Composable Engagement Models For Architects

I had a great time reading a recent article on A&G, our premier journal for elevating EA. The article is by an awesome writer, Raashi Bhatnagar. The article, on Composable Architecture, the latest description of adaptable enterprise architecture from Gartner made me realize just how far ahead and how powerful the Iasa Engagement Model is as a tool for implementing architecture practices. This article will describe first how Iasa’s engagement model in the ITABoK already has implementation methods for Composable Architecture but will also point out some rules of the road for connecting their model to a fully functioning architecture practice by pointing out some missing elements.

Since you may not be familiar with the term engagement model, it is the set of activities and interactions of an architecture practice, including all titled architects plus anyone expected to practice architecture. You can read about it here: https://itabok.iasaglobal.org/itabok3_0/engagement-model-overview-3-0/

Start by reading the article here.

MegaHeading
Composable architecture: The latest trend in EA helping companies adapt and grow

The Composable Architecture ‘Engagement Model’

There are a few foundation building blocks in the article that are used to achieve a composable architecture:

  1. Assessing the Ecosystem: In this step the organization ‘senses’ its environment through a few common tools; a) business capabilities, b) value streams, c) customer journeys.
  2. Assess the need for composability: In this stage the capabilities are supposed to be measured to understand what can be and should be composed by understanding their value, inputs and outputs.
  3. “Architect” (I put in quotes because one of my pet peeves is that architecture is not a verb :-)): In this phase you decide on what to work on and how to prioritize based on modularity, orchestration and discoverability.
  4. Build and Repeat: This step stresses the connections between business, solution, enterprise architects as well as a word or two about connecting development through strategy, intentional architecture and emergent design.

The goal of using this method is to be able to use capabilities and some aspects of technology to compose and re-combine the enterprise at will. This has long been the dream of architecture in general (remember component oriented architecture? also one of the goals of SOA). The basis for the thinking is that by using business ‘components’ called capabilities organizing them into value streams, then aligning them from strategy to execution, the enterprise can quickly and easily change, modify, replace, outsource or restructure the overall value proposition to a customer with minimum operational impact (not minimal, but more easily than without this method). The ITABoK whole-heartedly agrees and supports these tools, as you will see. However, it adds a number of building blocks to the engagement model for architects and the company which are missing in this structure.

The Engagement Model Tools

The article lists a few key concepts and tools:

  • The capability model: Capability Models have been in vogue for many many years now and the business architecture guild has done wonderful work detailing out their use and how they connect people, process and technology. They are also a foundation of the work in the ITABoK. There is much more going on behind the scenes in capabilities though as we will shortly see.
  • The customer journey: Customer Journeys are a bit newer and help an organization understand the lifecycle of customer interactions spanning across capabilities. They are also a wonderful addition/support to the jobs to be done framework that the brilliant folks at https://strategyn.com/ have done through the years. Connecting these to all levels of architecture takes some real work again as we will see.
  • The value stream: The value stream is a really old concept originating in the value chain and lean manufacturing space. It is an awesome tool. Again we are going to look at a lot more concepts to get all these to work.

So in the Iasa engagement model method, we look at these as ‘tools’, thought tools, mind tools, customer tools, stakeholder tools, design thinking tools, pattern and style tools. Sometimes these tools are automated as Mega does as well as others. But the power of tools is how they connect disparate often conflicting elements of an architecture practice together.

The ITABoK uses cards and canvases to represent these ‘tools’.

For example this is the ‘Capability Card’, which allows a capability to be mapped both inside and out. It is connected to the Capability Canvas, which lists all the capabilities, the business dependency network (from Cranfield) canvas, as well as the business model canvas and others.

No alt text provided for this image

This is the Value Stream Canvas (the folks at SAFe have a wonderful one as well).

No alt text provided for this image

And finally the customer journey canvas.

No alt text provided for this image

So the article gives an organization 3 tools and some basic advice on connecting them through different architecture practices. Obviously the ITABoK agrees. But this is where we run into interesting challenges. To be truly effective these need to connect through many other concepts. The ITABoK has over 75 of these cards and canvases to help with connecting the concepts necessary for a truly large architecture practice with numerous types of architects. Think through each of the icons in the following diagram.

No alt text provided for this image

So for example, how do you extract objectives and key results from business capabilities? How do those relate to architecture principles? How do those impact the architecturally significant requirements of a particular solution. Each of the concepts represented has a set of connections and ‘tools’ (remember we are talking thinking and facilitation tools) that are needed to see it come to fruition.

There will be many more of these posts to help understand the conceptual tools needed for a large architecture practice to be successful. One of the tools we are creating is a set of scenarios to show how these can interrelate:

No alt text provided for this image

Note: The way the canvases connect and this image is automatically generated from our database of canvases and cards all by the magic of one of our leaders David Slight, which I think is extremely cool. Basically he has systematized the very powerful set of concept connections within the canvases.

Look for many more tools and techniques from the Iasa and the awesome authors at A&G! And remember you can learn all of these techniques in our Core, Solution, Business, Integration, and Software Architecture Courses.