TOGAF Basic principles
Creating a specific enterprise architecture is considered as a transition from a general architecture to a specialized one. The architecture development methodology in TOGAF model is the process of making such a transition. The most generalized architectures in TOGAF model are called fundamental architectures. These principles of architecture can theoretically be used by nearly any IT organization in the world.
The next TOGAF specialization level is called system-wide architectures. These principles can be traced in many, but not all types of enterprises. The next one is an industry level of architecture. These principles are specific for enterprises engaged in one area of activity. The final level is the organization architecture level. This is the highest TOGAF specialization level. These are architecture of specific enterprises.
TOGAF includes two main components:
• Architecture Development Method defining the process of architecture development
• Foundation Architecture supplemented with a corresponding resource database, including descriptions of architectural principles, examples of implementation, as well as ADML.
TOGAF description includes seven (7) parts:
• Introduction contains a high-level description of the key concepts of the Architecture in general and TOGAF in particular.
• Architecture Development Method (ADM) is key TOGAF part, describing the step-by-step methodology for developing the Enterprise Architecture.
• ADM Guidelines and Techniques includes a description of the rules and techniques used in TOGAF ADM.
• Architecture Content Framework describes the approach to describe the Enterprise Architecture and contains meta-model of architectural artifacts, structure and description of typical architectural artifacts.
• Enterprise Continuum & Tools addresses the approach to architecture repository of architectural activities results.
• TOGAF Reference Models describes the reference models that to use in projects.
• Architecture Capability Framework approaches the organization of architectural practice in the company i.e. structure, processes, roles, skills and authorities required.
As the main processes of building Enterprise Architecture, it is important to implement only four key processes:
• Creation and development of Enterprise Architecture;
• Management of change;
• Monitoring the implementation of architectural solutions;
• Practice management.
TOGAF Architecture Development Method (ADM)
The processes of creation and development, change management, control of the implementation of architectural solutions in TOGAF are integrated into a single Architecture Development Method (ADM). This method can and should be adapted to the company’s objectives at all levels of architecture development. At the same time, there is no need to develop all possible documents and go too deep into details. ADM offers a ready-made set of techniques, tools, templates, and check sheets for each stage. The Architecture Development Method (ADM) contains ten phases. Each phase is divided into sub-processes (stages), individual works, and so on.
TOGAF Architecture Development Method (ADM)
For example, phase D includes the following main sub-processes:
•Description of the current technological architecture.
° An overview of the business architecture, data architecture and applications for defining the initial data and the required level of detail.
° Description of the current system with the required level of detail, selected to identify the required changes when creating the target architecture, i.e. the registry software and hardware platforms used.
° Identification and description of elementary architectural blocks to be used in the new architecture. In fact, it is a question of available architectural templates.
° Development of a draft technical report summarizing the main results of the study of the current state and the possibility of using typical units.
° Submission of the draft report for review, analysis of comments and introduction of amendments, if required.
• Creation of the target technological architecture.
° Description of the current system using TOGAF terms.
° Defining architecture perspectives (representations).
° Creation of a target architecture model.
° Definition of IT services.
° Confirmation of business requirements.
° Definition of architecture and blocks used (templates).
° Carrying out a gap analysis.
Table: Phases and Objectives of the ADM
The main objectives of the preliminary phase are:
• To create an architectural practice;
• To prepare the company for the launch of architectural projects;
• To enlist the leadership support;
• To create architectural principles;
• To adapt the methodology for the company’s goals and objectives.
The main objectives of phase A (Architecture Vision) are:
• To launch an architectural project, define goals and objectives, framework, scope and constraints of the project, develop a vision of the architecture, define the relevant stakeholders;
• 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.
• Responsibility of IT services implies that IT service is a liable owner of IT resources and the executor of processes to meet the business requirements.
• Intellectual property protection implies that ensuring the protection of an organization’s intellectual property should be implemented at the architecture level, IT operation and management.
• Data in IT system is an asset and have a certain value. They must be appropriately managed, shared and accessible to users depending on their access rights.
• Quality Assurance implies that the quality of every data element must be managed.
• Metadata must be consistent within the enterprise and accessible to all users.
• Data Security ensures data protection from unauthorized use and distribution.
• Technological independence implies that applications should not depend on specific models of equipment and system software.
• Simplicity of use implies that applications allow focusing on the implementation of business objectives through a single interface, minimizing the specifics of work, integrating systems, reducing the likelihood of misuse.
• Soundness and promptness of changes implies that changes in the information system and applications are made only in accordance with the business demands and duly.
• Interaction implies that the hardware and software must integrate with one another in accordance with common standards.
• Minimizing Diversity refers to reducing the number of different options for the platforms, products and versions applied.
TOGAF Architectural Practice Management
Architectural practice is the practice of implementing an architectural project within organization. Architectural practice consists of four key elements: