Kitabı oku: «IT Architecture from A to Z: Theoretical basis. First Edition», sayfa 2
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.
