The connecting thread in the OIO EA method is to secure the bridge between business and IT. Read more about this and see three examples how to deal with this.
The OIO EA method forms a frame which should always be adjusted to the needs of the individual organisation, and taking into account what already exists on the business side and on the technology side.The prime purpose of OIO EA is to ensure that decisions on technology and it-projects are well anchored in the objectives and strategies of the business, and helps achieve these.In brief, OIO EA shall be used to prioritize and justify all major technology investments made by an organisation.
The connecting thread in the OIO EA method is thus to build the bridge between business and information technology. Below is given an example on how this can be carried out, in a specific scenario.
Example: OIO EA used for Infrastructure Consolidation
Scenario: Two or more organisations are to be united, and different infrastructures consolidated.In this scenario the focus is on ensuring the fast establishment of the basic infrastructure, so that it might deliver the more basic services and at the same time support future applications – though these may not yet have been defined precisely.
OIO EA can in this scenario be used as described below (red arrows indicates that the future “TO-BE” architectures are being defined at the area where the arrow ends; blue that the current “AS-IS” architectures for where the arrow ends are being documented; and stipulated lines that the step is only carried out to a certain extent):
One starts in step A3 to define the adjustment of the OIO EA method to this scenario, as indicated here, only with more detail on the output from the individual steps.This is included in the project charter in A4, where project activities, timelines and responsibilities for each of the steps are defined.
After this, the core of the EA project is initiated.Notice that it is desirable – and possible – to have a large extend of parallelism, in order to speed up the infrastructure consolidation:
At the technical side one immediately starts the documentation of the current architecture (blue arrows). Even here, it is possible to document the current application-, service- and technology architecture in parallel. The technology architecture (C4) will get most attention, but it is necessary to have a certain understanding of which technology requirements the current applications (C2) and services (C3) poses on the underlying infrastructure, in order to be able to meet these in the future architecture.
At the strategy/business side one will, to a certain extent, make sure that the goals and strategies of the business are documented, to ensure that they are fresh in mind. Likewise, one will to a degree describe the business services that will be delivered in the future (B3). These can with advantage be further specified by selecting use cases (B5) and workflows (B6), although these two steps should not form a major task. More important in the business activity is to define which future locations and organisational units (B2) the future organisation will have, and thus which the future infrastructure must support.
When the current technical architecture and the future business architecture are both well documented, the work on designing the future infrastructure begins:
One will, to some extent, draft which future applications (C2) and future services (C3) need to be supported by an infrastructure. This is not to define them in much detail (like functionality, specific choice of software packages, data exchange formats, etc.), but merely to uncover the requirements from the future applications and services to the future infrastructure – development environments, network structures, etc.
After this is defined the future technology architecture (C4) shall be defined – i.e. network, operating systems on clients and servers, infrastructure services such as email, intra/extranet and portal technologies, database technologies, development environments, etc. This technology architecture will be defined rather thoroughly, with precise specifications of infrastructure topologies and choices of technologies and technology standards for the individual nodes (building blocks) in the topologies. It will also be most relevant to specify system management and security aspects of the infrastructure.
The project now continues with a gap analysis (D3) that compares the current technology architecture and the future, and based on this defines a migration strategy (E1) and subsequently a detailed migration plan (E2), describing migration projects and their relations, and estimate resource needs.This can with advantage be combined with a consequence analysis (E3), which among other identifies organisational aspects to be addressed, although these aspects may not be part of the implementation of thetechnology architecture.