OIO EA is a breakdown of The Handbook’s EA frame. The method, with the individual steps in each activity, is depicted below:
The OIO EA method focuses on the steps within the five central activities (marked blue-violet) – the steps from A1 to E3. The steps X1-X2 and Y1-Y5 are interacting with the core OIO EA method, and are also described here. These are however normally conducted by others than the ones responsible for the enterprise architecture, except for step Y3 EA governance, which is a step central for the maintenance of the architecture.
As for the OIO EA method, it is important to notice the following:
- It is an ongoing, iterative process to develop and maintain an enterprise architecture.
- The OIO EA method is a method, not an architectural framework. However a part of the OIO EA guide is an OIO EA framework. Output produced using the OIO EA method can be classified according to the OIO EA framework, the Zachman framework or other frameworks.
- The individual steps are not carried out in a pre-described order. The numbering indicates one that often will be appropriate (since the output of one step gives input to other steps). However, the order is not fixed. For instance, one can conduct the steps B5 and B6 before conducting the steps B1-B4. Likewise one can start on documenting the current architecture in the ”AS-IS” parts of steps independent on when the steps in A and B are conducted. However, the design of the future “TO-BE” architecture will require input from the A-B steps.
- Steps can (and will often) be conducted in parallel. For instance, the ”AS-IS” parts of the four steps C1-C4 can and should be done in parallel (to speed up the delivery). Even where there is no parallelism, it will happen frequently that one step leads to the modification of deliverables from steps already conducted.
- Only rarely are all steps in the OIO EA method conducted, the use of the method is adjusted to the specific needs. For instance, the focus can be on infrastructure consolidation. Then parts of step C1 and all of C4 becomes key. Or the focus could be on process optimization, in which case steps B3/B4 and C2/C3 are crucial.
Chapter 3 exemplifies how OIO EA can be used in a given scenario. A separate document describes other common scenarios.
- Not all output deliverables in a step are necessarily produced. For instance, C1 comprises two main parts:
– C1.1 describes the logical data model – as an extension and detailing of the business object model from B1.
– C1.2-3 describes locations and data flows between physical databases implementing the models described in B1 and C1.1.
These can be done rather independent of one another, both based on input from step B1.
- It is not an objective in itself to do Enterprise Architecture work. Hence, one should focus on areas where one with less effort needed arrives at the good answers for how technology should be used to achieve the business’ goals.
- The EA architect is a common actor for all steps A-E. Not necessarily as the driver of the step, but responsible for ensuring consistency across, and to identify opportunities for synergy, where relevant. In case of inconsistencies between deliverables (for instance that the proposed technology architecture does not properly support the future application architecture) the EA architect shall seek to resolve this. Typically, one will gather the architects who developed the deliverables, and see to find a solution.
When starting an EA project, aimed at establishing or modifying an enterprise architecture, one determines the specific use of the OIO EA method, as indicated in item 3-6 above.