Enterprise Architecture focusing on business rather than IT alone - Via Nova Architectura

EA is an IT term. It initially came from Zachman. Then it was adopted by the IT community in branding their technologies Enterprise wide: Enterprise Java, EAI, ESB... So why not Enterprise (wide) Architecture? Well, there is no "IT" in the name because it looked evident to them.

The role called Enterprise (Java) Architect has also been introduced by IT to denote an expert programmer that was able to design SW on top of complex application packages and their many many interfaces, like Java, .Net. But this adds to the confusion reigning today, about EA. Many still think of EA in terms of software.

It is likely that the term architecture, borrowed from the construction industry, came from IT system design, where the diagram of the logical system blocks and and their interconnections was coined architecture.

The business vocabulary does not have an architecture term. There is no concept of architecture in the business domain, in my opinion. Business uses Value Chains, business models, process maps...

So the EA concept comes from IT. More, the design methods come from IT: structure analysis, OO... IT can do architecture work but it can hardly do EA without business knowledge and a business architecture. EA is mainly designed by IT for IT.

EA has a high penetration though; its potential was understood by business due to the promise in the name. Still, it delivers little, since most people have to work out first what that is, then its scope, what framework to use etc. The Enterprise specific work is only done after that.

So EA is an IT term, but with a great promise that does not escape the business people. As such it was also adopted in the larger business context of the Enterprise. Business Architecture and BPM are part of the EA (taken in the context of the Enterprise rather than IT alone). Zachman's matrix proves this and I guess we all know it.

EA, as a term, is too good to be abandoned to IT, I believe. Anyway it would be hard to abandon the name in practice. "EA" is currently used without qualification and discussions always arise on the surrounding scope. We should qualify EA with: Enterprise IT architecture, Enterprise Business Architecture, Enterprise people architecture... Business, IT, People are in fact layers in most EA frameworks.

EA, ultimately, is becoming, from an IT centric activity, a coordinated set of various activities: IT, BPM, Six Sigma, organization design... IT cannot really cover alone business processes for instance. Business knows them best and analysts do it. Six Sigma would look into processes IT would not care about because they are performed by humans. Organization design and alignment to business architecture should be another EA activity done by business.

The Chief EA architect should report high up and coordinate all EA related activities like BPM, Six Sigma, IT architecture, alignment of technology to business and strategy...

Reacties (7)

	Geschreven door Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken op 25-10-2009 20:13
	Hi Adrian In my blog regarding the relative absence of women in our profession, Jan van Til and I came to the conclusion that "architecture" probably should be performed by multi-disciplinary teams rather than by one "hero", "sheep with 5 legs (Dutch saying)". Of course the context of that blog was completely different from the context of your blog, but I still think that this is an important insight. The question I would like to ask is therefore: what disciplines are needed to make an enterprise architecture to a success? We, the IT architects, tend to refer to the others as "business people". You do that too. However these "business people" may be a highly differentiated group. Depending on the type business, it consists of SME's who know the core business processes very well. next to that there are probably financial experts, marketing experts and many other disciplines involved in executing the core business processes. Next to that I wonder to what extent "THE BUSINESS" is interested in an enterprise architecture. After all this concept has a somewhat "static" connotation to it, whereas e.g. product lifecycles tend to be very dynamic and dependent on the needs in the market. If we are lucky the products of a certain business are composed of a number of atomic, common attributes that can be captured in an architecture. Also processes may need to change, e.g. as a result of changing conditions in the market or of mergers and acquisitions. How do we deal with this inherent controversy? Report

	Geschreven door Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken op 26-10-2009 15:19
	Hi Lydia, I believe that to succeed EA needs to correlate and coordinate the activities and teams in fields related to the commonly accepted EA layers: * Business: efforts for process improvement like BPM/xSigma/TQM and Business Architecture in general (Business Models, process frameworks, business maps) * Technology: in IT and non-IT Architecture design, roadmapping and strategy * Organization: business management responsible for organization improvement and alignment to the business needs But in the end, all stakeholders would become involved, having a view of interest, a stake in the EA. The EA architect would provide such a navigable framework where all the artefacts, designed and owned by stakeholders, would fit in framework placeholders, subject to constraints and guidance imposed by it. EA needs to be lead by an overall EA architect having an understanding of all EA layers: business, technology and people organization. The E Architect should have a high enough position in the hierarchy to have access to top management and authority to act rather than advise only. Solely at that level an E Architect would have visibility over the whole Enterprise and be able to discover and propose common functions, eliminate duplication between business silos, improve end to end processes... An Enterprise Architecture board, a governance structure close to the top management level, would still make the key decisions. The concept of EA is self selling but the current results turn its appeal down. In any case, it would be a benefit for business to have a single blueprint, eventually an one page E architecture, they can all refer to and debate upon, and a framework enabling the navigation of a process for performance, technology resources and people responsibilities analysis. At a high abstraction level, EA is static. After all, the Enterprise does not change too fast. At lower levels of detail, the EA becomes dynamic, always updated and relevant if the solution architectures are integrated in the EA and business stakeholders gain ownership and responsibility for their own \\\"architectural views\\\". The EA work is then delegated to those in the know and with a legitimate stake and acountability for it. Report

	Geschreven door Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken op 30-10-2009 23:09
	Hi Adrian, There are two points in your posting that I would like to react to. If I look at your view on what constitutes an enterprise architecture, I get the feeling that the road towards an "enterprise architecture" is pretty instrumental; that the aspects of "art" and "uniqueness" are missing from this view. This is not uncommon; the TOGAF view on enterprise architectures, to which your view is probably related, is equally instrumental. And also the various classes that I have taken and that I am teaching on IT architecture are aligned with this view. However an enterprise is not only a set of business processes, supported by a set of applications, running on an infrastructure landscape. The uniqueness of the enterprise, its colour, logo and values should also be captured in it. You mention the need for having one single blueprint, something that people can refer to and debate upon [and that gives them a sense of belonging]. That says it all, doesn't it? If the unique soul of an enterprise weren't important, all insurance companies could be moulded after one reference architecture such as IBM's IAA, all telecom providers could be moulded after the eTOM reference architecture for Telecom. The fact alone that this is impossible proves that there is more to it than just setting up a logically sound framework. This brings me to my point. If I am right we will need a whole set of complementary skills to make an enterprise architecture successful. The second point worries me even more. In your vision there is one lead enterprise architect who has the supreme overview. [I’m sorry that I cannot help thinking about the paternalistic white-bearded God figure that Robert Crump has been drawing] Where are we going to find this hero, this almost divine individual? Isn’t it time we start thinking in terms of multi-disciplinary teams where each team member’s skills have their place and are equally valued? Of course, some sort of coordination is no luxury in such a team, but that is different from omniscience. Report

	Geschreven door Adrian Grigoriu op 31-10-2009 15:19
	Hi Lydia, I cannot argue with your finding of "instrumental" since I don't know what you based your conclusion upon. It might be the fact that your are responding to my other post (Why .., a framework?) or that you, in general argue against such a common approach as TOGAF. It might also be the result of your more artistic approach to the IT EA, crediting the Enterprise with a soul and colour. I am not using TOGAF, as you may have assumed, I don't even recommend it. I use an own method, described in my book (reviewed at http://www.angryarchitect.com/?p=156) which covers, in particular, business architecture and then IT as opposed to TOGAF. The emphasis is on business so I doubt it can be used for IT teaching alone. Architecture, by definition, is about blueprints. To start with, I recommend a Single Page Architecture. The stakeholders, in business and IT, quite happy with it, use this simple view mainly to align their vocabularies and issues. And that says something. Then the framework also allows for views like you mentioned, and an unlimited number of others, as for instance, people and organization views. Here you may even describe the culture of an organization (a book chapter treats cultural issues). The framework permits the alignment of the organization, technology and business architecture, which is more than a business process framework like suggested. (...eTOM) I agree with the "unique soul" of an Enterprise. I would call it the specific of an organization, consisting of vision and strategy, business and operating models, values and culture... which can be adressed and described on top of a true EA framework. Cars have their unique soul even though they are all built on the same conceptual structure. Your creative comparison with a white beared figure reminds me of Zachman, the father of EA (some people say)! But logic says that if EA is more than IT, then its management has to sit above all activities it coordinates. And equally obvious is the fact that this leader should understand (be omniscient in) the activities he/she supervises (BPM, IT...) unless a people manager is preferred, as so often happens these days. Report

	Geschreven door Lydia Duijvestijn op 31-10-2009 18:17
	Hi Adrian Thanks for pointing me to your book. From the book review I conclude that you want to come up with something different. My apologies for not being aware of that and making the wrong assumptions. I hope you forgive me for being prejudiced! I did not mean to offend you, just to have a sparkling discussion about a subject that interests me. Let me tell you a bit more of my background. I am an IT architect / performance engineer and based on that experience I am mostly involved in pretty \"down-to-earth\" IT problems. I have been educated in IBM Enterprise Architecture Consulting and related methods. I studied a previous release of TOGAF through self-study. The method that I know best is really about enterprise IT architecture and describes in detail the road towards the blueprints but leaves it to the reader how they should capture those things that appeal to the enterprise. While practising architecture engagements in the past it has struck me that many of the products of these engagements ended up in a drawer and did not seem to reach a large audience. This suggests that (a) they were not communicated correctly or (b) something was missing from them or (c) the enterprise was not really in need of them. Now that I know better where you come from I would like to ask you the following question: Does your multi-faceted approach appeal to larger audiences, does it avoid \"ivory towers\" and \"drawers\" and if the answer is yes, can you tell me more about how you achieve that? - (i.e. make me sufficiently enthousiastic to start reading your book) Report

	Geschreven door Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken op 31-10-2009 18:29
	P.S. From my own experience I can only agree that it would be phantastic if there were a clearly described EA that encompasses both processes, organisation and IT aspects; it would be even better if there were an ominiscient leader who could really explain what it contained, but I also know that it is tremendously hard to find such Da Vinci-like all-round professionals. Or do you have a different experience? Report

	Geschreven door Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken op 31-10-2009 22:52
	Hi Lydia, You can find extracts of the book, a presentation and a blog where I describe various aspects for the past three years. at http://it.toolbox.com/blogs/ea-matters/. A revision of the second edition is at http://www.bptrends.com/publicationfiles/03-08-BR-Ent-Arch-Grigoriu.pdf An IT only architecture cannot show the big picture of the Enterprise because processes are executed by people and other non-IT technologies. For the big picture, one needs the business structure and its works i.e. the business architecture. Business and IT architecture are both necessary for the Enterprise description and more they have to be aligned. To achieve a unified Enterprise view, EA coordination under the same management is then a must. The EA architect may be hard to find but the CEO should be even harder to find and it's not. Report

Alleen geregistreerde gebruikers kunnen reacties geven.
Log in of registreer.

[ terug ]

Via Nova Architectura is not responsible for the content of blogs, but authors and readers are asked to adhere the following guidelines. Authors are strongly encouraged to check facts, cite sources, present balanced views, acknowledge and correct errors. Respect copyright, fair use and financial disclosure laws. Please do not disparage organizations, or individuals. Being critical of someone's practice is acceptable, when it is done in a professional manner. Prevent usage of marketing statements. Comments should be relevant to the specific post they are attached to. Spam, flaming, personal attacks, and off-topic comments are not permitted. Readers are requested to notify Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken of any violations. The editor holds the right to remove any statements that, in the editors opinion, infringe the above guideline(s). The author receives a notification of this action.