Structure, process and purpose
Just a simple idea that came up whilst I was pondering why the mix of EA (enterprise architecture) and BPM (business-process management) worked so well at the combined IRM-EAC / IRM-BPM conference last week.
I’ve long said that enterprise architecture is about structure and purpose, but I realised a few days ago that we can also turn that the other way round, and add another twist to the story.
‘Enterprise’ is about purpose – the Why of the organisation and its work.
‘Architecture’ is about structure – the What of the work.
“Process’ is about action, about execution – the How of the work.
Enterprise architecture is about the relationship between structure and purpose – the What and the Why of the organisation. Yet of necessity it’s also interested in process, the How of the work, how a strategy is brought into real-world execution. So enterprise-architecture needs to know about business-process management.
Business-process management is about the relationship between process and purpose – the How and the Why of the organisation. Yet of necessity it’s also interested in structure, the What of the work, in the ways through which everything holds together into unified whole. So business-process management needs to know about enterprise-architecture – especially the ‘real-EA’ forms that extend far beyond the confines of the IT-centric box.
Strategy – purpose – is the bridge that binds them together. Hence, we might suggest, the relationship between Why, How and What, that would reminds us of Simon Sinek’s exhortation that we should always ‘Start with Why’.
Each discipline needs to know about the other discipline’s space. Each will only work well with an understanding and respect of the role of the other. Two disciplines walking hand-in-hand, we might say, toward the guiding star of purpose.
What. How. Why.
So no wonder, really, that that conference worked so well! 🙂
Hi Tom,
The “How” in my opinion not only considers process execution, i.e., the operational stuff, but there is another “how” to EA: how you *implement* the architecture. This change management and business transformation part of EA is often neglected, or only approached from a blueprint perspective: portfolio management, plateau planning, transition architectures, etc. But there are many other perspectives on change. Should we view these as part of the EA discipline, or do you think this is better left to “the management”?
Marc
Hi Tom,
My interpretation of linking between WHY, WHAT and HOW is slightly different.
Classic ‘architecture’ is about static structure or static relationships between WHATs. Classic ‘architecture’ is an “enterprise genotype”. At the same time, there is “enterprise phenotype” (a set of observable characteristics such as performance) which is related to your ‘Enterprise’, purpose, and WHY.
Classic EA can’t predict how modifications in the “enterprise genotype” will change the “enterprise phenotype”. BPM, with its explicit and executable business-processes (which are dynamic relationships between WHATs or HOW some WHATs are produced from other WHATs), is the bridge between the “enterprise genotype” and the “enterprise phenotype”.
EA+BPM also help to execute the strategy or to carry out the change management — WHERE or desired delta of “enterprise phenotype”. Because of the BPM executable nature, it would be possible to define the necessary delta in “enterprise genotype” via the simulation (of course, with some approximation).
More details are in http://improving-bpm-systems.blogspot.com/2011/02/explaining-ea-business-architecture.html.
Thanks,
AS
Hi Marc – many thanks for joining in on this!
Will admit that the post above is way too simple as any kind of guide for action: what I wanted was to keep it short, rather than my usual over-long essays… 🙁
Quick summary is that I don’t think anything would be ‘better left to “the management”‘! 🙂
There are two sides to that slightly silly answer, of course.
One is that if whatever-it-is has anything to do with structure and purpose, and the way in which those are identified, assessed, (re)-combined and (re)-implemented, then it’s of concern to enterprise-architecture. And the processes that go through that architecture, and implement that architecture, are also of concern to EA. Hence the TOGAF ADM, for example, provides good advice on project-oriented implementation (if oriented mostly to IT-architectures), in its Phases E-G. (A practical problem is that it seems too many would-be EAs take little heed of that advice, preferring to hide instead in the safe comfort-zone of abstract architecture… We need to explain that the ADM needs to be executed as a complete cycle, all the way round from Phase A to Phase H, and onward to Phase A again – not solely an endless back-and-forth between Phases A-D!) Kevin Smith’s PEAF is useful for guidance on how to get started with setting up an EA unit and getting started with architecture-implementation. Plenty of other examples: process matters, exactly as you say.
The other side is that EA does need to remember that in business terms it’s primarily a decision-support function, not a decision-making function. Its business role is to advise “the management” on the available options for implementations, and on the probable value and consequences for each option. Like any other architecture-discipline, it should be able and willing to provide that decision-support right down into the detailed implementation. Yet it should not attempt to make or subsume business-decisions unless explicitly asked and authorised to do so. Once we’re clear on those relationships of mutual responsible and authority, then yes, anything ‘management-ish’ and ‘implementation-ish’ – and any and all of the “many other perspectives on change” – will also fit within the EA purview.
On the process side (i.e. BPM etc), much the same applies: their emphasis is process – reassessment, redesign, implementation and execution – but it also touches strongly on structure and purpose. In that sense, it’s clear that EA and BPM (and similar global-scope functions, as Alec Sharp described well in his IRM-EAC talk) must work closely together, to link business strategy to business execution, and make it work well.
As an aside, one of the most frustrating parts of the TOGAF ADM is that its Phase B ‘Business Architecture’ randomly jumbles together ‘anything not-IT’ into an almost unusable grab-bag, with little or no distinction made between high-level business-strategy, mid-level business-process and detail-layer process-execution. It’s one of the things that not only worsens the ‘business/IT-divide’, but also makes it much more difficult for BPM to work with EA – because BPM do need, and do use, those practical distinctions. A rework of Phase B into a proper layered business-architecture would help everyone in this space. But that’s another story, of course! 🙂
Hi Alexander – yes, a very useful distinction between ‘enterprise genotype’ vs ‘enterprise phenotype’.
(Also v.useful article, by the way – many thanks for the link. Also strongly agree with your comment: “BA is a part of Enterprise Architecture (EA), and usually BA is the least understood / developed / implemented part of EA” – hence the need for the crosslinks with BPM and the like.)
One possible danger is that we end up with too narrow a focus: both ‘classic EA’ and ‘classic BPM’ tend to be much too IT-centric in their emphasis, which in practice often puts their usefulness and validity into doubt. (Alec Sharp made this point strongly in his IRM-EAC/BPM presentation, ‘The soft-stuff is the hard-stuff’.) In effect, the artificial constraint on scope limits the understanding or awareness of the broader genotype, resulting in destructive distortions at the phenotype level. That’s one of the reasons why I insist that an IT-centric EA (as per TOGAF etc) or even a ‘business-centric EA’ (such as derived from Business Model Canvas etc) should not be permitted: we must instead use a holographic or whole-system approach in which everywhere and anywhere can and may be ‘the centre’, according to the needs of the context.
One other ‘red-rag’ term in your comment above was the word ‘predict’. We don’t predict. In fact, we can’t predict: the notion that we could do so is merely a sad delusion left over from the wreckage of ‘scientific management’. Sure, we can come pretty darn close to something that looks like predictability – such as through a determined Six Sigma effort, combined with IT-driven BPM – but we should never fall for the trap of thinking that because some part of the system is in effect ‘predictable’, therefore the whole of the system is predictable: not a good idea… Instead, we need to take a futures perspective: not scenario-planning, for example, but scenario-thinking, the ability to work with inherent uncertainty, rather than trying to delude ourselves into believing that we can ‘control’ it. A really crucial difference, that I fear way too few current EAs fully appreciate. But that’s just my opinion, of course! 🙂
Thanks Tom for the feedback and I fully agree with about “predict” comment. Sure, it is not possible to ‘control’ the future, but we should be able to prepare ourselves for different scenarios. In BPM I use the expression “scenario-planning” to emphasise that those plans/scenarios must be made explicit (see http://improving-bpm-systems.blogspot.com/2010/12/illustrations-for-bpm-acm-case.html). Maybe in my English, the expression “scenario-thinking” has meaning of being implicit. To be validated.
Thanks,
AS
Hi Alexander – we’re in a multinational industry, so if my English isn’t clear enough for non-native speakers, then it’s my fault, not yours. My apologies.
Didn’t help that I also didn’t quite use the right term. What I was thinking of was Kees van der Heijden’s ‘Scenarios: The Art of Strategic Conversation‘, so the better term would be conversation – co-creation – rather than ‘thinking’.
The position of planning is difficult, because the plan itself can give the illusion of a predictable world. (von Clausewitz’s military dictum that “no plan survives first contact with the enemy” applies in much the same way here.) Yet without a plan, we’re unlikely to know where to start. So the real aim – certainly in the EA space, perhaps less in the more production-oriented aspects of the BPM space – is to practice on planning, ‘as if’ the plan would be executed as per the specification – yet also be ready, at an instant, to change the plan. And to change the plan, we need to have a solid understanding of the overall strategic direction. It is concrete and explicit, yet necessarily fluid, ‘going with the flow’ and so on.
It’s a delicate balance, not easy to explain in words as such… but I hope that makes some degree of sense, anyway?
No need for apologies Tom — we know that EA and BPM do not have ‘commonly-agreed’ terminology yet.
I will have a look at that book.
Thanks,
AS