(Editor’s Note: What follows is Part 11. Part I appeared yesterday.)
By Greg Matthews
Subject matter expert (SME) over-utilisation
Most Enterprises have application owners that oversee and approve any changes to their allotted application(s).
What happens is that those SMEs typically get invited to meetings to explain what the application does and how it is integrated into other systems.
This is not the best use of the SME’s time, and the SME would be better off spending time on their actual job rather than in meetings explaining how systems work.
Typically, the SME is a functional expert on their allotted application(s) but sometimes doesn’t have a deep understanding of its Architecture, so there can be a lot of unintended misinformation on the architecture that needs to be worked through and verified.
It’d be better if the application architecture were documented and available for people to review and understand.
Ideally, it would provide all of the necessary details around application functions, integration, and information management. There would also be story-based documentation that answered key questions about the application platform – since story-based content is typically easier to understand than the content presented in other forms.
How to implement:
- Switch from an ‘application owners’ to ‘component owners’ approach (since an application owner approach generates silos).
- Ensure that components (which might cover 1 or more applications) have their Architecture design loaded into AIM.
- Ensure that designs cover application functions, data, integration, security, and link to business functions/processes, and the EA capability model.
- Create ‘Stories’ in AIM, being overlays of Architecture models, to provide a level of documentation enabling people to self-discover and understand how components (1 or more collaborating applications) work.
Change management cost
In a large Enterprise, there can be a lot of changes to applications, technology, and business processes throughout the year.
It takes a fair amount of energy to curate release notes and for staff to review and absorb this information.
This constant change means that there is a half-life to whatever facts someone thinks they know about how an Enterprise works.
It’d be better if there were a way to share Architecture changes. This might be changes to EA reference models, projects, or reusable components.
A centralised place to review Architecture changes allows people to more easily absorb summary information but then dive deeper if required.
How to implement:
- Create a Story in AIM for each significant element of change.
- Use a common story tag to identify those stories which were created to communicate change, e.g. ‘EA Update’, ‘Project Update’, etc.
- Inform your teams how to filter the AIM Stories page to see when change has occurred, and how to drill into Architecture content if they wish to explore further.
Misalignment to strategy cost
Most Enterprises have a Strategy function that charts the high-level direction of the Enterprise and set priorities for allocating resources.
It seems that staff commonly do not know where this strategy content can be found.
Sometimes, this is because it’s not even written down or published.
Then, well-meaning staff propose projects that optimise a department or aspect of the IT platform that isn’t explicitly aligned with strategy.
This can lead to the IT budget containing an unnecessarily high level of projects that do not align with strategic direction.
It’d be better if a strategy were published so that a higher proportion of project proposals were strategically aligned in the first instance.
How to implement:
- Ensure that views supporting strategic analysis are published in AIM
- Ensure that project proposals explain strategic alignment against strategy views before being funded.
Lack of scope clarification and project cost blowouts
It can be quite common for a project to be initiated off the back of a vital driver or objective that has been identified.
This might be a completely valid driver, but not represent a holistic view of the problem space.
Then, the requirements are written.
The requirements can then sometimes not really be requirements but instead a quasi-solution architecture document that specifies the solution and does not capture the current state, target state, or the changes to information lifecycle management.
Then the project ramps up, and an Architect is assigned at some point.
During project delivery, a range of discoveries are made, and there is a variation to project shaping and goals. For example, discoveries about unknown integrations, dependencies, or functionality.
All of this tends to require a readjustment to project activities, and therefore either an increase to the project cost or a descoping of the project to fit into the allotted budget/schedule.
It’d be better if the project scope were more fully discovered upfront.
This relies on being able to perform discovery on the current state in an Architecture repository to understand applications, functions, integration, and dependencies generally.
The main question being answered here is whether the proposed set of high-level work packages (scope) for a project makes sense.
If the project proceeds with the set of proposed work packages, will the Architecture (business, IT) be left in a working state, or will there be further remediation required?
How to implement:
- Take a ‘do the Architecture first‘ approach.
- Ensure that an Architect is one of the first people assigned to a project. i.e. do not just initially assign BAs to projects.
- Develop a high-level architecture approach that is intended to provide very clear project scope definitions, based on current state Architecture information. It should provide evidence that the proposed project scope will not require any further remediation work to leave the IT platform in a working state.
- Provide guidance around ensuring that “Business Requirements” documents do not morph into quasi Solution Architecture documents.
Ineffective governance cost
It can be quite common in large Enterprises that a project is launched, and then it disappears for some extended period to perform discovery and create designs.
The project is then told that it must pass through Architecture governance, so it prepares a slide deck that provides a project overview and explanation of the now locked-in target architecture.
The project then presents this deck at a governance meeting, and most of the time, because the project must meet a deadline, usually based on funding, there is little change that can be made. It’s too little, too late.
It’d be better if there was continuous access to project architectures as they evolved. This would allow for early feedback and meaningful project shaping.
Important feedback to projects can include guidance around:
- The use of applications and integration
- The lifecycle of information both within the Enterprise and with customers and partners.
- Functions provided
- Security
- Use of standards
- The general approach taken, i.e. tactical or strategic.
How to implement:
- Require that projects publish their project architectures into AIM, as early as possible, and also update when any meaningful change has occurred.
- Develop a collaborative approach whereby there is a continuous conversation across project stakeholders to ensure that appropriate project feedback is received, e.g. EA, Security, Applications, Infra, Procurement, Commercial, etc. can provide feedback as required through the project lifecycle.
- Modify Governance/Assurance processes to be more of a lightweight activity since the high-value project shaping and technical feedback have already occurred out-of-band of Governance processes.
Lack of ability to manage technical debt cost
It can be quite common in large Enterprises that Governance sessions make a point of capturing technical debt.
This list of technical debt gets captured in detail and then never referred to again.
This is partially due to the lack of structure available against which to tag technical debt.
It’d be better if the technical debt could be captured in a way that enabled it to be considered in IT investment planning.
One way to do this is to capture the current state IT platform as a series of components (1 or more apps and/or technologies that together provide a building block), and then tag technical debt against the relevant component.
How to implement:
- Define reusable Architecture building blocks as ‘Components’ in AIM. A ‘Component’ is 1 or more applications and/or technologies that work together as a building block. We apply object-oriented principles here, and seek to achieve high cohesion (do 1 thing well) and low coupling (minimal interdependencies with other components).
- In each Component, define one story for each element of technical debt. Tag each story with a meta-tag, e.g. type = ‘Technical Debt’, so that you can find and review technical debt across your entire portfolio of reusable components.
Part I appeared Monday.
Greg Matthews created the Architecture in Motion (AIM) platform as a result of 16 years in Enterprise Architecture and Solution Architecture in large Enterprises across different industries, and a previous background as a software developer.
AIM is an open and transparent platform to manage project architectures and reusable component architectures using the ArchiMate modelling notation. It contains a rules engine and machine learning to drive towards model consistency and allows stories to be overlaid atop architecture diagrams so that people can discover and understand architecture content more easily. This is a new and innovative approach to architecture and you can trial AIM for free at www.aimrepo.com. You can also find out more about AIM at www.architectureinmotion.com.au.