Nobody would imagine the construction of a major building today without the preparation of a sound architecture and methodology to ensure the attainment of business objectives (for example, to serve as the corporate head office, conserve the environment and maximize the comfort of users) and the coordination of all the different players involved in the construction work (bricklayers, electricians and so on).

In contrast to the building housing a business, its software is intangible and cannot be seen. This increases the difficulty, but like a building, software requires a sound architecture to assure the attainment of business objectives and coherent, orderly construction. Just like a building, the construction of a software is based on numerous diverse systems.

At Kynetia we provide our clients with Enterprise Architecture (EA) solutions from the management and planning of EA initiatives within the firm to the implementation of Governance models, frameworks/methodologies and tools.

Kynetia’s approach to Enterprise Architecture is backed by the track-record we have built up over years providing our clients with real, tangible architecture solutions.

As an independent firm, we are not directly linked to any of the frameworks or methodologies existing in the market, although our experience and the skills of our architects means we can work with the market leaders, such as TOGAF and Zachman. In the case of TOGAF, we are members of the Open Group, and we are actively involved in the events it organizes on this methodology, such as the Enterprise Architecture Practitioners' Conference San Diego and the Enterprise Architecture Practitioners' Conference Paris.

Our goal is to adapt to our clients’ needs and provide them with the solutions they require on each occasion. Consequently, we seek to avoid concentrating on a single methodology and to provide our clients with flexibility, even working with methodologies they have designed in view of their own particular needs.

This sometimes makes it impossible to undertake the design of an EA from start to finish, and it becomes necessary to address partial architecture solutions to resolve problems as they arise while giving due consideration to the possibility of bringing them under the umbrella of a full EA at some time in the future. At Kynetia we help our clients resolve today’s needs, while considering the dynamics of tomorrow. We undertake a current / future status analysis together with the client and jointly design what we consider is the best architecture at any given time to resolve a specific problem, but that will anticipate the business needs that are likely to arise tomorrow in view of the corporate strategy.

If the Enterprise Architecture is to be more than a pile of documents of dubious utility, the methodology applied holds the key to the whole process of analysis, creation, implementation and evolution. In the absence of a pragmatic methodology based on clear conceptual scenarios, the benefits of a good Enterprise Architecture will fade away in the CIO’s office, gathering dust with the documentation. For this reason, Kynetia uses its experience to work together with our clients, devising realistic, practical working scenarios to provide a successful solution as flexibly as possible.

Methodology

Basic components of Enterprise Architecture

At Kynetia we take a general approach to studying the four basic components of the EA (Business, Applications/Users, Information and Technology) without tying the scenario to any market framework, under the umbrella of a Governance model capable of ensuring the successful implementation of the architecture.

While it is possible to undertake the design of an Enterprise Architecture without any specific framework, we normally find it appropriate to adapt one or other of the existing methodologies to the specific needs of our clients. If the client does not have a specific, predefined framework or methodology, we advise on the adoption of the one that provides the best fit to needs or assist with the creation of specific structure to provide the best possible support.

The aim is the stepwise creation of the architecture in complete execution cycles. Upon the completion of each cycle, a new one commences, in which it is possible to make improvements to the work already done. Not only is the complete cycle is normally iterative, but each of the phases comprising the cycle is also iterative. The iterative nature of the process is highly pragmatic, and the results obtained from the creation of the Enterprise Architecture are quickly visible.

efore beginning the iteration in each phase, Kynetia performs an initial exercise to establish the basis for the work, especially with regard to the determination of the principles that will govern the rest of the process. We also take care to ensure that the client’s business objectives are clear, and to establish the degree of granularity required and the most appropriate time window in which to undertake the project. After these preliminary steps have been completed, work begins on each of the phases, which depend on the framework finally chosen.

Phases of the process

TOGAF Phases

While the different phases concerned in the process of creating the architecture depend on the methodology selected, the following example describes those that would be required if the TOGAF option were chosen. However, this is only en example to provide new-comers to the world of EA with a general idea of the phases of the work.

Phase A: Architecture Vision
The objective of the first phase is to determine exactly the work required from the architecture standpoint. The aim is basically to define the scope of the project and the parties involved (in order to obtain their approval). In general terms, the current and future status of applications is documented.

Phase B: Business Architecture
The objective is to establish in depth the various business aspects concerned in the project. Strategic maps, corporate policies and business objectives are addressed, the functional breakdown and organizational models are prepared and standard and core business processes are documented. This concerns not just the current standard model but also the future status. Consequently, the strategic maps represent a key matter, because they determine future requirements. The result of this work is a Gap Analysis reflecting the gap between the objective established and the current status of the system.

Phase C: Information System Architecture
The applications and data layers are examined in this phase. A map of existing applications is drawn (including both third-proprietary and custom applications), interfaces between and internal and external links. This describes the current status. The future status is also projected by way of an approach to the future Enterprise Service Bus.

Phase D: Technology Architecture
It is in this phase that the technology architecture implementing both the business and the information architectures designed in phases B and C is developed. Like in the preceding phases, a baseline for the current technology is prepared, consisting among other things of a hardware model, network model (LAN and WAN), existing software infrastructure (operating system, applications server, data server, etc.). This is the base for the creation of the future state and the projection of the optimum technology architecture. Having done this, the pertinent gap Analysis is prepared, showing how far remains to go to achieve the objective.

Phase E: Opportunities and Solutions
This is perhaps the key analysis of the whole process. All of the current and future architectures defined in the preceding phases are now analyzed in order to establish precisely the blocks required to construct the new architecture, which of them can be reutilized and which will need to be provided either through procurement (in the case of standard processes) or through custom development (for core business processes).

Phase F: Migration Planning
The set of blocks required to set up the architecture to be implemented are established in the course of phase E. Logically, not all of these will be implemented at the same time, as this would only cause chaos. Consequently, it is necessary to establish priorities and the order in which the measures decided will be implemented. This, then, involves establishing the plan for migration to the new architecture.

Phase G: Implementation Governance
It is in this phase that the guidelines are created to ensure that both the developments falling within the scope of the architecture and those outside it exactly fit the target architecture proposed. In addition to the overall Governance model, the architectural principles, security principles, methodology to be used in development projects and so forth are established. In the end, the aim is to draw up an architecture contract, which will be signed by all of the parties who will work on the development projects.

Phase H: Architecture Change Management
In a highly dynamic business environment, it is practically impossible that a static architecture will be able to respond to all of the needs generated. Managing the dynamic of the architecture is the objective in this phase. Over the course of phase H, change proposals are monitored and it is decided whether and how to proceed. It may or may not be necessary to include changes in this phase depending on their nature. For example, the simplification of a process can normally be handled through a sound change management policy, making it unnecessary to address the change in this phase. However, changes such as the modification of standards and new technologies may require a partial re-architecturing, which would be undertaken from phase D. In the case of more profound changes, such as the complete modification of business processes, it will be necessary to return to phase A.

Enterprise Continuum

Finally, the importance of creating a repository for all of the models, patterns, artifacts and so on appearing over the course of the different iterations involved in the process of architecture development cannot be understated.
Following the conceptual model proposed by TOGAF, the Enterprise Continuum can be further broken down into the Architecture Continuum and Solutions Continuum. The former holds the models, patterns, etc. produced. The latter contains the formats in which these models, patterns and so on have been obtained. Given its practical nature, the model starts at the general, but also addresses the specific in order to ensure its utility.

Conclusion

At Kynetia we believe that the only sure way to undertake the construction of a sound technology base that is properly aligned with the business is to create an Enterprise Architecture that follows a strict methodology and ensures due coordination and cooperation between the players involved.