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

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:

• People are the foundation of any company’s activity. If people cannot do, do not know how, do not use, do not participate, do not want to or do not do something, everything else is useless. If you have forgotten about people, you have to forget about the results.

• Artifacts. Working people must achieve predetermined results. They also create artifacts enabling to share information, discuss objectives and issues, save ideas for later implementation, monitor the achievement of results, etc.

• Processes. In order to achieve results, people must do the right things in the right sequence. All people make mistakes, but if they follow predetermined processes, the likelihood of errors decreases, and their consequences can be easily eliminated. Processes help turn good ideas into results. So, one cannot just shrug off them lightly.

• Management. Architectural practice is doomed to failure without proper management. One should determine the framework and rules of practice beforehand, taking the standard processes, artifacts, roles, etc. as a foundation. It is very dangerous to make up the rules as the game is on. People will be disoriented, processes will fail, the results will be wrong and at the wrong time.

Figure: Architectural Practice Management using “TOGAF”

Architectural practice management is required to exclude the common mistakes made by people working on a task or project. People are unlikely to achieve results if they:

• go too deep in the theory and research;

• do useless work;

• make long preparations before commencing the work;

• re-invent the wheel;

• “optimize” their work instead of doing it;

• theorize too much;

• Search for someone to blame;

• find themselves the smartest ones;

• avoid unpleasant work.

The approach to the architectural practice management consists of six main elements:

• Methodology is the main element of the approach. It defines the company’s processes for developing, updating, and implementing the Enterprise Architecture, their roles and responsibilities.

• Artifacts include a set, templates and rules for filling in the documents, tables, diagrams, used for description of the Enterprise Architecture.

• Standards are the standards, laws and rules of business and IT used by the company. These can be international standards, Russian standards, standards of the industry, region, and company.

• Best practices and ready-made models are proven ways to implement solutions, tested in your or in other companies.

• Regulations and rules are the documents describing the goals, objectives, organizational structure, rules of work and the boundaries of architectural practice. They contain the rules of work with other subdivisions, and architects’ authorities. The regulations should be integrated with other company regulations, especially those of the IT department.

• Managerial impact by practice managers are aimed to ensure practical results in the company. One needs to plan, get people to follow processes, start architectural projects, resolve conflicts, monitor intermediate results, etc. No elements will work being unmanaged.

First, the order of implementation of architectural practice includes development of all these company’s elements from scratch – that is a very difficult task to do. Therefore, one needs to take the existing methodologies and adapt them according to the company’s needs. Secondly, the practices should be introduced gradually, as a part of the practice development. The introduction of each element should be a real value for the practice. Third, one should keep a balance between bureaucracy and personal initiative. Finally, do not be afraid to experiment and try new approaches. If they are valuable, describe them in the regulations and use them in your next projects.

TOGAF Key Documents and Templates

To implement the TOGAF methodology, the question arises: what is the minimum set of documents required to maintain an architectural project? Extra documents mean extra time and funds. From my own experience and theory (during preparation for certification), the minimum set can consist of eight documents:

• The Main Methodologies are Templates, Business Principles, Goals, Drivers, required to understand the company’s mission, goals, and strategy and register the business principles. See Template “TOGAF 9 Templates, Business Principles, Goals, Drivers.doc”

• Architecture Principles are the rules to guide the work on architecture. Architectural decisions are made based on these principles. Principles need to be formulated based on TOGAF examples. Using principles when working on architecture has proven its effectiveness. See Template “TOGAF 9 Template Architecture Principles.doc”

• Architecture Vision is a high-level description of the desired end product of an architectural project. So, these are the results to achieve. Description of the solution of the problems and tasks to start the project for. This document is important for interaction with the project sponsor and other stakeholders. See Template “TOGAF 9 Template Architecture Vision.doc”

• Statement of Architecture Work is an agreement between the sponsor and the project team on the implementation of the work. It includes all the frameworks, restrictions, assumptions, terms, budget, and project rules. It designates the project manager and states his/her rights and responsibilities. Addendum includes the architecture vision as a description of the project framework. See Template “TOGAF 9 Template Statement of Architecture Work.doc”

• Architecture Definition is a presentation of the current and target architecture and covers each of the architectural domains i.e. business, data, applications, and technology, as well as an analysis of the discrepancies between the current and future state. See Template “TOGAF 9 Template Architecture Definition.doc”

• Architecture Requirements Specification is a document providing a quantitative view of the requirements, restrictions, suggestions, and measurable criteria that must be met during the implementation of the architecture. See Template “TOGAF 9 Template Architecture Requirements Specification.doc”

• Transition Architecture. The implementation of the target architecture has several stages. Each intermediate state must be workable and valuable. This document groups projects for each of these stages. See Template “TOGAF 9 Template Transition Architecture.doc”

• Implementation and Migration Plan is a consolidated implementation plan for projects aimed to achieve the target architecture. It also includes benefits, scope, timeframe, cost, risks, and milestones of projects. See Template “TOGAF 9 Template Implementation and Migration Plan.doc”

Such set of documents can be done rapidly and in a cost-effective way. If you are going to use third party services, I recommend to include one more document – an architectural contract. This is an agreement between architects and IT project executives. See Template – “TOGAF 9 Template – Architecture Contract.doc” When accepting a project, it will be easier for you to get the desired result if you have agreed on it beforehand.

Management Strategy

When forming an IT Strategy, one can determine the strategy on “Technological Architecture” and “Information Systems (Services) Architecture” of some IT infrastructure components, as well as recommendations on choosing solution. To understand the problems of the business and translate them into the IT language, you can use the method of “problem tree – solutions”. As can be seen from the diagram, business formulates its problems in the language of business. The task of the CIO is to translate the business language into a technical language, for the further development of IT projects and setting tasks for the IT department staff In order for business and IT to understand the need to demand from each other, it is necessary to define criteria for achieving goals and objectives, as well as metrics for their measurement.

“Problem – Solution Tree”

Financial control strategy

A financing strategy may foresee an organization’s behavior in IT financing. In particular, it is desirable to have a financial strategy on issues such as:

• cost of the solution as a priority when choosing an IT project solution, even if it affects the functionality. Solution capabilities must meet business requirements with minimal cost;

• focusing on the use of free software;

• balancing by cost or functionality.

For example, the cost of leasing circuits for different branches of the same bank may differ depending on the distance or geographic location. Let us say that the cost of a 10 Mbps channel (which is a standard and sufficient IT requirement) for a regional branch costs 500 USD. The city branch can get the speed of the channel up to 100 Mbps for the same cost. This branch has a current standard speed of 10 Mbps for about 100 USD a month. The average cost of a communication channel for all branches is about 250 USD. The leadership should have a certain strategy regarding this issue, i.e. provide branches with an opportunity to increase speed within the average cost, maximum cost, or leveling all up to the established channel speed (10 Mbps).

Outsourcing in the implementation and maintenance of Information Systems and projects should be used whenever possible. The capabilities and potential of the IT department staff should be increased.

Administrative strategy

The strategy of changes may foresee the organization’s behavior when changing in requirements, etc. As an example, let’s consider the situation when the number of employees remains unchanged, while the speed of Internet access has dropped significantly due to intensive use. As a solution, the bandwidth can be increased, that will affect the costs accordingly. This issue will periodically occur until it reaches the critical point. Another solution is “repressive” method, i.e. having analyzed the network traffic, the IT department determines that the misuse of the Internet has increased. Some administrative controls may lead to improvement of Internet speed without increasing the costs.