Enterprise Architecture myths

Enterprise Architecture myths

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.
Source: ebizQ

Related Posts:

 

Comments are closed.