Better Scaled Agile with AIM

The great thing about SAFe and Scaled Agile is the strong delivery focus.

The no-so-great thing about SAFe and Scaled Agile is that, in practice, they can sometimes not be Architecture-friendly. Product Owners can sometimes be intent on releasing great products with a siloed perspective, which can create IT platform fragmentation over time.

You can’t blame them, though.

Enterprises typically don’t have a technology platform to enable digital discovery and reuse of Architecture components or continuous evolution of Architecture components over time.

This is where AIM fits in.

AIM provides an open and transparent repository for your product/project and reusable component models.

This enables a better approach to product/project development:

  • Architects can digitally reuse Architecture building blocks, improving design speed and quality.
  • Product owners can still seek to get their products to market the fastest way possible, trading off time-to-market vs potential technical debt.
  • Any Architecture development set aside in favour of a faster option can be captured as a technical debt against the relevant reusable Architecture component.
  • The Enterprise can balance investment into products/projects vs improvement to reusable components / addressing technical debt — since at least technical debt is now captured and searchable in a meaningful way (per component).

Without AIM as a central repository, none of this is possible.

  • Teams typically develop their product/project Architectures in a silo, and it’s difficult to identify gaps and overlaps across the PI. Are multiple projects introducing duplication or fragmentation into the IT platform rather than reducing it?
  • There is no feedback loop to harvest reusable Architecture components. As a result, every project/product design starts from scratch.
  • The ART never gains the ability to become a configuration activity, rather than a design from scratch exercise.
  • Assurance activities, like CyberSecurity, Regulatory, and Privacy, must assure the entire solution rather than being able to treat reusable components as pre-assured.
  • This problem is compounded every time there is staff turnover.