A few days ago, I weighed into a discussion in the BPM Group LinkedIn group. Someone had asked the question "what’s your opinion? is BPM part of EA [Enterprise Architecture] or EA part of BPM?". Well, I took the bait – I couldn’t help myself – but I didn’t have time to really give a comprehensive answer. I have heard others ask similar questions, so hopefully this will be useful.
The first thing we need to get to the bottom of is – what do you mean when you say Enterprise Architecture? Anyone who’s been following me for long enough will know that this is an old hobby horse of mine. Still, it seems that most practitioners of and commentators about EA mean "Enterprise IT Architecture" (i.e. "architecture of IT systems enterprise-wide") rather than "attempting to architect the whole range of systems and structures that exist across the enterprise" (including systems that have no significant IT components).
The latter is a much larger and more complicated effort.
The way you answer the question about how BPM fits really depends on how you see EA. If you see it as the former (let’s call that "small EA") then there are three likely views. If you’re concentrating on mapping out application, middleware and database portfolios you might wonder if there’s any connection with BPM at all. If you have a slightly wider scope of concern you might be mostly concerned with how a BPMS platform relates to other systems and components. Lastly, if you have a perspective and remit that also encompasses business context, you might see BPM activity more as a kind of requirements definition input to your architecture work.
The much more interesting response comes if you think about this question from the perspective of the latter view of EA, though (let’s call this "big EA").
In "big EA" the goal is to try to build up a high-level picture about how an enterprise operates as a system-of-(only-sometimes-IT)-systems, and to use that picture to reason about relationships between business goals and strategies and existing and future investments in business capabilities, resources of various kinds, and technologies.
In this context, the answer to the question "Is BPM part of EA or EA part of BPM?" is still not simple – it’s "neither". However this is not what many architects expect. The heart of most architecture work as it’s carried out today is modeling, so it stands to reason that architects will see BPM primarily through the lens of business process modeling.
Any confusion here could well get worse, I think, as BPMS vendors offer more comprehensive modeling tools as part of their suites – tools that aren’t just focused on process modeling, but also modeling of other related concepts such as organisational structures, information types and even strategies. Although these tools aren’t typically EA tools in any meaningful sense, they are concerned with modeling other types of object commonly found in EA reference models and taxonomies.
But BPM is about much more than modeling; that’s just one piece. BPM is a fundamentally different creature from EA – because EA, like the vast majority of other management-related disciplines that organisations practice today, clearly separate planning work from execution. BPM is not (or at least, ideally should not be) like that. In the world of EA, execution – either of change projects or "run the business" services – is Somebody Else’s Problem.
Conversely, a big part of the value of "BPM done right" comes expressly from the way that it erases that boundary between planning and execution. BPM work creates clear feedback loops between business strategy, management and execution and back again – through technology.
So: from a pure planning and modeling perspective, process management work follows from a broader Enterprise perspective – but planning and modeling is just one (important) element of BPM activity. If you see BPM as a part of EA, or indeed if you see EA as a part of BPM, you’re probably doing it wrong.
What’s your view on this? Do you think there’s enough understanding about how EA and BPM work should fit together and influence each other?
And by the way, just to muddy the water further, of course BPM can be used as a way to build and manage a process for creating and maintaining an EA practice and its outputs… for large organisations with serious commitments to EA work, this could actually be a pretty sensible use for BPM practice and technology.