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.
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 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 stakeholders.
- EA needs to keep the 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 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 needs to 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 are 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 a Practical Tool
EA has two
components, blueprints and change management strategies. The EA blueprint
includes the artifacts (business models, structure, etc) to execute the business
strategy or describe the IT environment being proposed to support business goals
and operating approaches. The change management plan would comprise migration
strategies and tactical plans, engagement strategies/implementation models and
a robust feedback/enhancement cycle.
- Design tool; Focus on the fundamental elements 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 the 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 lose sight of the fact that the practice is called EE-Enterprise Ecology, not EE Enterprise Engineering.
- Communicate tool: 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 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.
- Problem-solving tool: 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, then the problem owner's team. Secondly, state obvious solutions with a completely different team, then 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 to ‘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 points 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 the “ivory tower" approach which is not agile to adapt to the real-world changes.
0 comments:
Post a Comment