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

Enterprise Architecture myths

Vote 0 Votes

True, most if not all myths contain a bit of truth, but the key word is "bit".

Myths you heard about:
That you need to "sell" Enterprise Architecture.
Do you? For one, the concept is straightforward. Anyone understands a plan or a city map and everyone wants a "schematics" of the Enterprise.  EA is self selling.
But are those loose IT diagrams you are going to provide to your business really delivering the sold benefits? Selling promises you may not keep will not help your effort or the EA. Can you deliver on your promises?
That EA is about strategy. 
What about documenting the day to day operation of the Enterprise to reduce duplication and unnecessary complexity, to improve and optimise the Enterprise,  what about describing the key processes and technology to enable tactical change. Strategy existed long before and will survive without EA. The EA is the Enterprise blueprint for managing complexity and change. It enables strategy specification and execution but it is more than strategy. EA is related to many other Enterprise disciplines but it does not replace them, it just works along them.

That you have to do the To-Be first.
How would the target Enterprise state look should it be not anchored in the reality of the current state? Do you suggest discarding your present systems and processes? Are you committed to a revolution, i.e. starting from tabula rasa and abandoning current investments, rather than to an evolutionary path departing from the existing state? At least, you get rid of the gap analysis phase. And soon after, when the To-Be becomes the As-Is, would you be ignoring it as well, in the strategy development cycle?

That you need an Architecture Review Board.
You definitely need a decision forum to sanction process, architecture and technology change. But the EA strategy will be the Law book for their judgments. Without the EA the forum cannot properly function. Care should be taken though not to duplicate the tasks of the existing governance boards.  

That architecture principles are key to EA.
In my mind, there are just a handful of useful architecture principles. And those are already known to whom it matters. Any more than a handful and we would have a problem employing them. Architecture Principles are there to guide our architectural choices and design. Usually they come mingled with principles that have little to do with architecture. 
How are you going to use the principle, for what decision or purpose? This is a question that you should answer before producing "the principles". Otherwise they would be quickly buried in the graveyard of EA artifacts that no one ever uses. 

That we do not need an EA framework.
How do we make sure we deliver an EA, the same EA? How can our effort be predictable and replicable? Does every EA architect need to concoct an own framework? An EA framework consists of a frame/chassis on which the EA artifacts mount on to construct the whole. The whole can be broken into parts as such, that can be documented or designed independently. It helps us manage complexity. But if you don't have a proper or a single one then you may have to go on your own. An extended framework would consist of the development process and governance best practices.

That we have EA frameworks
We have a process framework like TOGAF (found useful by IT folks unaware of project management good practices), a cognitive EA approach such as Zachman's and its clones, and other frameworks often consisting mainly of acronyms such as POLDAT. Also there are specialized frameworks for the public sector (FEA), not generic enough to be used the business sector and design methodologies like D/MoDAF... for the defence industris and so on. But it is still a matter of debate if they returned results or are suitable to your purpose.
Imagine a manufacturer having to produce a car using a process like TOGAF or a framework like Zachman! They don't even describe the parts of an Enterprise.

That EA is about business rather than IT.
That's true, in theory, but, in practice, most if not all EA groups are part of IT and are tasked to deliver a technology EA. Nevertheless, without the business view, the IT architecture explains little and has a very diminished audience. Which is what happens. 

That the Cloud has an impact on EA
It does but no more than anything else. The business blueprint is about the same except that you don't care about the insides or the How functions are implemented. The infrastructure is abstracted in terms of servers, storage and networking. The applications becomes a business service. Indeed, you have to integrate the business service into your landscape.

Here is a framework called GODS - FFLV. GODS stands for and describes the key parts of an Enterprise (Governance-Operations-Development and Support) while FFLV illustrates the components of the framework: Functions, Flows, Layers and Views. All integrated in one. It comes with a metamodel, functions and flows maps, Business, Technology and People layers, IT technology architecture template, development process, governance best practices. And many more. 

Views welcome.


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