IT Architecture from A to Z: Theoretical basis. First Edition

• To develop a “project charter” and get a formal confirmation of the project start.

The main objectives of phase B (Business Architecture) are:

• To develop an architecture with a description of the current and target architecture;

• To conduct gap analysis.

The main objectives of phase C (Information Systems Architectures) are:

• To develop an architecture with a description of the current and target architecture;

• To conduct gap analysis.

The main objectives of phase D (Technology Architecture) are:

• To develop an architecture with a description of the current and target architecture;

• To conduct gap analysis.

The main objectives of phase Е (Opportunities and Solutions) are:

• To plan the implementation of project objectives;

• To identify major implementation projects and group them into transition architectures.

The main objectives of phase F (Migration Planning) are:

• To conduct cost and risk analysis;

• To develop a detailed implementation and migration plan.

The main objectives of phase G (Implementation Governance) are:

• To govern the overall project implementation;

• To prepare architectural contracts.

• To ensure conformance with the defined architecture by implementation projects.

The objectives of phase H (Architecture Change Management) are:

• To prepare for the next turn of the Architecture Development Cycle.

• To ensure the compliance of the change management with the actual needs of the business and maximum value to the business.

The main objectives of the Architecture Requirements Management are:

• To collect and agree on business requirements at each phase of the architectural project;

• To identify, store, the requirements, to define the priorities and use then in the relevant phases of the architectural design.

The TOGAF specification also enables flexible work with stages. The specification states the following:

Before applying the architecture design methodologies, one needs to check whether the components are applicable and then link them to the specific circumstances of the individual enterprise. This allows creating a methodology for architecture developing for a particular enterprise.

The TOGAF model enables partial implementation of stages, skipping, merging, reordering, and amending them to meet specific requirements. Not surprisingly, two TOGAF certified consultants working with the same organization can develop two completely different processes.

The TOGAF model is even more flexible for the architecture created. In fact, TOGAF “knows nothing” about architecture. The quality of the final architecture can be good, bad or even undetermined. TOGAF describes how to create an enterprise architecture, but does not describe how to create a good one. The quality of the final product depends on the experience of the company’s staff and the TOGAF consultant. Those who introduce TOGAF hoping to get a miracle cure, will be severely disappointed (like using any single methodology).

Foundation Architecture

Foundation Architecture includes:

• A set of the most common services and functions, combined in a Technical reference model (TRM);

• A set of elementary architectural elements used as “building blocks” for building specific solutions;

• Standards Information Base.

The concept of using the Foundation Architecture is defined in accordance with the breakdown of architectures included into a common continuum of definitions. A technological reference model in TOGAF is recommended for use, but not mandatory. In general, the technological reference model is not perfect for the reason that it aims to ensure the portability of applications sacrificing their interoperability and autonomy. Implementation of TOGAF model in organizations is mainly reduced to an architectural design methodology. In this sense, the Core Architecture component, which contains a set of services and standards, is some abstract implementation of the entire IT system. The Common Systems Architecture is implemented by selecting and integrating specific services to shape dedicated blocks that can be used in various functional areas, such as security architecture, network architecture, etc. (possibly, repeatedly or in various combinations).

The next level of detail is implemented at the level of the Industry Architecture, which adds industry-specific data models, applications, standards, business rules, and, if required, procedures for the interaction of various industry systems. The final level of the Organization Architecture deals with formation of the IT architecture within a particular enterprise, taking into account all of its features, including the availability of legacy systems, plans and implementation possibilities, organization of data at the physical level, etc.

The Reference Model includes a common services system (taxonomy), including such services as Data Exchange and Transformation, Data Management, Internationalization Support, Directory Services, etc.

The level of implementation quality should be defined for all services used in the architecture such as manageability, flexibility, warranty, usability, etc. along with the functional purpose. It should be noted that some services are interdependent. For example, specialized software development service components may be required to create and test relevant software products to ensure a specified quality of internationalization service.

Architectural principles are fundamental “axioms”, used as “starting points” for evaluating the current system and for developing individual architectural solutions. Generally speaking, architectural principles are a subset of the more general concept of IT principles, which define the main aspects of all activities related to the use of information technology. IT principles, in turn, are a detailed elaboration of the more “common” principles defining the activity of the entire enterprise.

The structure of a set of principles may include justifications for the formation of a system of requirements or criteria for evaluating decisions. For example, such a principle as “minimization of the number of software providers” can be further specified as a requirement of a “unified DBMS for all business-critical applications” or “using the same DBMS as the current one” depending on the characteristics of the enterprise. Architectural principles can also be used for justification of the significance of the very notion of Architecture and the necessity to develop it for the enterprise business, as well as to select options for implementing this process.

These principles are interdependent and should be applied as a consistent set. A “good” set of principles must satisfy such natural criteria as availability for understanding, accuracy of formulations, completeness, consistency and stability (not to be confused with invariability!) Usually the number of principles does not exceed 20 in order not to restrain the flexibility of the architecture or to avoid a purely formal definition of unworkable principles.

Figure: “TOGAF” Enterprise Architectures

Examples of principles, used to create the TOGAF architecture (Title and Content):

• An example of use is applicability of the defined principles of IT management to all cases and divisions of an organization.

• Maximum benefit is that IT decisions are made based on the maximum benefit for the entire organization.

• Everybody is involved since information management is everyone’s business.

• Business Continuity i.e. enterprise operations should be ensured in spite of all possible interruptions in IT operations.

• Common use – the priority should be given to developing or implementing applications applicable to the entire enterprise, rather than its individual divisions.

• Compliance with the law implies that IT management should not contradict the applicable law and the adopted regulations. However, this is not an obstacle to the improvement of business processes, leading to changes in these regulations.