Enterprise Architecture typically represents ' why you do or what you know', how do you ensure you are also aware of 'What you don't know' in the process of drafting an EA blueprint. An EA can only be complete for an instant. The next instant the world has changed, and so the EA has to change. Thus, is EA ever completed?
1. The Purpose of EA
The aim of an EA must be to define, implement and refine the overall architecture on a continuous basis.
- EA is not about Documentation. It is
about Providing Direction, so that decisions can be made, executed,
and measured. If EA has been treated as a purely technical exercise consisting of
completing documents, then it will not be effective. It is not about the
documents, it is about identifying the major enterprise issues THAT MATTER
and developing strategies for those - in collaboration with business
- EA need Keep Focus on Key Issues that Matter: EA is about providing direction, so that decisions can be made, executed, and measured. Play multiple action scenarios through the architecture. This can exercise all layers of architecture (and show completeness both within the layer and between layers). But how do you keep engaged with the business? They generally will not have the stamina to help you create a "complete" model. They tend to be issue-focused. Thus, EA need have focus.
- EA Provides Systematic Approach to Solve Business Problems: First, identify the business problem and eliminate all non-relevant perspectives. Next identify all relevant guided statements or principles any stakeholder issues with regard to the business problem at hand. The combination of all guided statements and principles defines a solution space for the business problem you trying to tackle. At this moment in time the prerequisites for the solution are globally known.
- Technology Waves Continue to Push EA
Forward: One of the goals of Enterprise Architecture is to guide
technology evolution driven by business direction and business environment
change, therefore by its nature EA is a never ending process. EA is
portrayed as an iterative process, therefore you may approach the
completeness infinitely closer but never reach the point where you call it
complete and done.
2. EA as Practical Tool
EA has two components, blueprints and change management strategies. The EA blueprint includes the artifacts (business models, structure etc) to execute business strategy, or describe the IT environment being proposed to support business goals and operating approach. The change management plan would comprise migration strategies and tactical plans, engagement strategies/implementation models and a robust feedback/enhancement cycle.
- Focus on fundamental element of the meaning and definition of architecture - the art and science of design and structure This encompasses both the macro-level - the master-plan of the organization, where the organization is going, it's place and role in its community (market, shareholder, customer, staff) and the micro-level upon how the functional and service operations are designed for 'fit' and 'function' in this master-plan. EA should not loose sight of the fact that the practice is called EE-Enterprise Ecology, not EE Enterprise Engineering.
- Being good enough to communicate,
make decisions from and move on to the next step of usage. "Never
make an architectural decision until you need to do so". More
seriously, the blueprint should be complete to the level that allows
detailed solutions work to start during the execution of the change
management plan. The change management strategy will include
migration/implementation plans and engagement models will provide
direction on how to realize the target IT environment. The feedback cycle
would be the mechanism that would allow the EA to be enhanced to deal with
the things that you didn’t know about when you first started.
- EA Orchestrate Multiple Solutions: When
defining EA as all possible for a specific business problem, the universe
of discourse is perhaps too large. However, It's crucial to make a
distinction between obvious solutions and out-of-the-box solutions. First, use an out-of-the-box method to identify extra-ordinary solutions with a
completely different team, than the problem owner's team. Secondly state
obvious solutions with a completly different team, than the problem owner's team. Confront the problem owner's team with the outcome of both sessions.
Cross balance all comments into the solutions and you have probably
touched all possible solutions.
3. A Useful EA is a Living Thing
A useful EA should be a living thing, a set of shared strategies, trying to define the completeness of an EA is trying to make it into an artifact of precision. It is not.
- ‘Completeness’ is not equal ‘done’. An EA will never be done, but completeness is quite a different matter. Completeness is relative to the organization that is served by the EA. If the organization finds value in simply retaining data on the business processes, infrastructure, and data architecture, then so be it. That is a complete EA. If the organization also finds value in tracking other aspects or domains, then adding additional layers is a necessity.
- EA solutions should only be complete enough to define and plan the solution strategies. It is complete when you have identified and vetted solutions to all of the most significant challenges that the enterprise faces and that business processes or systems can help to solve. It is a waste of time to fully elaborate solutions at an EA level, as that should be left for detailed design efforts. Too much EA focus is on dotting all the information using various framework approaches which encourage one to focus on completeness and rigor, and that is not what is needed in an effective EA. EA should be about business process and technology strategies, not a morass of details. What is needed is understandability, consensus, organic, and mature.
- Agile Mindset & Methodology: there are possible measures to test how close EA is in terms of coverage, effectiveness and maturity at certain point of time. An EA can only be complete for an instant. The next instant the world has changed, and so the EA has to change. That is why so many waterfall-based projects have failed - by the time anything deliverable was produced, the business and its underlying market has moved on. An overarching EA with "solutions" for all the business functions is “ivory tower” approach which is not agile to adapt to the real world changes.