IT ENTERPRISE ARCHITECTURE
General Provisions
This chapter describes the general information on Enterprise
Architecture. A generic definition can be represented as depicted below:
“Relationships of IT methodologies”
Enterprise Architecture is a set of principles, methods and models used in the design and implementation of an organizational structure, business processes, information systems and technologies. It is a management practice aimed at maximizing the impact of the enterprise, investing in IT, developing systems in achieving the enterprise goals, converting the business vision and strategy into an effective change of the company through creating, discussing and improving key requirements and principles that describe the company’s future state and enable its development.
Since the Enterprise Architecture is a complex solution including the intersection of various methodologies and techniques, building an Enterprise Architecture should take into account, but not be limited to, the recommendations of the following standards:
•TOGAF — Enterprise Architecture
•ISO/IEC 20000 — Quality in IT Service Management
•ISO/IEC 27000 — Best Practice IT Security Standards
•CobiT v5 — Audit and Control Framework
•ITIL v3 — Best practices in IT Service Management
•MOF — Microsoft Operations Framework
•PMI — Project Management Institute
The architecture is designed to respond to such challenges and problems of the organization as:
• Business discontent of the IT service for objective or subjective reasons.
• Inability to assess the effectiveness of IT use in business.
• Mess in IT solutions and systems implemented in the organization.
• The complexity of making IT-related decisions.
• The complexity of IT budget coordination and the launch of IT projects.
• Growth of “Information” value and connectivity between business and IT.
• Lack of transparent and clear connections between business and IT.
• Whether solving the actual business problems using IT is possible?
• How to make IT give companies greater value?
• How to change IT with changes within business?
• IT systems are complex, unmanageable and expensive to maintain.
• IT systems restrain an organization from responding adequately to changes within business.
• Business-critical information is untimely and inadequate.
• Communication culture between business and IT is missing.
As a result, the business does not see any value in information technologies. CIO’s face difficulties in pushing new ideas if they talk about technology. They are not understood. Everything they can do is to support what already exists and do the objectives pitched by the business. The serious problems arise with the justification of IT budgets. In fact, the CIO acts more like a foreman who fills in the holes, rather than a top manager who is developing the company. Top managers quickly lose interest in IT projects, and therefore, they lose funding and fail. IT department are replaced with various system integrators to implement “fancy schmancy” solutions that will “save” the business. The ideas also arise to take all company’s IT assets and services and outsource them. It will be difficult for the IT department to fight with integrators and the result is predictable — the integrators have one key competence, i.e. technology, and that is their forte. The IT department is turning into a “swamp”, and the best employees leave taking away the unique knowledge and skills. The goals of an integrator or an outsourcing company are the same as your company’s — making a profit. But unlike the IT department, whose interests coincide with the interests of your company, the integrator’s interests may not coincide with yours, including unique ideas and visions. At best, it will be “like everyone else,” and the business will lose its identity (if it is inextricably linked to IT) or quoting one movie character: “… we will have everything new in an old fashioned manner…”. The end is sad.
The Main Aspects of Enterprise Architecture
To fight the above-mentioned problems and consequences, the Enterprise Architecture helps shape the following important criteria.
Structuring the Enterprise
When building an Enterprise Architecture, the first and most important aspect is an understanding of the enterprise’s organizational structure, principles of management, decision-making, etc. The organizational structure is a fixed and ordered set of objects and connections between them. Depending on the specialization and operations the organization may have:
•Vertical structure — in terms of subordination
•Horizontal structure — in terms of functions and operations.
Accordingly, the management structures are distinguished as linear based on “chief — subordinate” principle and functional, i.e. “professional integration based on the operational specifics”. As a result, organization structure can be represented as the following main types and their varieties:
• Flat, the simplest structure, is suitable for work or project teams, or a small organization.
• Breakdown (bureaucratic) is based on the organizational structure, the functional division of labor and employees’ responsibilities.
• Linear, direct control (head — subordinate), communication between departments occurs through heads of departments only.
• Functional, interaction is based on function.
• Linear-functional — the interaction is combined in a linear and functional type (the most used model).
• Linear and staff — separate functional groups (staffs), conducting work independently with departments or organizations. As an example, a group of companies in the holding.
• Divisional is characterized by central coordination with decentralized management. The key figures in this case are not the heads of functional units, but the managers of individual branches, factories, and so on.
• Organic (adaptive) — the structure formation is based on the need to adapt to changes. Relationships are based not on the structure, but on the nature of the objectives set.
• Project — organized during project management.
• Matrix (program-targeted) — the principle of dual reporting, direct reporting to the manager and project manager
• Brigade (cross functional) — work in separate groups with independent management and decision-making (contrary to breakdown).
Organizational structure may depend on a number of factors:
•Specificity and diversity of operations;
•Geographical location;
• The centralization level of the organization;
• Organization strategy;
• Number and range of services provided.
IT role in the organization
One of the main criteria of building an Enterprise Architecture is to identify the IT role within the organization. If we ignore articles and recommendations about the importance of IT in the modern world given by consultants and other small talks, we have to rigidly fix the role of IT in the organization, the objectives, rights, opportunities and degree of responsibility. To understand the IT role in a particular organization, one needs to answer the following questions:
How is IT involved in business? How much does business depends on IT? Many business processes and functions are tied to complex, centralized or specific IT solutions. Business development is impossible without rapid and quality IT work. There are entire industries that depend on IT such as banks, insurance companies, other financiers, service companies, Public agencies, technology and power companies, etc. (as an example, two-thirds of the bank employees work in one way or another with a centralized banking program, while only a few rural organizations use mostly autonomous IT solutions, where majority the employees work on the field or the computerization of the company is low).
Whether your organization can be attributed to large or medium-scale business. In my opinion, as long as all the technologies of the company are stored in one head, and the CIO communicates directly with the management it is too early to think about the enterprise architecture. For small-scale businesses, enterprise architecture is superfluous.
Whether your company is actively developing IT. The company has several IT projects per year, or at least one project on implementing ERP, CRM or other complex solution. Enterprise Architecture will help to make a decision save from most alterations, errors, inconsistencies, delays and other problems. There must be one person, or groups of people in the company to have a general picture of the future and understand the development process. Otherwise, the pieces of different projects will never make a puzzle.
Whether the company periodically faces IT crises having a significant impact on the business, or there are failures in information systems affect the business and even stops it. Failures are caused by integration problems, miscalculations in infrastructure solutions, temporary solutions and just a mess. Not all projects, including IT, end successfully, meeting the deadlines, budget and stated requirements. If your company management is fed up with failures, delays, exceeding the budgets of IT projects, it is worth thinking.
Companies are looking for speed, quality and efficiency of IT development. One of the parties (business or IT) is developing much faster than the other one. If business develops faster than IT, the latter one impedes the company’s development. Conversely, if IT develops faster than the business needs, business lose money (good IT costs money) and profits (the business does not use all the potential IT capabilities). Both parties should be on the same wavelength to allow the harmonious development of all company’s elements.
Building a relationship between business and IT
IT actions should be focused on business goals and objectives. Business and IT parties see the objectives, goals and expectations differently. This is what IT staff says “…we are good in technology, we are paid for the ability to program, configure, install and solve technical problems, etc. Our work commences as we receive the statement of work…". While business sees it as “...there are so many IT innovations, IT should give us some kind of solution to increase sales. In the worst case scenario, we need a solution our competitors already have. So their sales are higher …you are welcome to implement it since you’ve made a decision though you don’t understand how this business works…”. The task of the CIO is to have an equal share in the discussion of business strategy. The general principle can be defined as: “a business describes its requirements and expectations (business requirements), while IT creates a statement of work to achieve the goals.”
Establishing collaboration between business and IT
All above mentioned is followed by another important problem, i.e. the “vacuum” in communication between business and IT employees. The task of the organization’s management and the CIO is to establish communication between the organization’s employees not only at the top-level, but also between the middle-level employees and the direct executors of business and IT. As the saying goes “the devil is in the details.” Any cool idea in general should be fine-tuned. At this stage, the specific thinking of IT specialists with having causal link, and WH-questions such as “…what happens if…,”, “… how to control…”, “…how to measure …”, as well as analysis of limit state scenarios, will help develop an optimal solution. In addition, such questions will help business representatives to understand and work out the solution from a business point of view and what to demand from IT, the ongoing solution capabilities and their future opportunities or limitations.
Getting maximum value from IT
Most organizations, except IT company, IT is used only as a tool to achieve business goals, a secondary service, just like accounting or administration, providing support for key areas and processes. IT evaluates solutions in terms of technical maturity, completeness, functionality, and so on. At the same time, the business’s only interest is making profit. A perfectly developed technical solution can nullify the business advantages of the idea itself, make it difficult to use and expensive to implement and maintain. It reduces financial benefits and makes the solution inconvenient for customers, etc. The tasks of CIO is not to develop the best solution from the IT point of view, but the most correct one. The most correct solution will be made by using the formula and of the following key components:
VALUE = BENEFIT — COSTS
From a business perspective, it can be interpreted as getting maximum value from IT. The value of information technology is the difference between the benefits of using information technology and the its cost. From an IT perspective: Compliance with IT values and requirements i.e. workability, security and manageability.
Transferring part of the work to the IT department or refusing to automate a number of elements can reduce the cost of the solution, increase ease of operation and convenience for customers.
One of the primary objectives is to define the boundaries to search for opportunities and identify the border, beyond which is destroing the foundations of IT manageability and information security.
Management of change
What we mean in the context of this chapter is the readiness for changes initiated by the business. The business environment can change quickly and radically: new business niches emerge, new products are developed, mergers and acquisitions take place. This can lead to the situation when technical solution used in the organization does no longer meet the organization’s requirements. The IT objective is to adapt an existing solution or develop a new one as soon as possible spending minimum budget to meet the business’s new requirements. As a result, when developing IT strategies and IT solutions in particular, it is necessary to keep in mind a certain flexibility and generality.
Sorting out and managing IT development
Modern realities of business and technology development lead requirement to implement more and more new technological solutions. Different methods and models of their implementation, i.e. independent development, the purchase of a Commercial Off-the-shell solution, implementation and maintenance by a third party, etc. leads to a large number of different duplicated hardware and software in IT infrastructure, obsolete solutions, and so on. Moreover, it generates constant dependence on professionals with “unique” knowledge and experience. The task of the CIO is to arrange IT management, continuous training on new technologies for employees, selection of promising directions to benefit business.
Basic principles of building Enterprise Architecture
The integrated automation of the management function in any modern enterprise requires a unified information space, in which ordinary employees and management will be able to carry out their activities, being guided by single rules for access, presentation and processing of information. Modern methods of building a single information space are based on a comprehensive re-engineering of business processes, creating an information-logical model and then implementing the appropriate software and information support using new technologies. The development of IT architecture allows you to clearly imagine:
• What information / data are critical for the company’s business and the way it is organized?
• Which applications will support the business?
• Whether these applications effectively communicate with each other and with external systems of partners and suppliers;
• Whether the technologies used meet the requirements of supporting business processes;
• Whether the information security of the systems is sufficient?
• Whether the company employees get timely access to the right data they need;
• What standards should be used in the development and procurement of system components?
The architecture is designed using common methodologies, frameworks of architecture description and modeling tools (for example, ARIS IT Architect) taking into account the customer’s experience and preferences. During the project a set of architectural principles is formed, used and prospective standards are identified, and architectural models and individual areas such as applications, data, integration, technical infrastructure, security, etc. are developed.
The approximate sequence of building a single information space of the enterprise is the following:
• Enterprise survey
° Main goals and objectives;
° Precise identification of the project objectives and goals;
° Formulation of functional and technical requirements for the project;
° Infrastructure audit of the enterprise IT system for the design of the solution architecture;
° Shaping the enterprise’s ongoing business processes, automated within the project;
° Obtaining data to justify the number of licenses;
° Evaluation of the resources required for the project;
° Project risk assessment;
° Development of a preliminary project plan, schedule and specification of supplies for each stage and whole project.
• Survey results:
° Report on the situation “As is”;
° Proposal for creating an information system “As required”;
° Proposal for “functional and technical requirements of the project”;
° Project implementation plan;
° Project risk assessment and proposals for their minimization;
° Estimated cost of the pilot project and final solution.
• Supply of necessary hardware and functional solutions for the business units automation:
° Adaptation and adjustment of basic and development of new solutions (if required) in accordance with the functional and technical requirements obtained at the survey stage;
° Deploying a platform with basic document processing and storage services;
° Trial operation of the solution;
° Integration with ERP-system;
° Putting the system into commercial operation.
• Training of technical staff and users.
• Providing additional functionality, i.e. the work allocated at the stage of the survey in separate stages.
Framework is a ready-made methodology and a set of supporting tools to be adapted for use in a particular company. Framework contains typical architectural processes, recommendations for their adaptation for a specific company, recommendations for creating templates of architectural artifacts, requirements for their filling, requirements for architects and much more.
“The Enterprise Architecture model” diagram
The Enterprise Architecture model can be divided into several key levels (categories):
•A business architecture contains the company strategy, management approach, organizational structure and key business processes.
•An information system architecture describes arrangement or potential arrangement of the company’s information systems. An information system architecture can be divided into two subgroups:
•Application architecture shows the business applications deployed in the company, their interaction and relationship with the company’s business processes.
•Data architecture contains a description of the logical and physical structure of the company’s data, as well as the approach and means of data management.
•Technical architecture describes the software and equipment required to deploy business services, data and applications, IT infrastructure, application servers, networks, telecommunications, standards, etc.
“Enterprise Architecture documentation level”
The next level of hierarchy can be:
•Strategic architecture — describes the entire company. At this level, you are not immersed in the peculiarities of specific departments, business areas, etc. The strategic architecture focuses on the company’s overall strategies, business processes, investments, data, systems and technologies. Its primary focus is the implementation of the company’s strategy. At this level, principles and priorities are defined, the common IT services are created for the whole company.
• Segment architecture is the architecture of the company’s activities, the program of projects or a separate subdivision. The company will have several segments like this. At this level, you are immersed in the peculiarities and requirements of a particular subdivision, function, or company within an organization. You study the IT business case with departmental leadership. The segment architecture should have the same structure and shared services as the strategic architecture does.
• Solution architecture is the architecture of a specific IT solution. It is used to implement new or adjust the current IT solutions, services or their parts. It considers both the common requirements for the entire company and the specific needs identified at the segment architecture level. The solution architecture is limited to a single project, process, or function. The solution architecture is studies in the most thorough way. It allows avoiding unpleasant surprises in the future as the project is implemented.
IT maturity levels
In the organization grows and develops, the IT department also goes through several stages of its development. Building an Enterprise Architecture one should take into account the maturity level of the entire organization and IT in particular. The following stages and symptoms of the IT department state can be distinguished:
Initial or “localization”
The company rapidly develops or purchases information systems that give value to a particular business unit or function. The main symptoms of this stage of development are:
• IT department is secondary;
• No IT department strategy;
• No IT department budget;
• IT department acts upon request only;
• Managerial staff is concerned in maximum savings;
• Service within the business department (administration, finance) in the organizational structure of the company.
Development or “standardization”
The company moves from closure of the needs of individual business units or functions and increases IT efficiency by standardizing technology and infrastructure. The main symptoms of this stage of development: are:
• The IT department is not a strategic resource;
• No or initial level of IT department strategy;
• No IT department budget or it is managed by the third party;
• IT department hardly acts in IT infrastructure or acts passively (upon request only);
• Managerial staff is concerned in minimum investment;
• Service or department within the business unit (administration, finance) or overseen position in the organizational structure of the company.
Establishment or “optimization”
The company builds end-to-end business processes using common data and information systems. Whenever possible, it centralizes subdivisions’ business processes and functions in centralized information systems according to previously described operational models. The main symptoms of this stage of development are:
• The IT department is important;
• IT department strategy partially meets business requirements;
• Manageable IT department budget;
• IT department responses reactively to business requirements;
• Managerial staff is concerned in getting business benefits in the short term;
• A dedicated department in the organizational structure of the company, but the IT manager is not a part of the board of directors.
Mature
Reuse of existing business processes and components to create new services and opportunities. Proactive IT is an integral part of the business. The main symptoms of this stage of development are:
• The IT department is a strategic organization resource;
• IT department strategy integrated into the company’s business strategy;
• IT department budget considered as business investment;
• IT department acts proactively to business requirements;
• Managerial staff is concerned in long-term business investment;
• IT department is a part of the company’s organizational structure, CIO is a member of the board of directors.
Each of these stages has pros and cons. The IT development stage should correspond to that of the company. Experience has shown that to skip at least one of the stages is difficult since it requires huge amounts of resources (time, money, human resources etc.), and the effect will rather be to the contrary. Most companies grow stage-by-stage. The company transits to the next stage when the leadership of the company realizes or the severity of the issues arisen:
• Issues of supporting the growth and business changes
• Duplication of business processes
• Multiple platforms and systems
• Dissatisfaction with the current IT state.
Criteria of choosing a methodology
Since the methodologies vary a lot, one should set criteria to compare them.
The completeness of the taxonomy defines the suitability degree of the methodology for the classification of various architectural artifacts or whether fully focused on the Zachman framework.
The completeness of the process defines how detailed the process of creating the enterprise architecture is.
The guide to reference models defines the usefulness of the methodology in creating an adequate set of reference models. The FEA methodology is almost entirely focused on this.
The practical guide defines the degree of implementation of the speculative idea of the enterprise architecture by the methodology and shaping the culture in which this architecture will be used. The Gartner methodology is almost entirely focused on this.
The readiness model defines the degree of assessment of the efficiency of using the enterprise architecture in various departments by the methodology.
A business orientation defines whether a methodology focused on using technology to increase business value, where business value defined as cost reduction or revenue increase.
The management guide defines the degree of methodology usefulness in understanding and creating an effective management model for an enterprise architecture.
The partitioning guide defines the usefulness of the methodology in effective partitioning the enterprise into departments, which is very important in managing complexity.
The availability of the catalog defines the efficiency of the methodology to create a catalog of architectural assets to be used in the future.
Neutrality towards service providers defines the likelihood of being tied to a specific consulting organization when implementing a methodology. A high rating means a low degree of attachment to a particular organization.
The availability of information defines the quantity and quality of free or relatively inexpensive materials on this methodology.
The time of recouping investments defines the duration of your using this methodology before you can build high business value solutions on its basis.
Enterprise Architecture can be built using various methods and practices. This book briefly discusses some of them and focus on one of them:
•“Zahman Framework” is the earliest and most well-known methodology. It is ideal to “classify” architectural elements.
•“TOGAF (The Open Group Architecture Framework)”, designed for “building processes” is widely known and spread, largely due to its openness.
•“Gartner” is a methodology for expert analysis by using “best practices”.
•“FEAF” is an architecture building methodology using the “service oriented” approach.
When building an IT Enterprise Architecture, one should highlight the following states of the organization’s architecture:
• “As-is” or “Baseline Architecture”;
• “Transition Architecture”;
• “To-be” or “Target Architecture”;
• “Enterprise Architecture Management Plan & Roadmap”.
In general, the Enterprise Architecture represents a transition plan from the “Ongoing” to the “Future” state of the organization. The architectural project lasts for several years and initiates many IT projects. These projects will have different duration, different start and end dates. They need to be grouped so that changes in business and IT would take place at the right time, with minimal risk and no compatibility issues. Therefore, architecture can transit from one operational state to another several times as an architectural project lasts. The intermediate state is called the Transition Architecture.
Enterprise Architecture using the Zachman Framework
The earliest methodology and in my opinion the most complete and structured is the Zachman Framework. It was originally developed as an Information Systems architecture. The main idea is to provide the possibility of a consistent description of system’s individual aspects in coordination with all the rest. The Zachman model is used to describe the enterprise as a whole, so the proposed model can be generally used as a means for describing architectures of any complex production system. The main characteristics of this model are:
• Integrity of the enterprise;
• discussing complex issues using a relatively small number of non-technical concepts;
• applicability for solving problems, i.e. the ability to work with abstractions and entities, highlighting and isolating individual system parameters without losing the perception of the enterprise as a whole;
• Simplicity of description.
The advantages of the Zachman model over others are:
• It is easy to understand for both technical and non-technical experts;
• It has more detailed descriptions of architecture components;
• It can be applied to planning and better decision making;
• It has the most visible representation of the company’s components.
• It describes complex architecture using a small number of non-technical terms;
• It has independent tools for specific description;
• It can be used as a tool for describing architectures of any complex production system.
Enterprise Architecture — Zachman Framework Matrix
Enterprise Architecture using “FEAF”
FEAF is a framework developed by the US government, as an approach for the development of information technology for Public agencies to use a single architecture. The FEAF is based on five reference models:
• Performance reference model;
• Business reference model;
• Service component reference model;
• Technical reference model.
• Data reference model.
One of the useful properties of the FEA framework is the principle of a segment approach, allowing accelerating the implementation of the Enterprise Architecture. The process of developing an enterprise architecture using the FEA methodology includes the following steps:
• Architecture analysis;
• Architectural definition;
• Investment and financing strategy;
• Program management and project implementation plan
Enterprise Architecture using “GARTNER”
Gartner Methodology can be described as a set of recommendations for creating an enterprise architecture. The 2002 Gartner model is designed in four related, interdependent, and increasingly complex levels:
• Business Relationship Grid;
• Business processes and business process styles;
• Templates;
• Technological building blocks (bricks).
Essentially the Gartner methodology is neither a methodology, such as a structured Zachman model, nor a process like TOGAF or FEA. Gartner is a set of practical recommendations. This methodology is a collection of tips for building enterprise architecture from one of the world’s most famous consulting IT companies. This framework is a three-dimensional cube consisting of following levels:
• Horizontal layers;
• Vertical domains;
• Vertical elements of technical architecture.
Enterprise Architecture using “TOGAF”
The main area for TOGAF application is the software infrastructure of the information system. It best suits for describing the integration components used to support a wide range of critical enterprise applications for business. The model can be described as:
• Business architecture overview;
• Description of the current system with the level of detail required;
• Identification and description of elementary architectural blocks to be used in the new architecture;
• Development of a draft technical report;
• Submitting the draft report for review.
TOGAF is positioned not as a reference model, but a “tool for developing information system architectures”. The primary function is to speed up and facilitate the process of developing the architecture of a particular organization, providing the possibility of future development. Let us consider building of the Enterprise Architecture based on the TOGAF methodology in more details, which in my opinion has several advantages:
• TOGAF approach allows you to build the entire architectural process — from the launch of the practice to the results.
• TOGAF is the de facto standard and has a certification program.
• TOGAF is absolutely free and has lots of open resources to download and use.
• TOGAF contains a complete set of tools for creating and developing architectural practices in an organization. There is a step-by-step process for developing a description of the Enterprise Architecture and a complete range of tools, templates, etc.
• TOGAF is compatible with other frameworks, for example, “Zahman Framework”. As an architectural process, the TOGAF model supplements the Zachman model classified as an architectural taxonomy. Zachman demonstrates how to classify the artifacts. The TOGAF model describes their creation.
Enterprise Architecture using “TOGAF”
Even though the TOGAF methodology and Zakhman infrastructure are merged into the “enterprise infrastructures” category, their principles, structures and competencies are different. TOGAF is a functional and dynamic infrastructure including guidelines for process use patterns. While the Zachman framework is a static architecture structure, it is the most effective one for applying the analysis and meta-analysis of infrastructure frameworks. Despite the significant differences in these frameworks, they can be used together.
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:
• 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.
Strategy of Infrastructure Building
Architecture choice strategy
As a solution architecture, one can consider the following:
• On premise infrastructure;
• Cloud based infrastructure;
• Hybrid architecture.
“On-premise” implies that IT assets are physically located within the organization. Benefits:
• IT infrastructure is located within the organization and controlled by organization’s IT employees.
• Relatively low operative expenditures of IT infrastructure.
• Solution autonomy and higher security.
Deficiencies:
• Relatively high capital expenditure in IT infrastructure.
• The introduction of new services, or surges of existing services are difficult to plan.
• The need to hire IT specialists to maintain physical servers, network equipment, and so on) leads to additional costs.
• Indirect costs for IT engineering systems.
“Cloud based” implies that IT assets are located in the “cloud”.
Benefits:
• Relatively low capital expenditure in IT infrastructure.
• High level of planning of maintenance costs for IT infrastructure.
• Good communication, linear relationship between the resources used and their cost.
• Easiness to implement new solutions and expand existing IT services.
• No need for additional staff.
• No need for indirect engineering costs.
Deficiencies:
• Relatively high operative expenditures of IT infrastructure.
• Higher requirements for Internet bandwidth and backup channels.
“Hybrid” architecture provides combined solutions.
Benefits: The benefits of the first two solutions are used.
Deficiencies: A higher capital and operative (CAPEX and OPEX).
Recommendations for selection:
“Cloud based” solution is more preferable for initial projects, small organizations, organizations with developed geography and so on. “On-site” solution is more preferable for well-developed organizations, financial institutions, organizations where access to the Internet is not a business requirement. “Hybrid” solutions can supplement the IT infrastructure and replace some components of the IT architecture.
Infrastructure platform choice strategy
If you choose “On-premises” as deployment infrastructure, there are the following options:
• Physical servers as a foundation;
• Virtualization platform as a basis;
• Mixed infrastructure with no dominance.
“Physical servers” implies that IT services are located on physical servers. Benefits:
• Relatively low capital expenditure of IT services for small solutions;
• The resources of the physical server are fully allocated to the tasks of a particular service.
Deficiencies:
• The complexity of maintenance as the infrastructure grows;
• Deployment and recovery speed.
• Sub-optimal use of computing resources.
“Virtualization Platform” implies that IT services are located on the virtualization platform as virtual machines. Benefits:
• Relatively low operative expenditures of IT infrastructure.
• The platform is de facto standards for the deployment of “On-premises” solutions.
Deficiencies: Relatively high capital expenditure in IT infrastructure.
Recommendations for selection:
“Physical servers” solution is more preferable for small, isolated or remote IT services, or high volume systems. For all other cases, it is better to use a virtualization platform.
Choice strategy for data storage system
If you choose “On-premises” as deployment infrastructure, there are the following options:
• Physical servers and Direct-Attached Storage (DAS);
• Centralized Data Storage System, i.e. Network Attached Storage (NAS) and Storage Area Networks (SAN);
• Distributed Data Storage System, i.e. Digital Data Storage (DDS) and Software-Defined Storage (SDS).
Physical servers implies that the data is located on physical servers.
Benefits:
• Relatively low capital expenditure of IT services for small solutions.
• The resources of the physical server are fully allocated to the tasks of a particular service.
Deficiencies:
• The complexity of maintenance as the infrastructure grows.
• Deployment and recovery speed.
• Sub-optimal use of computing resources.
Centralized Data Storage System (NAS, SAN) implies that the data are located on a single data storage system partially or completely. DSS is a single complex consisting of controllers and disk storage racks.
Benefits: Relatively low operative expenditures of IT infrastructure.
Deficiencies: Relatively high capital expenditure of IT infrastructure.
Distributed Data Storage System (DDS, SDS)” implies that the data is distributed between different physical servers. A storage system is a complex distributed within the network and consisting of data controllers and disk storages.
Recommendations for selection:
“Physical servers” solution is more preferable for small, isolated or remote IT services, or high volume systems. For all other cases, it is better to use a virtualization platform.
Strategy of choosing the manufacturer
The strategy for choosing software and hardware determines the approach to the choice of manufacturer, standardization, and so on.
The following options can be considered:
• Use of a limited list of manufacturers;
• Use random list of manufacturers.
Using a specific manufacturer for each category of IT assets implies using hardware and software standards within the organization.
Benefits:
• Implementing IT asset standards simplifies providing an organization staff with IT assets;
• It facilitates the implementation and maintenance of IT infrastructure, and increases the level of the organization’s information security.
Deficiencies: Relatively high cost and dependence on the manufacturer/supplier.
Using a random manufacturer implies use of recommendations instead of hardware and software standards within the organization.
Benefits: Relatively low cost and promptness in procurement of IT assets.
Deficiencies:
• The process of providing an organization staff with IT assets is more sophisticated and takes longer;
• It complicates the implementation and maintenance of IT infrastructure, and
• reduces the level of the organization’s information security.
Recommendations for selection:
The first licensing option is recommended is recommended to organizations with close integration and dependence of business and Information Technology or a large number of employees.
Licensing strategy
The licensing strategy determines the approach to licensing methods. The following options can be considered:
Using an “Enterprise” license agreement with the annual software update. Licensing is an ongoing IT process.
Benefits:
• Greater flexibility of licensing.
• Maintaining the high level of IT infrastructure and information security due to using updated versions of systems and solutions.
• Systems are upgraded smoothly, with no surges in requirements of IT, human resources or time.
Deficiencies: Relatively high cost.
Purchasing commercial off-the-shell retail versions with no software update. Licensing “upon request”.
Benefits: A relatively cheaper option.
Deficiencies:
• Less freedom in licensing.
• The level of maintaining IT infrastructure and information security is reduced due to using not the most updated versions of systems and solutions.
• Systems are upgraded in jumps (every three, four years), and require additional IT resources, people, and time.
Recommendations for selection:
The first licensing option is recommended to organizations with close integration and dependence of business and Information Technologies.
The strategy of building engineering systems
“On premise” and “Hybrid” solutions demand to determine the engineering system requirements. The engineering systems requirements for may include:
• Physical requirements for the premises of the data center, server room, data cabinets etc.
• Requirements for a Structured Cabling System (SCS).
• Requirements for redundancy, reservation and so on.
Testing strategy
Testing is one of the important elements when building an IT architecture. Testing questions have to be identified at the design stage. There are the following platforms:
•“Test or Development” is a platform with individual IT services deployed which is used to develop services or adjust IT service elements.
•“Pre-production” is a smaller “Production” platform containing all the components of the IT architecture. It is used to test the interaction of IT services and allows emulating troubleshooting, estimating performance, and so on.
•“Production” is a platform with detailed computing resources providing IT services.
Recommendations for selection:
Various solutions can be implemented depending on the business requirements and the organization’s financial capacity. A detailed description is further discussed in this guide.
Redundancy strategy
Defining the redundancy level of IT infrastructure components indicates the requirements for duplication of components. It can be reviewed as follows:
• Components of engineering systems (channels and communication cables, switching racks, etc.). Reservations (duplication or redundancy) at the level of critical elements, such as:
• Channels and communication cables (two or more in different stacks),
• Excessive number of operating points (ensures the organization growth and backup).
• Device components (server, switch, and so on). Duplication at the level of critical elements such as:
•Processors (two or more),
• RAM (two or more),
• HDD (two RAID1hard drives + one backup)
• Network cards and adapters (two cards with one or more ports)
• Power supply units (N+N or N+1)
• IT service components. Backup at the device level and the type of their inclusion. For example:
• Two servers in a failover cluster
• Two servers performing the same function (two domain controllers)
• Two servers performing different functions in the normal mode, but can assume the neighboring function in the case of a failure (File server and print server. In case of failure, one can install the function on a neighboring server).
• Geographically separated devices within the site. Allocating a pair of devices in different racks, rooms, or buildings within the same site.
• Geographically separated devices at the site level. The allocation of a pair of devices on different sites.
Determining the backup level depends on the business criticality of failure or downtime. It is analyzed within Risk Management, formalized in documents on equipment standards.
Backup and Archiving Strategy
Backup systems and archiving IT infrastructure may define the following requirements:
• System components must be installed on dedicated physical elements (servers, storage, and so on)
• Backup and archiving systems on the same components can be combined.
• Access rights to (automatic) backup accounts should not provide an opportunity to delete data or overwrite them.
Backup building strategy
Backup component is one of the important elements when building an IT architecture. It relates to the information security, fault tolerance and recovery. The fault tolerance can be as follows:
• Fault tolerance at component redundancy level;
• Fault tolerance at the level of duplicating elements;
