These are the inefficiencies and costs you might be paying if your product/project lifecycle is not based on a digital platform.
It is impossible to remove the fog of war or improve efficiencies at scale with better people or a better framework alone.
The solution to all these business case issues below requires using a platform that takes a truly digital approach to create, share, and evolve reusable architecture components.
New staff inefficiency cost
This is the cost of skilled but new staff being inefficient because they lack access to high-quality and in-depth current state business and IT platform content.
How much time is required for new hires to become efficient? Three months? 6 months?
How do new hires solve the day-to-day questions around how the business and IT platform work, especially considering the delays often involved in booking meetings with people who may know the answer to these questions?
The alternative is new hires being able to browse through a curated set of Architecture models to learn how the business and IT platform work and query this as required when a quick design decision is needed.
- How does the business work?
- What application platforms do we have, what do they do, and how is data created, consumed, and exchanged?
- What projects are planned and in flight, and how do they change the IT platform?
- What are the partner and supplier ecosystems, and what information do we exchange with them?
Lack of reuse cost
This is the cost incurred if Architects do not have a way to reuse Architecture content digitally and are forced to create designs from scratch.
How much time is spent performing modelling of components that are already modelled somewhere?
If all Architects are constantly remodelling your IT systems from scratch, how consistent and complete will those models be?
How much time do Architects spend attempting to discover what can be reused and then analysing functionality or performance to assess the appropriateness of reusing a component?
The alternative is being able to discover, analyse, and import the interface views for reusable Architecture components into their project architecture models. For example, the APIs and other interaction mechanisms for your core platforms.
Quality and consistency cost
This is the opportunity cost of receiving high-value assurance feedback from the range of experts in your business, who would be able to provide better feedback on designs if only they could understand them.
When all of your Architects use different modelling styles, it becomes difficult for your experts (InfoSec, Infrastructure, Business, Regulatory, etc.) to understand them.
The alternative is using AIM’s rules engine and machine learning to automatically drive quality and consistency at scale, improving the level of expert feedback from teams within your business.
These diagrams exist alongside the sketches and other collateral typically created in PowerPoint and Visio.
Duplicated projects risk
This is the risk of duplicated projects proposed from different areas of the business due to not having visibility of strategy or pipeline of planned projects.
The risk is that duplicate projects get initiated and then must be consolidated and reshaped once large project teams have been onboarded.
The alternative is for business sponsors to be aware of strategy artifacts to work together better and avoid proposing duplicate projects in the first instance.
If duplicate projects are proposed, then they can be reshaped before large project teams are onboarded.
Duplicated technology risk
This is the cost of introducing duplicate technology because the sponsor does not have access to what technology is in use or what projects are in the investment pipeline.
The alternative is the project sponsor’s ability to query AIM for application and technology building blocks and understand what is already available.
This can also include a shift in thinking about reusable components (that package applications and technology into services) so that sponsors propose projects that improve or introduce new components (platforms) — not individual application and technology elements.
Poorly conceived projects cost
This is the cost of ill-conceived projects being proposed, typically in the form of “Let’s consolidate all the X’s” — substitute whatever application or technology component you like for “X”.
The alternative is offering a component-based way of thinking, in which the focus shifts to how information is created, consumed, and exchanged through the Enterprise.
Projects should exist either to deliver new products and services or to streamline the IT platform into a smaller number of core platforms that evolve over time.
Project proposals should mostly be authored with awareness of this, and not simply introduce a new application to solve a narrow problem.
Subject matter expert (SMEs) over-utilisation
This is the cost of product/project teams unnecessarily engaging SMEs for functional and architectural inputs because there isn’t any helpful documentation on how systems work, or no one knows where it is.
It also includes consideration of usually incomplete information provided by SMEs since they typically know how to use the application/technology, but not how it is architected.
The alternative is for product/project teams to access a rich set of architecture and functional content that can be searched without always needing access to SMEs. Instead, your SMEs can focus on what they are meant to do.
Change management cost
This is the cost of curating and publishing changes to strategy, projects, and other Architecture related information, including the cost of that information becoming stale.
The alternative is AIM being the known up-to-date location for project architectures and component architectures so that updates to projects and reusable components are visible to everyone all the time.
Misalignment to strategy cost
This is the cost of having projects proposed that do not further the business or IT strategy because proposers are not across the strategy or what projects may be planned or in-flight.
This can lead to the IT budget being frittered away on projects/products that do not matter and make no difference to the business.
The alternative is enabling project proposers to access and contribute to the business’ evolving strategy and having a more significant percentage of projects be strategically aligned.
Scope blowout cost
This is the risk and cost of scope blowouts because the project wasn’t shaped or defined correctly in the first place, or the work packages required to deliver the project were not adequately defined or socialised.
The alternative is to have project concept designs published in AIM so that they can receive broad scrutiny and feedback on whether the scope was fully identified. This applies equally to whatever methodology is being used, SAFe or otherwise — it is important to separate direct and indirect scope items. Directs should be tagged as Work Packages against the target architecture.
Ineffective governance cost
This is the cost of a project not being appropriately assured such that the solution causes some issues: technical debt, duplicated technology, lack of ability to address business drivers, etc.
In addition, governance can sometimes be too little or too late due to a lack of openness and transparency around the development of project architectures.
The alternative is that project architectures are visible early in their lifecycle, and assurance has sufficient lead time to influence the project architecture design.
‘Assurance’ covers a range of teams, including InfoSec, regulatory, EA, as well as other project teams able to be aware of each others’ direction and self-govern. This last point is important because, under a SAFe or similar approach, project/product teams are usually running blind in their own project/product silo, unaware of any detail about what other teams may be doing.
Lack of ability to manage technical debt cost
This is the ongoing carry cost of having technical debt in the IT platform and perhaps an operating model that represents a constant tax on the business due to having to compensate with manual workarounds and more staff.
The alternative is managing technical debt on a per-Component (platform) basis instead of a usually long list of to-do items that aren’t organised within any structure.
A per-Component approach to managing technical debt makes it easier to make investment decisions on how to remediate that debt.
Time to market cost
This is the cost of a new product being late to market due to a range of inefficiencies in the plan/design phase outlined above.
The alternative is operating more openly and transparently, where product/project design can be assembled using reusable components, assured more quickly, and go into delivery much faster than average.
Annual funding model agility cost
This is the cost of a lack of business agility and responsiveness resulting from annual funding model approaches.
The alternative is to better manage the strategic investment pipeline with openness and transparency, a more agile rolling funding model can be implemented, e.g. 3-6 month lead time of investment planning.