The Evolving Role Of Business Architecture

Business architecture has become a bit of a watchword for organizations thinking about their future. It’s about all sorts of things – the “what” we do and “why” we do it. It’s about the “who with”, or more importantly “who for.” But it’s also about the “how we do it”, and “how we build engagement” to ensure we “do the right things,” rather than just “doing things right.”

Given that I focus on the methods and techniques that help organizations translate strategy into action (business architecture, process architecture, business engagement, etc.), I want to talk a little about the trends, methods and approaches that we see in the practice of business architecture.

I have to say recent engagements have been a real eye opener … some folks are very advanced in some areas – say capturing strategic intent, but then struggle to translate that into meaningful plans that energize colleagues in the business. Some are talking a good story of target operating models – focused around the experiences they deliver to their customers, but then miss the link to current day project portfolio that’s singularly focused on reducing the employee headcount. And as we saw in our recent BPM Suites Wave, business architecture principles are becoming more important at the process execution layer too.

Many business architects have put business capability maps as the core element of their toolbox, with a few different heat maps to help focus attention. When my colleagues and I review the capability maps and approaches of our clients, we find challenged common thread:  Business architects often struggle to get the levels of engagement they need in the business; to be taken seriously and not be seen as some purveyors of some sort of geeky IT method.

As Brian Hopkins put it – they suffer the common IT problem of “doing it to the business” not “with the business.” Gordon Barnett and I are concerned that as much as 75% of the clients we’ve met had a fear of going to the business to discuss issues – they didn’t see that co-developing capability maps could really help them in engaging their colleagues. They were creating capability maps and present them, often without any real business context. It’s not that business folks don’t see the value in capability maps; it’s that to be relevant, business capability maps have to help solve a problem (that they care about).  The two key takeaways:

  • Develop your capability map with your business partners; don’t do it for them.
  • As quickly as possible (in weeks, not months) put them to use addressing a problem the business cares about. 

Use is the most critical aspect.  To help business architects put their capability maps to use, Gordon and I will soon be publishing a Capability Assessment Toolkit (and demonstrating at the Forrester Business Technology Forums in Washington DC and London). This will enable multi-dimensional comparison and portfolio management across business capabilities in support of road map planning for a variety of purposes including (but not limited:

  • Customer experience or service design efforts.
  • Business process improvement initiatives.
  • Application rationalization.
  • Opportunities for revenue generation or cost reduction.
  • Risk assessment and compliance.

The same approach can also support decision making around business shape such as:

  • Whether to in-source or outsource a capability.
  • Investment planning or how to prioritize acquisition targets.

Post M&A, it can also help provide a framework for alignment across the business, or even support a broader metrics framework spanning the entire enterprise. The point is that once business execs see the usefulness of business architecture, business architects will be able to close the gap between architecture models and the real world their business operates within.   

Are you seeing the same gap between business architecture and execution?  Do you have tricks or tools you use to close the gap? 


Capability definition

Hi Derek,

Interested to see the Capability Assessment Toolkit that you and Gordon are working on.

At the risk of incurring the wrath of this community, can I suggest, that what is missing from the whole Capability approach is a well-defined, broadly accepted, precise, unambiguous definition for a Capability (unless I've been living under a rock).

My experience is that the term as it is used is very ambiguous and wishy washy once you start drilling down into it.

Being pragmatic, if we are to build our business architectures around Capabilities we need to be able to model one.

So what is the canonical model for a Capability?



Cannonical Capability Definition

Hi Terry - thanks for weighing in. As you can probably guess, I have my definition and yes, there's lots of room for confusion. I see the word used several different ways to mean subtly different things. But I think the real issue is in your question ... "Well defined, broadly accepted, precise ..." LinkedIn is full of raging arguments on that front.

But humor me for a minute here ... What's yours? I will then respond with mine.

A Canonical Model for a Capability

Ha! Why should I have known to expect a Socratic response!!

OK, well I will give you my explanation which, since I am obsessed with conceptual models (or more specifically, ontologies), is a very structured, positivist view.

Firstly, I'd suggest that the difficulty in defining a Capability lies in the fact that it is a composite concept involving interactions between various atomic concepts. Proposing a canonical model involves identifying these concepts and their relationships. Several authors identify a list of related concepts but I haven't seen any attempt to model them. This is how I would approach it:

A Business Capability it would seem, is concerned with an ability of an organisation to achieve a desired Outcome. It involves somebody doing something to bring about some desired state of affairs. Assuming that's a close enough definition, it's clear that there are a number of concepts in that statement and in my definition they are:

- An Outcome - a desired state of affairs, recorded by a particular state in the lifecycle of a business record (eg ShippedOrder)
- An Action - identifies what's actually going to be done in this endeavour (Ship)
- A Role - the party authorised to execute the the Action (eg OrderShipper)
- An Activity - the task or service in fulfilment of a particular business endeavour (eg ShipOrder)
- The Subject of the Activity - the party for whom the endeavour (or service) is being transacted (eg Customer)
- The Object of the Activity - the asset, information or service being transacted (eg Product)

If I could paste a picture here it would help to show the relationships. I'll send it to you by e-mail and you can decide if it's worth posting.

All of these are constructs of the CAPSICUM Framework which you can read about at


Biz Arch

While it is not universally true, more often than not, techies are morphing into business architects. And they carry that frame of mind, toolkit and approach to the job. The language used is technical and alien to business, the frameworks are complicated and burdensome, and the focus is on artifacts, not outcomes. These are some of the pitfalls of business architecture "being done" to business rather than with business.
Sorry for the self promotion, but in work with major financial institutions as a consultant and in our software (, we've made it very business friendly. Business product managers and capability owners drive much of the work with enterprise and solution architects pitching in as needed.