#entarch #JohnSeddon People sometimes describe the value of enterprise architecture (EA) in terms of the battles of enterprise architects against narrow or short-term thinking from various stakeholders. (See my post on the Future of Enterprise Architecture.) Describing the value of EA in these terms largely consists of anecdotes - either actual money that was supposedly saved thanks to the timely intervention of enterprise architects, or hypothetical money that might have been saved if only the enterprise architects had had more power and proximity. This gives us the notion of the EA-as-realist, who earns his/her keep largely by stopping ill-conceived initiatives, saying No to pushy vendors, and producing economies of governance. (See my post on EA Archetypes.)
More generally, people may describe the value of enterprise architecture in terms of things that supposedly only EA can do - things like vision or business structure. But there are many organizations whose leaders are perfectly comfortable and competent in these things - for example, I imagine it would take some nerve for an enterprise architect within Microsoft to try teach Ray Ozzie something about structuring a collaborative and innovative organization. (See my post Who Architects the Organization?)
Alternatively, enterprise architecture simply takes up a different position of vision or business structure, and its value depends on being able to mobilize a healthy and constructive argument. So maybe, this is just a thought, you could offer Ray Ozzie a "different perspective" on business structure and see how far that gets you.
The implication always is that EA isn't a viable system in its own right, it merely contributes to the viability of some larger system by correcting some classes of failure or lack. In other words, the value proposition for enterprise architecture is driven by what John Seddon calls "failure demand". According to a Seddonite view, enterprise architecture probably seems like a kind of back office function, and it would make a lot more sense just to reengineer the larger process/system so that it doesn't generate this kind of failure demand in the first place.
(That last paragraphy may cause a bit of cognitive dissonance with my Seddonite friends in the enterprise architecture communuity. I look forward to some healthy and constructive argument here.)
And if there is a maturity path for EA, as some EA experts suggest, then the mature state may be one where "enterprise architecture" is practised throughout the organization, rather than located in a separate organization unit whose viability and value seems to be so problematic. In other words, formal enterprise architecture will wither away. Yes?
Richard, you discuss the value of EA as seen by different practitioners. And then you debate that "if there is a maturity path for EA, as some EA experts suggest, then the mature state may be one where "enterprise architecture" is practised throughout the organization, rather than located in a separate organization unit whose viability and value seems to be so problematic. In other words, formal enterprise architecture will wither away. Yes?"
ReplyDeleteThe only value EA intrinsically adds is in documenting the current and future states of the Enterprise thus enabling the stakeholders to add own value in using this information to roadmap, plan and transform the Enterprise in alignment. Many EA practitioners focus though on solely one or two potential benefits of the EA, like strategic planning for instance. This indeed creates dissension as this work is already done by somebody else in the Enterprise. The role of the EA function is to initiate, correlate and align stakeholders' efforts to document the Enterprise and implement change and strategy rather than do the work for them. So the EA is achieved through the whole organization but is coordinated by the EA function according to a documented EA and framework.
Adrian
http://www.enterprise-architecture-matters.co.uk/home
Thanks Adrian
ReplyDeleteYou suggest that EA only adds value by documenting stuff. The documentation or modelling is presumably a means to an end, rather than an end in itself. I'm guessing that your word "intrinsically" is an improtant qualifier here, helping to distinguish output from outcome.
And you may have noted my suggestion (in Value of models) that the stuff EA needs to document isn't just AS-IS and TO-BE models, but sense-making and navigation models as well.
In terms of outcome, I suspect that the value of EA (if any) has to be understood in terms of things like coordination.
But that means there's a serious problem for EA if it doesn't have a robust theory of coordination.