Digital Transformation

What does good look like?

Your business has started using AIM, and this story below describes how you drive digital transformation.

(We’ll use the term project to mean project or product, depending on the particular approach your business takes, and also use the term PMO to refer to either PMO or Agile Release Train, and PM to refer to Project Manager or SCRUM Master).

One day, in the not-too-distant future.

Adopting AIM, you rounded up all your project architecture models and loaded them into AIM.

This was a revelation to your staff. They had never been able to surf through any models like this before, and even though this was just an incomplete initial curation of models, it was enlightening.

People could understand what other projects were doing and where there was alignment or interaction between projects. This led to all sorts of healthy collaboration across projects.

As part of this onboarding, the project architect tagged the project models with information such as the business domain, lead architect, and project stage — to make it easier for the PMO/ART to analyse from a portfolio point of view.

Due to it being easy for everyone to find and surf through models, it became immediately more accessible for projects to socialise and evolve their designs with the various assurance and approval forums.

After Architects loaded their project models into AIM, the EA team extracted various model fragments and loaded these into AIM as reusable Architecture components.

The initial set of components that you loaded were the usual suspects that tended to appear in most project architectures – the CRM, the billing platform, the integration platform, the ordering system, and so on.

It was strange to notice that most project architectures modelled all of these reusable components from scratch, which seemed to be a bit of a waste of time.

To save time and consistency, you adopted an approach where projects imported these reusable building block/component definitions.

Now, in this new world where everyone loaded project architectures into AIM, you found that various teams collaborating on projects found it easier to review and provide feedback, e.g. teams like CyberSecurity, Infrastructure, Regulatory, Testing, and so on.

Previously ineffective assurance processes were replaced by those teams now more effectively contributing their valuable expertise to the design early on and continuously.

The project teams could also now craft Stories atop different project architecture views so that anyone viewing their project could learn about it independently, without requiring many meetings.

Stories covered such aspects as ‘How does the IT platform work?’, ‘What are we changing?’, ‘Why did we make decision X?’, ‘How are we securing the solution?’.

A convention evolved after a while on standard Stories that each project should create, which led to fewer meetings, and more time spent delivering products.

Standard stories included explanations of the problem/opportunity, key design decisions being made, how the solution was being secured, and the main pieces of work to deliver the solution.

The Strategy and Architecture (S&A) team also loaded their Enterprise reference models into AIM.

These included designs covering value chain, operating models, and information flows for the Enterprise as a whole and next-level down views on a per-domain basis, motivation models (drivers, goals, etc.), technology reference models, and business capability models.

The EA team marked up their reference models with documentation for each model element and created stories atop the models so that they were easy to find and use by the broader IT and business team.

These EA reference models had never been as easily accessible as before.

The business could now use these reference models for more collaborative planning.

They could create investment plans that considered the Enterprise as a whole rather than a series of separate departments.

These foundational views were important because IT fundamentally is about streamlining the flow of information to achieve outcomes — everything else is derivative. That is, applications, technology, security, and so on only exist to support the streamlined flow of information.

And so, having a platform to publish the lifecycle of information as it is created, consumed, and exchanged was critical to enabling a broad understanding across the business of what all/most IT projects should be seeking to optimise.

As a result, the EA reference models became more living/breathing designs, enabling a higher proportion of investment to be more strategically aligned instead of being frittered away on low-value projects.

Due to more people having access to project and component models, rather than just the Architects, it became more important to the business that diagrams were high quality and consistent.

The business agreed on what diagram conventions were necessary and typically what type of diagrams are expected per project and component. This didn’t necessarily mean high complexity diagrams; it just meant the same kind of diagrams should more or less be done the same way.

Architects configured some Rules in AIM around these conventions, and Architects could quickly press a button to check if their diagrams aligned.

After IT had created a few ‘good’ models, these were given to ArchiBot; the AI built into AIM so that it could learn what ‘good’ meant and then support achieving quality and consistency. The Architecture team took on this new ‘AI trainer’ role.

It became a badge of recognition to have your models selected to go into the ‘good’ training set, encouraging friendly competition to produce the most fit-for-purpose and consistent models.

As projects continued to be delivered, the approach to project modelling shifted to a component-based design.

Architects linked their projects to reusable component models and only imported the interface views for those components; that part of the component needed to interact with it. Interface views typically include the UI or API for a component.

Using a component-based approach is what the software and civil engineering world have been doing for many years, so it made sense for Architecture to catch up and replicate this successful approach.

This technical ability to manage components meant that it was now possible to improve components over time incrementally.

Component authors added meta-tags like domain, layer, owner, and status, making them easier to find.

Components authors also added Stories to make it easier to understand what they did and how to use them.

The basis of managing technical debt was also centred around Components. If a component had technical debt, then IT added a technical debt story to the component.

The business could then quickly search through stories where Type=Technical Debt to see the overall level of technical debt in the Enterprise.

This made it easier to see where CIO and the business required investment, and addressing technical debt could now be done as a separate project or part of a project.

Previously, no one understood how much technical debt was present, where it was located, or how to fix it. As a result, projects could not incorporate a selection of technical debt into their scope.

The previous approach to managing technical debt was just a long list of fixes captured during Assurance/Governance sessions and then not acted upon.

Due to everyone embracing this better component-based approach, the business stopped having ‘application owners’ and instead adopted ‘component owners’.

A component could include any application and technology components, although ideally, not too many.

A good component did a few things well and had a very well-defined interface, central to Object-Oriented (OO) thinking.

In OO thinking, components should have high cohesion (do one thing well) and loose coupling (well-defined interface) so that changes to a component do not require large-scale changes across the IT platform.

PMs/SCRUM masters found that AIM helped better de-risk delivery because AIM could extract a clear view of Work Packages and Deliverables — which show the pieces of work required to deliver the target architecture.

It was easy to open a project, click on the Work Breakdown Structure (WBS) tab, see the Work Packages and Deliverables, and then click through to the view on which they were defined.

It was easy to see if little or no Work Packages were defined, which probably meant that there was scope yet to be identified.

This open and transparent approach to the WBS meant that the scope was better identified, costed up front, and incorporated into the Project Plan/Program Increment.

PMs/SCRUM masters found that they could deliver better plans since there was a differentiation between direct and indirect activities.

Changes to the Architecture are ‘directs’, and everything else is ‘indirect’. Or, anything left over once the project is complete is ‘direct’, and everything else is ‘indirect’.

This differentiation meant that project plans/PI planning didn’t mix direct and indirect together, so it was more evident how the business and IT platform were changing.

Even though the business had tried a ‘better framework’ or ‘better process’ before, they were surprised that it took the actual technology enablement of the project/product architecture lifecycle to provide a real step-change to the business.

After taking a step back to consider the impact, everyone agreed these were the significant valuable changes that had occurred.

As a result of using AIM to support digital transformation, there were:

  • less duplicate projects due to an Enterprise-wide view of planned and inflight projects.
  • fewer projects proposed misaligned with strategy
  • increased visibility and ability to manage technical debt – due to it being captured on a per-component basis
  • less wasted energy by project teams due to fewer unnecessary meetings.
  • less over-utilisation of SMEs contributing to project meetings
  • less time/effort spent updating the business on what was changing
  • less change management effort since it was easy to see what had changed
  • fewer cost blowouts due to better identification of scope
  • faster project delivery due to better socialisation and more rapid project modelling through digital reuse of component architectures.