The end of enterprise-architecture?
In terms of ‘means and ends’, what’s the end of enterprise-architecture – its real, practical purpose?
[Don’t worry! – this isn’t yet another round in those interminable arguments about ‘What is enterprise-architecture?’… What follows would apply just as much to IT-architecture, or business-architecture, or just about any other form of architecture, as it does to EA at a whole-of-enterprise scope.]
What got me going on this was a conversation with a colleague, who was pondering whether his new organisation needed an enterprise-architect – a full-time or part-time enterprise-architecture role. That they were going to need some form of enterprise-architecture was not in doubt; but the need for an explicit person to do that work was a bit less certain.
The more we looked at it, the more blurry it became. And then a kind of breakthrough: enterprise-architecture is a discipline, not a role.
To me, enterprise-architecture is a discipline – or set of disciplines, if you prefer – that revolves around a single core theme: that things work better when they work together, on purpose. (Okay, there are lots of nuances and ifs and buts and perhapses all mixed up in there, but that summary of the ‘core theme’ is close enough for now, yes?)
And the key point here is that this will only work well when it’s taken up as everyone‘s responsibility – not solely the responsibility of the person who has some variant of ‘Enterprise Architect’ in their job-title.
As with other ‘pervasive’ themes such as quality, security, health-and-safety, knowledge-sharing, environment and suchlike, it’s more of a discipline than a ‘job’. It’s sort-of a specialism, yes, but a specialism that in real-world practice looks significantly different from the mainstream specialist roles seen in job-adverts and the like. For example, it’s usually a generalist discipline – ‘go anywhere, work as directed’, rather than ‘work on these materials for these defined outcomes’. And there are few clear ‘deliverables’ for these ‘pervasive-themes’: the best we can do, or expect to do, is to make things somehow better in the terms of that specific discipline, with metrics that are often blurry at best.
The danger here is that if it does become someone’s role, someone’s job, there can be some unfortunate unintended-consequences. Of these, the most common traps are:
- the enterprise-architects interpret everything solely in terms of enterprise-architecture itself – and try to force everyone else to do likewise
- enterprise-architecture becomes regarded as solely the responsibility of the enterprise-architects – not as the necessary responsibility of everyone
When we put the two together, the risk here is that enterprise-architecture becomes both hated and ignored – in other words, exactly the outcome we don’t want…
[The equivalent applies to every other pervasive-theme, of course. I remember being on one of those team-building courses where the task was to get everyone over a high wall, against the clock, to protect them from some metaphoric explosion or flood at the end of that time. The person assigned the role of ‘safety-officer’ became so obsessive about safety – criticising everyone, stopping every action as ‘unsafe’ in some kind of absolute terms – that no-one got over the wall before we ran out of time: everyone ‘died’. And that does happen all too often in real-life, too: there were several tragic examples of this at Japanese primary-schools during the 2011 tsunami.]
What we really need – again, as with every other pervasive-theme – is for enterprise-architecture to become understood, accepted and enacted by everyone as their personal responsibility. In practice, what we need to make it happen are four distinct sets of activities:
- develop awareness of the pervasive-theme – in this case, enterprise-architecture – to explain why it’s important to everyone
- develop capability to enact the theme – otherwise it ain’t gonna happen, no matter how great the awareness may be
- apply capability for the theme in every aspect of real-world practice – because that’s where it actually happens, and needs to happen
- verify and audit what was done to enact the theme – so as to support continual-improvement on that theme
So yes, it’s probable that, right at the start, we’d need someone in the role of ‘safety-officer’ or ‘security-officer’ or whatever, to help everyone with all of this, and in chivvying them and reminding them why it’s important and why and how to do it. Hence, in this case, the role of ‘enterprise-architect’. And the need for that role is likely to continue on for quite a while, perhaps indefinitely.
Yet in doing so, we should never lose track of the real aim here – that the disciplines to support the outcomes of the respective pervasive-theme become understood as and are enacted in practice as everyone‘s responsibility.
In other words, the end of enterprise-architecture is that there is no ‘Enterprise Architect’ – instead, everyone is an enterprise-architect, in their own way, with and on behalf of everyone else.
Comments, anyone?
Very true indeed, I realized that while working with Cactus@bwin. We actually established the practice as just the support role to enable all others see and consider the EA perspective in decision making, strategy creation and execution. Sayin this, I don’t believe you can efficiently do without a role of EA, perhaps in a slightly different mode than usually understood. My point is that to make people understand the complexity and interconnectedness of the whole, it might be sound to put in place somebody who is capable of doing so. here our practice probably differes to the most I’ve seen. we focus most of our efforts to understanding the key roots of the current state. which in our case apart from the most obvious – crapy legacy systems – is – wait for it – culture, followed by org.setup and human behaviour. so we focus most on visualisation and clear communication (the most influencing outomes were a decision making tree looking like drawn by a 5-year old and disney-looking transformation roadmap). infographic that is lightyears from the form and content of traditional EA outcomes. And I ca see this role s very useful in almost any org of any size.
cheers!
Hi Ondrej
“My point is that to make people understand the complexity and interconnectedness of the whole, it might be sound to put in place somebody who is capable of doing so.”
Yes, agreed, and I’m not doubting it in any way at all. What I am suggesting is that whilst, yes, we may well have and need a person with ‘Enterprise Architect’ in their job-title, we should never lose track of the idea and ideal that enterprise-architecture is everyone’s responsibility.
Got what you mean, anyway, I quite dislike the role name anyway. Architect kinds of suggests an active (and perhaps sole?)participation in architecting an enterprise. Almost being an oxymoron considering every company is mostly about people, complex human behaviour, personal interests, emotions, skills… It’s to me so constrasting discussing lines among boxes by far too often meaning IT systems, much less so often some kind of business capabilites… well, I just have a feeling we are missing the point. With the role title, with what the role description usually covers. What about something more to the point? “sense-maker” or something like that?:)
Tom,
everybody contributes to EA, but an EA architect and a team manage the modeling, the design of the target architecture, the development process, the deployment, communications, standards, site organization, even the transformation… Not everybody can do that and you cannot do that by committee.
Tom, Great post.
A comment to Adrian: We might have to rethink the phased EA process. Michael T. Nygard has given a good talk about the subject, Architecture without an End State? http://yow.eventer.com/yow-2012-1012/architecture-without-an-end-state-by-michael-t-nygard-1256 . There is also an interview of him http://channel9.msdn.com/posts/YOW-2012-Michael-Nygard-Architecture-Without-an-End-State-Modern-IT-and-More .
Adrian, yes, understood – yet please see my reply to Ondrej above for the real point I’m making here: it’s about responsibilities, not merely about roles that enact those responsibilities. There’s a key difference there that many people seem to miss.
Lari,
Can you yourself, explain what “architecture without and end state” does mean? Then you perhaps might have to do some rethinking.
Adrian – I don’t know about what Lari might think here, but to me the notion of ‘architecture without an end-state’ means working with the reality that in a dynamic, continually-changing, continually-evolving enterprise there is no ‘end-state’ (not until the enterprise itself dies, anyway).
In that sense, I’d strongly agree with Lari: we do indeed need to rethink the old notion of ‘phased changes’, because otherwise each time we reach the ‘there’ that the specified design-phase expects, the designed-for ‘there’ is no longer there, but may be something else entirely. Under those circumstances, the notion of ‘future-state’ can be a dangerous delusion’; and even the concept of ‘present-state’ is problematic, because the ‘now’ has already changed by the time we’ve finished observing it, let alone written it down.
Tom, sure, the enterprise architecture effort continues indeed. But we knew that from the beginning. No news here.
Still EA is performed in iterations. The first one is probably the most consuming because the team, the governance the first EA… are delivered then. Then tt becomes architecture “as usual”.
Larry, himself, could have explained that before asking us to read references. It’s manners I guess.
“Sketching and visualising through drawing is what defines an architect” – Brian Edwards in “Understanding Architecture Through Drawing” http://archive.org/details/Understanding_Architecture_Through_Drawing_Malestrom
That everybody plays a role in designing/creating/realizing an (enterprise) architecture doesn’t make everybody an (enterprise) architect.
Peter –
“That everybody plays a role in designing/creating/realizing an (enterprise) architecture doesn’t make everybody an (enterprise) architect.”
Yes, agreed – though again, see my response to Ondrej above.
It worries me a bit that you, and even Ruth Malan, seem to making an exclusive-or out of this: either everyone ‘is’ the enterprise-architect, or only the person with that role in their job-title is, with nothing in between. Instead, think more carefully about the distinction between the disciplines of enterprise-architecture, versus the ‘job’-role of ‘enterprise-architect’. That distinction is crucial here – so please, please, do read the post again: I’m very clear about that point, and also the point about “that the disciplines to support the outcomes of the respective pervasive-theme become understood as and are enacted in practice as everyone‘s responsibility”.
The existence of a ‘special and different’ job-role of ‘Enterprise Architect’ can have serious unintended-consequences – as again described in the post above. If we do need that role to exist, we need to be careful to design for and mitigate those unintended-consequences.
Also, consider the nature and value of natural-emergence. In many (maybe almost-all?) natural contexts – such as a termite-nest, for example – there is clearly an architecture, but no explicit ‘architect’ as such: the architecture is emergent from innate collective responses to the context, with natural-systems and feedback-loops (e.g. pheromone-trails) to assist in maintaining awareness of the whole-as-whole. Hence, again, one of the points that arises in the post above is the need for possibly-artificial equivalents of those natural-systems and feedback-loops to help maintain people’s awareness of the context they’re in.
I perhaps also ought to add that that client’s business-context is a relatively-small (100-200-person) research-unit specialising in innovation in technical-engineering: in other words, a context with a very high level of unpredictability and uncertainty, and very significant governance-challenges – and also a very real risk of runaway costs (in almost every sense of cost) if the architectural and other issues are not appropriately managed. For a simpler, more stable context, yes, it probably would be easier to have an explicit ‘Enterprise Architect’ or ‘enterprise-architecture team’: but in that context, it really does need to be everyone’s responsibility, otherwise the wrong kind of chaos would inevitably ensue.
Tom, thank you for being worried. 🙂 But no need, at least, not as regards me taking a “nothing in between” position. For, indeed, I think there is a whole world of room for different interpretations and enactments of enterprise (and other) architecture.
Thanks for this discussion, and drawing me in. Tom, your exploration of the pitfalls/challenges/traps of having (enterprise) architects is an important contribution to the broader discussion, as is exploring what it would take to be effective as more responsibility for (enterprise) architecture is shared more broadly until ultimately the role of (enterprise) architect is done away with.
But just as important to the discussion, are the traps/challenges/consequences/downsides of _not_ having (enterprise) architects — not having that leadership, that focus, the bandwidth, the experience, etc.
Anyway. My response, perhaps over-zealous, was simply to try to add to that other facet of the conversation. I think both “sides” (horrid word in this context, but hopefully you’ll understand that I simply mean in a dialectic sense, so we lay out the consideration space) are useful.
There are forces that are being contended with, and their resolution will differ for different organizations, in different contexts. Helping shed light on what those forces and considerations are is important, and I’m certainly happy for this discussion, and all the tacks it has taken. 🙂
It is exciting, isn’t it, that we can learn so much in our field, and still have fundamental existential questions shake up our conceptions?
Hi Ruth – thank you for not being worried about being worried-about! 🙂 (And I hope you’d be equally worried with/at me if/when I seem to be going a bit too far sideways somewhen?)
Re “But just as important to the discussion, are the traps/challenges/consequences/downsides of _not_ having (enterprise) architects — not having that leadership, that focus, the bandwidth, the experience, etc.” – yes, agreed. And that is discussed (if briefly) in the post above: “Hence, in this case, the role of ‘enterprise-architect’. And the need for that role is likely to continue on for quite a while, perhaps indefinitely.”
Re “hopefully you’ll understand that I simply mean in a dialectic sense” – yes, I do indeed. 🙂 And yes, it is important that we “lay out the consideration space” in this way.
Re “There are forces that are being contended with, and their resolution will differ for different organizations, in different contexts.” – yes, exactly. The attempt to identify some of those forces is a key reason why I’m so concerned to draw this distinction between the disciplines of (enterprise)-architecture, versus a putative role/job-title of ‘(Enterprise)-Architect’ that enacts some (but, crucially, not all) of the aspects of those disciplines.
Re “It is exciting, isn’t it, that we can learn so much in our field, and still have fundamental existential questions shake up our conceptions?” – but of course! 🙂 Hence, again, delighted to see you here – many thanks indeed. 🙂
Tom
Helpful thinking, as per usual!
I have been thinking along similar lines, but coming from a different direction.
It seems that large organisations tend to need this role. So, I was interested in why small organisations did not seem to need it. Then I wondered when does an organisation start to need the role. This line of thinking caused me to think that enterprise disintegrity tends to grow as enterprises grow or change.
What if we were to focus on the creation of EA enabled enterprises such that, as they grow or change, they have designed in them the capacity to do so with greater integrity, eliminating the need for an architect to come and help fix it all up.
Thoughts?
Peter: “Enterprise disintegrity tends to grow as enterprises grow or change.” “Thoughts?”, you ask?
Well, quite a lot, of course! 🙂 But two that come straight to mind may be relevant here:
— Complexity is somewhat a function of size, but even more of the possible range of permutations of interconnection. (That’s one of the reasons that silos tend to develop naturally as organisations grow: their closed-off structures with limited interfaces reduces the number of possible point-to-point permutations.) Specialists can happily cope with almost any amount of ‘inside-the-box’ complexity, but tend not even to be able to see the ‘between-the-boxes’ complexity, which by definition grows exponentially (or some variant thereof) with the number of specialist ‘boxes’, which again tend to grow with size.
In smaller organisations (or, as we’ve discussed before, in the ‘small-countries’) people tend to straddle the boxes, simply because there aren’t enough people to do all the specialisms that would be needed. In those contexts, people tend to think somewhat architecturally, out of sheer necessity to get things working. But as the organisation grows, specialists can settle into a single’-box’ groove, and ignore the impacts or ‘invisible-interactions’ with anywhere else. That’s when a ‘specialist-generalist’ such as an EA may well be needed, to help people (re)develop that whole-of-context awareness again.
(There’s a similar kind of effect that grows with organisation-age rather than organisation-size: increasing complexity arising from interactions between (heavily-patched) legacy-systems, (often-undocumented) now-business-critical shadow-IT, and rapidly-changing business-contexts.)
— There are critical shifts that take place at each stage of growth, in roughly powers-of-12: 12^0 (single-proprietor), 12^1 (first explicit managerial-role), 12^2 [approx Dunbar-Number – see http://en.wikipedia.org/wiki/Dunbar's_number ] (key social limit, also first appearance of manager-of-managers), 12^3 (appearance of full middle-management layer, living solely in a world of information), and so on. Probably the crucial shift is at the Dunbar-number size, because that’s where natural/implicit person-to-person social-integrity and social-cohesiveness across the organisation start to break down: from that point onward, the integrity starts to need to be maintained by explicit means – such as through ‘pervasive-values’ roles such as Enterprise Architect.
Hope that makes some degree of sense? 🙂
To me, independent of the titles, the enterprise architect, or for that matter architect of any other artificial system, is above all designer of that particular artificial system.
So in real life in the actual enterprise architects are CEOs, or the ones (often external consultants) to which CEO is delegating the task to design the enterprise.
People who have the title of enterprise architect at work, usually do not have such mandate, and they are most often given the task to document the work of actual enterprise architects sometimes before, but most often after the fact.
What comes to the enterprise architecture in general, as certain disciplined way of doing things in enterprise, then I agree, that should be everybody’s responsibility — as keeping the hygiene.
At the same time, if looking at the enterprise architecture as set of specific techniques to handle changes in complex multi-faceted systems, then this I don’t see as relevant to everybody in the organization, but only relevant to these managerial roles which have responsibility over sufficiently large and complex area.
Alar: “So in real life in the actual enterprise architects are CEOs, or the ones (often external consultants) to which CEO is delegating the task to design the enterprise.”
That’s the position that Chris Potts takes in his book ‘recrEAtion’, and to a fair extent I’d agree with it, other than for one very important proviso: the CEO is the ‘enterprise-architect’ for the organisation’s relationship with the [shared]-enterprise – and not of the [shared]-enterprise itself. The organisation does not ‘possess’ the shared-enterprise, nor does it ‘control’ that shared-enterprise within which it operates: the distinction between organisation (bounded by rules, roles and responsibilities) and the shared-enterprise (bounded by vision, values and commitments) is often missed or misunderstood, but absolutely crucial here. Hence a key role for (delegated) enterprise-architects is to maintain awareness of that much-larger shared-enterprise, and advise the CEO and executive on how best to relate with it.
(Another way of describing the difference is that a CEO and executive will tend to have an ‘inside-in’ or ‘inside-out’ perspective, looking from the organisation to the market and the shared-enterprise beyond; enterprise-architects need to balance these perspectives with ‘outside-in’ and ‘outside-out’, looking at the organisation from ‘outside’.)
Your other points – ‘everybody’s responsibility’ versus ‘specific techniques to handle changes in complex multi-faceted systems’ – I’ll answer in my reply to Ric Phillips below.
It is interesting to see what criteria people apply to the legitimate use of the word / title of “architect”.
There is a key distinction which needs to be made in relation to architecting a human system vs architecting an inanimate system. For software, buildings, etc, the architect is involved in the envisioning and design of an end-product where the components are (relatively) static and their behaviour is (reasonably) predictable.
For human systems, the primary components are people and they have the capacity to override every decision that an architect might make. Hence, for human systems, one of the key success factors is the extent to which the enterprise owns the decisions about its architecture. This is not a requirement for other architects – you might say, they get it easier!!
My point is to strongly advocate that the criteria of sole or chief decision authority is not the test as to whether “architecture has been done or not”, and that even when others may be the ultimate decision authority, this does not mean that the architect does not have a legitimate, value-adding role.
Peter, while I strongly agree that Enterprise Architecture and Software Architecture are very different beasts, I must disagree that it’s because “the components are (relatively) static and their behaviour is (reasonably) predictable”. Environment, traffic, and the users themselves combine to ensure that ceteris ain’t never paribus (you might reasonably plan for expected, business-related spikes, but foreseeing the latest cute kitty video that everyone must download is much harder). It’s a different kind of chaotic (for the most part), but chaotic nonetheless.
Hi Tom, let me jump in at…
“enterprise-architecture becomes regarded as solely the responsibility of the enterprise-architects – not as the necessary responsibility of everyone”
And compare….
“Health becomes regarded solely as the responsibility of doctors”
“Justice becomes regarded solely as the responsibility of judges/lawyers”
The arguments for the functional requirements of a particular skill-set / body of knowledge formalised to a role or profession are not well made from the domain of culture and ethics.
Returning to the first analogue.
Having doctors is vital to health.
Having doctors solely responsible for health is insufficient to the best health outcomes.
Doctors, well, all health professionals as an aggregate, are far more effective when,
a) they take responsibility for sharing their knowledge and creating a culture of health.
b) individuals take responsibility for their own health and see the medical profession as a resource and partner in that task.
None of which supports a claim that we would be healthier without doctors or that having them necessarily leads to us neglecting our health.
The question isn’t only what are the organisational-cultural risks of having a role? The question is, can EA be achieved well solely as a result of organisational norms.
We have finance departments, CFO, auditors, reconciliation officers, and so on because while everyone in an organisation should be responsible for honest and rigorous accounting, budgeting, procurement etc – and organisations work hard to establish those norms – it has been discovered over and over again that when the accountant’s away the managers will play.
Before the imperative – “Should” be everyone’s responsibility, we have to ask, “can” it be. Is it something that can practically work as the effect of generalised norms – even if structured by policy, process and reward?
I don’t find your argument compelling. I haven’t however discounted your conclusion entirely as a result.
How would EA work? Am I detecting some emergence or neo-evolutionary compelxity theory here? Do you see architecture as an outcome of self-organisation in a complex system adapting under stress? Role-based EA as a bet on discredited punctuated-equilibrium theories of organisational development?
The deconstruction hasn’t won me over. I am wondering what the alternative construction is.
Cheers.
Ric – nice use of deconstruction-via-parallels! 🙂 And (no surprise there… 🙂 ) a good challenge, too… [Self hides in corner for a moment to adjust metaphoric clothing…]
Okay. You’re right, I need to tweak that description a bit – or perhaps more than just a bit…? Here goes, anyway.
I’d still assert that ideally and ultimately pervasive-themes such as health or justice [your examples] or enterprise-coherence [John Gotze’s term for the outcome of enterprise-architecture] is everyone’s responsibility – or, more specifically, each person’s personal responsibility, both to themselves and to/with the collective.
It’s extremely important, though, to notice the words ‘ideally’ and ‘ultimately’ – because it [almost] certainly ain’t gonna happen right from the get-go, it’s something we need to build towards, and towards that respective ‘ultimate ideal’.
The second point to note is a simple deconstruction of ‘responsibility’, as ‘response-ability’ – the ability to choose [and enact] appropriate responses in terms of the respective ‘ultimate ideal’. When we start off, people’s ability to choose appropriate responses – or even awareness of the [shared] need for such responses – is likely to be somewhere between low and non-existent. Hence why those four sets of activities described in the post above:
— develop awareness of the pervasive-theme
— develop capability to enact the theme
— apply capability for the theme in every aspect of real-world practice
— verify and audit what was done to enact the theme
Which leads to two roles (two layers of role?) for ‘proponents of the theme’ – in our examples here, respectively doctors/nurses etc, lawyers/judges etc, and EAs etc.
The first role is essentially about coaching, much as above: help people understand why the theme is important, help them build their capability, provide them with some hand-holding during execution, and help to verify and audit – all whilst reminding people that it’s everyone’s responsibility, not just that of the person doing the coaching.
The second role should only happen as the organisation gets larger and/or as the complexity for the respective pervasive-theme increases beyond what most people would expect to be able to cover within their own work. This where we start to get the specialists in the respective-theme: the health-specialists (doctors/nurses etc), the justice-specialists (lawyers/judges etc), the coherence-specialists (EAs etc) and so on. (Some of those, as we see especially with EA, need to be ‘specialist-generalists’ – they specialise in linking things together.) The crucial point, though, is that even though there are now specialists doing specialist work for the pervasive-theme, the overall responsibility still remains with everyone. If awareness of that fact ever breaks down, we very quickly end up with a dangerously-codependent structure, where the specialists blame everyone else for failing to play their part, and everyone else blames the specialists because ‘it’s their responsibility, they’re the specialists’ – as we see with disaster-areas such as the ‘architecture-police’. (As I put it in the post above, under those circumstances “enterprise-architecture becomes both hated and ignored”.)
I hope that makes a bit more sense now? – if not, yell, of course… 😐 🙂