The Agility Quadrant

mcronin Mar 16, 2016 Agile

What role does a reference architecture play in agile delivery? And how do you start to build a reference architecture and road-map to support your Agile programs?

We created a tool we like to call the Agility Quadrant to support us here. In this article we will explore how we use the Agility Quadrant as one tool to support us in decisions regarding what could be an agile asset and what should remain “Monolith”. On this quadrant we plot technology agility against business agility.


Why is business agility different to technology agility?

Technology agility is easy to address, even if definitions vary on the market. There are lots of products, tools and technologies that can be built, deployed and monitored quickly. They are highly modular, configurable and customizable at the lowest granularity.

The business agility vector captures the level of agility the business user experiences. For example, many technologies now separate templates from content (i.e. content management, output management or customer experience management). These technologies, implemented, provide agility to the business. I once implemented an output management solution for a customer that had chosen a technology after a lengthy internal political process. This technology was produced by a small product vendor and the product originated back to the CTO’s college thesis some 15 years back. We delivered the project successfully. Now if Swiss law dictates a change serial numbers used by this customer the business can respond very rapidly. Their experience is positive and agile. However if the product experiences a bug, the product vendor needs to wheel out an ancient C compiler from a cupboard to fix the base product (I kid you not). The product has no real road map, so when new features are needed the upgrade path to the next version will not be trivial. As an IT owner, I would know the experience will not be agile. Therefore this solution is very agile from a business perspective but not from an IT perspective and should be plotted in the top left hand quadrant.

So what do we plot on this quadrant?

I recommend a 2 phase approach to enable you to identify what should be agile in your organization.

First a logical architecture approach and then secondly plotting capabilities and outcomes.

Phase 1 - Logical Reference Architecture

With the above in mind I have asked customers to plot where they see the systems in their organizations reside on the Agility Quadrant. It is very important that this is done from the perspective of their organization and not that of product vendors or research analysts!

Frequently I see layouts like this:

vanilla quadrant

We can see that the systems of record do not need to be highly customizable. These systems typically have high investment but once realized have low configuration, customization and changes both from an IT and business perspective. Take payroll; the payroll system needs to issue salaries to employees once a month. The business processes may not change often. The requirements may not change often. The technology does not need to change often. The system is critical to the success of the organization. Without being paid the valued employees will walk out. What is important here is that no quadrant on the Agility Quadrant is “bad”. Stability is a good thing and being successful at stability enables agility.

When I see layouts like this from customers I challenge their physical platform layout approach. Even though architects build “logical” models, they frequently look like physical stacks – like the one above. I encourage my customers to think like Picasso #ThinkLikePicasso.


In a logical reference architecture systems do not need to stack on one another making visual sense like a physical stack. So applying #ThinkLikePicasso the real layout for the organization maybe as follows:

chocolate quadrant

The Systems of Engagement may need to be very agile from a business perspective. Adapting quickly as customers behaviour changes but maybe for this organization the technology solution can be simple enough, for example a salesforce CRM could be provisioned to an organization as a SaaS solution. The overhead for the IT teams for that organization is very low, the SaaS manages upgrades, new releases with new features and all technology considerations, but the system responds rapidly to business changes.

In this example we have plotted the systems of insight and utility in the far right. For these solutions the organization needs to plan to enable both the business and IT teams be agile. The technologies and methodologies chosen in this space need to rapidly respond and adapt to business and IT requirements and changes.

Phase 2 - Capabilities and Outcomes

Most technology vendors would probably plot themselves in the top right hand quadrant – thereby telling your organization nothing! Therefore in this phase it is very important to plot capabilities or outcomes rather than technologies. Simply put, capabilities are what your organization are trying to achieve, outcomes are the solutions enabling these capabilities. So the capability might be payroll and the outcome an SAP program solution implemented in production. Again this needs to be from the perspective of the organization.

Organizations typically like to use outcomes as they are frequently more tangible to them, and some organizations may not have a dedicated capability framework. For the purpose of this post I am going to use some of the capabilities from the periodic table.

The organization should plot physical capabilities (or outcomes) where they believe it should reside. So you may end up with something like this:


Now overlay this physical quadrant on your logical quadrant and will end up with something like this:


1. We can see our Underwriting and Billing capabilities are correctly plotted against systems of engagement and our collaboration capabilities correctly overlay with our Systems of Utility. These programs and associated architectures are following a strategic road map to be stable systems for this organization.

2. The Claims handling capability is currently in the top left hand quadrant. (In this example the customer upgraded their technology to a new technology listed on the periodic table, it provided new functionality to the business but was implemented 11 times across this global organization with little IT reuse and high license cost).

3. The customer relationship management capability was plotted in the top right hand quadrant as senior IT and business stakeholders all want to be "agile".

The above quadrants enables the architect and IT owners to determine

  • what capabilities their "high cost, low customization systems of records" should realize. Organizations can then implement stringent governance around these IT systems.
  • what capabilities can be "fully" agile (top right hand quadrant), here departments and business units can focus their agile programs, DevOps initiatives and agile infrastructure investments (docker). They can put initiatives in place to encourage adoption (rather than enforcing stringent governance)
  • portfolios and technology road maps. Above in the case of the claims capability it was plotted in the top left hand quadrant based on its physical deployments in the organization, but the logical reference architecture deems it to be in bottom left hand quadrant. This descrepancy (and the CRM one) should be taken by the architectural department and the gap closely examined. How can the solution and the programs provisioning it be addressed to move it into the correct quadrant?

Using the agility quadrant we can see what should remain stable (monolithic) and what are candidates for polyglots/modular architectures. We can also determine what new and in-flight initiatives need to be readdressed to correctly balance the architectural landscape.

The agility quadrant is one of the techniques we use to help define practical reference architectures to support a hybrid agile/stable landscape in large institutions.

Previous Post Next Post

Similar Posts You May Like