Processing the Enterprise...

23rd of February 2016

Gartner states that Enterprise architecture (EA) is a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes. As for Business process management (BPM), it is a discipline that uses various methods to discover, model, analyze, measure, improve, and optimize business processes.

Triggered by Paul Harmon’s musings on Business Architecture in this month’s entry on his blog, where he states that the discipline has become muddled with the “invasion” of enterprise architects since the late nineties, I have once again started thinking about a pet peeve of mine: What is it exactly that Enterprise Architects do and how does it relate to Business Process Management people? A recurring fear in a lot of domains is the added value it brings to the table. To quote Harmon: “Suffice to say that lots of people with lots of different perspectives are now engaged in suggesting the creation of artifacts (e.g. capabilities) that are of dubious value and that have made the whole topic very confusing.” There are many papers, blogs and various other outputs that suggest several fields of added value, and since I am not an Enterprise Architect myself, I don’t feel myself up to the task of challenging any of these claims. I simply do not have sufficient information on the topic at this time to either confirm or disprove them. However, I do fancy myself to know quite a bit of BPM, and the question then begs: What does EA do that BPM doesn’t, and vice versa? Do we need both in an organization, or is one, either one, sufficient? Or are they equivalent and give answer to the same problems, each arriving at a valid solution in a different way?


My understanding of the demarcation line between the two disciplines has always been that EA and BPM are very synergistic and highly complementary. Where EA will deliver value to the BPM effort by identifying those processes in the value chain which offer the highest benefit to the business goals, BPM will deliver value to the EA effort by operationalizing the future-state vision established by EA. And through this operationalization, BPM creates detailed current- and future-state business models that enrich the EA models, supporting other EA efforts such as information architecture and application portfolio rationalization.

But when a guru like Paul Harmon scratches his hair when the question pops up, you are no longer so eager to take your own views at face value. And so I hit the books to confirm my suspicions. And the book I happened upon was a RedBook By IBM titled “Combining Business Process Management and Enterprise Architecture for Better Business Outcomes”. It introduced me to the concept of Actionable Architecture, much like in EIM we stipulate that knowledge is actionable information. IBM characterizes its Actionable Architecture as follows:

  • Contextual with a clearly defined purpose, motivation, priority, scope, and time horizon
  • Collaborative with availability to and accessibility by all stakeholders to get participation and commitment, often even collaboratively evolved
  • Connected with traceable links across purposes and domains, including appropriate levels of change and configuration management
  • Consumable that can be understood from (different) stakeholder perspectives and viewpoints as required for their understanding and buy-in

Rendering architectures actionable is thus no small feat, but it plays an integral part in creating a synergy or tension field between them so that handovers in both directions can take place. In this case, it makes certain that both EA and BPM architectures profit from an exchange between the two.

IBM’s view on the demarcation line is similar to mine. They place the alignment with corporate strategy and the definition of subsequent blueprints in principles squarely in the corner of Enterprise Architecture. They also place the task of validating the “contract” of any transformation processes with the enterprise architect. However the solution delivery (or implementation) and the portfolio management and optimization segments are the purview of BPM. Where EA sets the direction and the targets to reach (translated from the corporate strategy), BPM takes over to design/define and execute the manner of optimization and transformation.

Reaffirmed in my beliefs, and bolstered by IBM’s similar views to my own, I lay this topic to rest till the next guru raises it up again with sufficient cause for concern.

Review EA BPM