We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Enterprise Architecture Matters

Adrian Grigoriu

The business architect role and the enterprise architecture of tommorrow

Vote 0 Votes

We all agree that, ideally, there should be only one enterprise architecture (EA) that describes the overall business operation, technology and organization of the enterprise in integration. And to be able to properly operate cross-enterprise, the function that delivers the EA should report into the top enterprise management.  

In practice though, EA is more often than not, working, reporting and more importantly, delivering into IT. 

Hence, it is the "old" story of the two EAs. The current IT EA we have today and the target EA that, to speak in our own EA terms, we want and need to have. Thinking like EA architects then, how do we move from the IT EA of today to the full business EA practice? 

The minimal effort is to employ a business architect who reports into IT. I've recently seen a few positions of business architects which, in reality, were disguising business analysts roles, dealing mostly with requirements and process modeling. Moreover, the BAs were required to be TOGAF and ITIL certified and they indeed, reported into IT. 

The probability of success is poor though because IT has its own priorities, skill profiles and accordingly career prospects. The business architect skills simply do not belong in IT. 

An alternative perhaps, is to employ a business architect that does report into the top management and coordinates the whole EA effort in a cross functional effort. Because, while the executives do a good job in managing the enterprise today, what everybody misses is the synoptical blueprint that enables them to talk about the same thing, in the same language, in terms that have same definitions.

This architect, should rather be the overall architect of the enterprise at least because he understands the business operation and needs and occupies the position that controls the whole architecture, including technology.

This might work, had there been an overarching methodology that integrates other enterprise level developments with the IT EA in a single view and effort. In the absence of such a framework, occasionally, a brilliant individual, working and innovating hard may succeed from IT to develop a better kind of enterprise architecture. But the outcome would be hardly reproduceable since we lack a theoretical framework that offers repeatability, predictability, standardization and consistency to such developments.  

We need an EA framework that considers not only BA and IT, but also relates all enterprise level activities together, that is, corelates work in such functions like IT EA, BPM, Quality, non-IT architecture, strategy... 

Still, the business architecture (BA) know-how today may not be ready for prime time. We don't even agree on the definition. BA is often seen as a collection of activities such as process modelling, documenting capabilities etc all executed in isolation. Yet, we already have that in most enterprises and we don't call it business architecture. 

To sum up, this enterprise business architect should operate higher up in the enterprise hierarchy to cover the business architecture and integrate it with the technology architecture. He will ensure that it is the full blueprint of the enterprise that it is delivered rather than the IT blueprint.  And he will make sure that the audience is the whole enterprise rather than IT.

This blueprint would enable stakeholders model own parts with same conventions and constraints in the enterprise wide context. This would unite the enterprise in one coherent operation and development effort. The EA would be the collective cross enterprise design where everybody contributes to the same plan and goals, in synchronization. This architecture would enable people in the enterprise to do enterprise planning as a portfolio, would turn change reliable and ultimately, would make possible the implementation of strategy.

To convince the enterprise, the architect must produce results first rather than debates  To guide the eforts toward the same goal one must have an overall method and framework rather than rely on the excellence of a single individual.  

Yet, long live the EA IT architect of today because he is, today, the EA flame bearer! It is ironic though that with the advent of the IT cloud computing, the enterprise architect role will operate outside the IT, at least because the enterprise would employ outsourced, off-the-shelf business services,  the technology of which is hidden in the cloud.

As an uplifting thought, the business architect and designer of today's enterprise is the entrepreneur, because, before puting together the enterprise and  funding, the entrepreneur comes with the plan that describes the products, the markets, the business and operating models, the resources and forecasts of costs and profits to make sure that the enterprise will be viable. 

The overall business architecture, while not put on paper, still exists somehow in the mind of the entrepreneur. That is lost in time though when the enterprise grows.

See also this generic business architecture model, a framework for building the business architecture.


| Leave a comment


I feel as though your thinking process is locked into the word "architecture" and this is getting in the way.

If you use the phrase "operating model" or "business model" then the problem of how to get a business oriented EA - seems much less daunting. You would be unlikely to put the head of operating model design in IT. More likely, this person would report to the head of "operations" or the head of "business processes" or "transformation" or even "strategic planning.


my topic was "the business architect in the context of enterprise architecture". I thought that obvious.
What's also obvious is that you (perhaps Ashridge) are "locked" outside the world of business architecture and EA at your own peril.

I had a look at your web site. There is no buzz word missing: Change, Leadership, Strategy, Talent Management, Executive Coaching, supervision, responsibility, sustenability, MBA... except business and enterprise architecture.

Now, how do you think that in the future, one can properly do the management job rather than the artistic job you teach today, without an enterprise wide architecture to describe how the enteprise works for everybody at all levels, how a change impacts other parts of an enterprise what and where is everybody's role in the value chain of EA?

And there is no "head of operating model design" anyway.
The models are just coming from business, perhaps out of a collective effort, and are documented and enabled by EA. Their implementation is ensured by the transformation effort.

Hence, the reporting line for a business oriented EA function should be at least at the same level with, rather than reporting to the '"head of "operations" or the head of "business processes" or "transformation" or even "strategic planning' because it has to cover them all.

I think there is middle ground here. You are each coming from a different perspective and using different language to describe the same thing. I have started to reserve the "business architecture" and "enterprise architecture" language for use with other architects. When I am speaking with groups not familiar with "architects" and "architecture" I tend to use language that describes, in business terms, the problems, approaches, and results.

For example, since "architect" and "architecture" (regardless of the adjective you put in front) can be interpreted as "IT architecture" I prefer to use the word "business designer" and "business design". I do not even try to explain differences between and amongst business architect. enterprise architect, and technology architect.

When discussing the work to be done I talk in terms of innovation, strategic planning, developing and maintaining standards, policies, and target / reference designs.

When discussing the results I definitely talk in terms of business models, operating models, roadmaps and business cases. These are the terms the business already understands.

As the principle designers of enterprises, we (business, technology and enterprise architects) need to adapt our language to our audiences rather than forcing our internal language and structure upon them.


Dave, to make this more of a public debate see my next post in answer to your comment.

Leave a comment

Adrian Grigoriu blogs about everything relating to enterprise and business architecture, SOA, frameworks, design, planning, execution, organization and related issues.

Adrian Grigoriu

Adrian is an executive consultant in enterprise architecture, former head of enterprise architecture at Ofcom, the spectrum and broadcasting U.K. regulatory agency and chief architect at TM Forum, an organization providing a reference integrated business architecture framework, best practices and standards for the telecommunications and digital media industries. He also was a high technology, enterprise architecture and strategy senior manager at Accenture and Vodafone, and a principal consultant and lead architect at Qantas, Logica, Lucent Bell Labs and Nokia. He is the author of two books on enterprise architecture development available on Kindle and published articles with BPTrends, the Microsoft Architecture Journal and the EI magazine. Shortlisted by Computer Weekly for the IT Industry blogger of the year 2011.

Recently Commented On

Monthly Archives