Who needs Enterprise Architecture and why?

Copyright © 2009 Zabegalin E.V.

1 Current State of Architectural Methodologies and Practices

AT foreign countries ah, a certain range of topics has long been methodologically and practically developed, the subject of which is the architecture of complex organizational and technical objects such as enterprises, "electronic governments", corporate information systems.

AT Russia, despite the fact that the terms "information system architecture"“Enterprise IT architecture”, “electronic government architecture”, have long become fashionable and are widely used among IT professionals, a serious methodological interest in “architectural” topics is present only in a narrow circle of enthusiastic specialists (including authors of publications), activities which in this area is mainly educational and popularizing in nature.

Therefore, if we talk about the standardization of "architectural" methodologies in Russia and their subsequent wide practical use in domestic companies, then this seems to be a matter of an uncertain future. However, the “architectural” movement in Russian enterprises should practically begin now.

"Enterprise Architecture", in Russian "Enterprise Architecture" (AP), has developed into a general discipline as a step historical development set of methodologies related to the architecture of automated information systems - these are the methodologies of J. Zachman, Art. Spivak, CIMOSA, GERAM, TOGAF, etc. An analysis of this historical process is presented in sufficient detail in.

To date, the most prominent and significant sources of modern methodological ideas and practices of EA include:

The Zachman Framework for Enterprise Architecture;

ISO 19439:2006 "Enterprise integration - Framework for enterprise modeling";

ISO 15704:2000 standard. Industrial automation systems - Requirements for enterprise-reference architectures and methodologies;

"Federal Enterprise Architecture" (FEA), practiced and developed by the US government;

"Extended Enterprise Architecture Framework" (E2AF), developed by independent organization"Institute For Enterprise Architecture Developments" ;

The Open Group Architecture Framework (TOGAF).

Along with this, in Russia in 2000, the conceptual architectural scheme "3D-Enterprise" was developed and published, in which the matrix ideas of J. Zachman were supplemented by a third - temporary - dimension to reflect the transformation of the enterprise structure.

It is noted that significant interest in the topic of AP is explained by the urgent need of modern managers and analysts for a multidimensional systemic description and planning of the development process of organizations (including enterprises). Interest in such a description is dictated, at least, by the practical need to always have enough meaningful knowledge about the current structure of the organization, which can also be used for rational planning of the transformation of the organization in changing conditions. If such knowledge is available, maintained and used in the organization in an alienated form, then it turns into an effective management tool. This is especially true for new leaders and managers of organizations (enterprises).

Figure 1 - Managers and analysts have a practical need to always have sufficient meaningful knowledge about the structure of the organization (enterprise)

At the same time, the level of abstraction and complexity of most of the listed methodologies remains very high and may hinder their effective use in their organizations. practical managers and specialists. different kind The "matrices" and "cubes" proposed in the listed methodologies may seem unnecessarily artificial and, therefore, inconvenient for practical use. So, for example, the nature of the same "Zachman Matrix" seems to be more philosophical than practical engineering, it is rather a schematically visualized specification of a systematic approach to the analysis of large and complexly structured organizational and technical objects. However, this does not in the least negate the enormous methodological value and practical significance of the developing discipline of AP.

In the interests of the practical application of the discipline of EA, overcoming this artificiality can be started by searching for an answer to the question: who and why in an enterprise might need an “Enterprise Architecture”?

2 Purpose of "Enterprise Architecture"

Figure 2 schematically depicts the structure and content of the generalized enterprise. It can be seen from this diagram that AP, considered and used as a model, can be practically in demand in an enterprise only as a management tool, because neither technical nor production personnel need AP to perform their production functions.

This conclusion follows from the fact that all the management objects indicated in the diagram are simultaneously objects to be reflected in the EA model, which in the future will also become a management object (the architectural model of the enterprise is shown in the diagram as its component).

Figure 2 - Generalized structure of the enterprise

As a management tool, EA can be used to support all its main functions - analysis, planning, organization, motivation, control, coordination.

Figure 3 - "Enterprise Architecture" can be used to support basic management functions

From the role of EA as a management tool, at least two main functions of the Enterprise Architecture can be derived:

in the contour of the operational management of the enterprise - it is the formalization and provision of alienated knowledge about the existing structure and functioning of the enterprise;

in contour strategic management enterprise - is the formalization and provision

alienated knowledge about the planned structural and functional transformations of the enterprise.

Figure 4 - The main functions of the "Enterprise Architecture"

AP can be used with these functions at all levels of management: from the enterprise management level to the shop floor. This is (explicitly or implicitly) provided by well-known methodologies -

"Zachman Framework for Enterprise Architecture", "Extended Enterprise Architecture Framework", "TOGAF",

"GERAM", ISO 19439-2006 standard ("Generic", "Partial", "Particular" levels).

After J. Zachman, the most specific and consistent management levels for the use of AP are proposed in the “3D-Enterprise” scheme - “Main needs, goals, plans, restrictions”, “Business model”, “Logic model”, “Technical architecture”, “Detailed implementation", "Practice of use".

3 Composition of the "Enterprise Architecture"

All architectural methodologies agree that for a sufficiently meaningful description of the device of an enterprise (organization), it is necessary to use many different points of view (views) on this device. These viewpoints may also be referred to as architectural domains, content aspects, and the like. Describing (and modeling) the structure of an enterprise from many different perspectives results in an "Enterprise Architecture".

Different methodologies use different sets of architectural viewpoints. For example:

in Zachman Framework for Enterprise Architecture, these are "Data", "Function", "Network", "People", "Time", "Motivation";

in the Extended Enterprise Architecture Framework (E2AF) is "Business", "Information", "Information

Systems", "Technology Infrastructure";

in GERAM and in ISO 19439-2006 these are "Function", "Information", "Resource", "Organization";

in TOGAF they are "Business", "Information", "Application", "Technology".

The author of this article considers it practically expedient to overcome such a variety of methodological approaches to the choice of substantive aspects of EA through the use of any one simple and understandable principle for the logical derivation of these aspects.

Such a principle can follow from the general fundamental understanding of the "system" as a set of purposefully interacting elements. Based on this, the following basic and easily understood substantive aspects of the "Enterprise Architecture" can be fundamentally distinguished:

1) Construction aspect- an enterprise is built from many different physical and information components, including: fixed assets and other property, consumed and produced energy, personnel, paper documents, electronic information, automation and automatic control tools, that is, these are the “building bricks” from which the enterprise is physically composed. To this aspect, you can also apply the synonym term - the structural aspect.

2) Functional aspect- the enterprise operates, producing products, providing services, purchasing and selling raw materials, materials, products, technological and business processes are carried out on it, that is, this aspect highlights the external and internal manifestation of the enterprise's activities;

3) Logical aspect- the activity of the enterprise is purposeful, in accordance with the goals of the enterprise, its construction and functional structures are determined. This aspect highlights the business sense of the creation and operation of the enterprise.

The main components of the logical structure of the enterprise are such speculative components as the purpose, mission, vision, goals of the enterprise, its place in the market, the principles for choosing the main types of its building components, the principles of functioning and development of the enterprise.

AT In the Zachman Matrix, this aspect is indicated by the name of the first line "Scope" ("The purpose of the Row 1 are to define the boundaries of the Enterprise, what is being included …" ).

AT Federal Enterprise Architecture (FEA) is a "Performance Reference Model".

AT E2AF and in GERAM the logical aspect is not explicitly distinguished and is included in the "Business" aspect. However, the E2AF core principles state: "No strategy, no enterprise architecture ... No Scope - No enterprise architecture

The Scope and the Goals & Objectives sets the level of abstraction of the enterprise architecture ... Business Drivers, Goals & Objectives are leading ..." .

AT TOGAF logical aspect corresponds to "Architecture Vision" ("... key elements of the "Architecture Vision"- ...

enterprise mission, vision, strategy, and goals ..., include architecture principles, define breadth of coverage of enterprise, the specific architecture domains ..." ).

Summing up the review of the logical aspect and using the philosophical language, it can be argued that the logical aspect of the enterprise structure is necessary to represent the "Integral idea of ​​the enterprise", "Integral idea of ​​the enterprise", "Integral concept of the enterprise", in English we can offer - "The Notion of the Enterprise" .

4) Chronological aspect- the company is created, operates and changes over time. The past, current and planned structural states of the enterprise should be recorded, i.e. - this is the "History of Life".

In GERAM, in ISO 15704-2000, ISO 19439-2006, many life cycle stages are proposed for structuring the temporal aspect: "Identification", "Concept", "Requirements", "Design", "Implementation", "Operation", "Decommission" .

AT methodology TOGAF - Architecture Development Method (ADM) - the temporal aspect is reflected by the sequence of stages of development, implementation and change of the "Enterprise Architecture" itself.

The "3D-Enterprise" scheme allows planning the prospective states of an enterprise in the EA time dimension, including individual projects and development programs. In particular, the sequence of implementation of technological components (systems) of an enterprise may include: strategic analysis of goals and needs, design of technical solutions, detailed implementation of a system of solutions, implementation of solutions, use (operation) of the system, improvement of the system.

Figure 5 - The main points of view on the structure of the enterprise

Thus, the "Architecture of the enterprise" can be defined as the structure of the enterprise, considered by its management, at least from four main points of view (in four main aspects) and represented (including modeled) by an appropriate set of four main types of architectures Enterprises: logical, construction (structural), functional and chronological.

The components of the building architecture of an enterprise can be considered:

organizational architecture is the organizational structure of an enterprise;

property architecture is the ownership structure of an enterprise;

information architecture is the structure of a set of documents (organizational, regulatory, technical, etc.) and enterprise information databases;

production and technological architecture is the structure of the production and energy capacities of an enterprise, as well as the structure of instrumentation and automation complexes and automation equipment complexes.

To The components of the functional architecture of the enterprise can be attributed to:

structure of functional systems and subsystems of the enterprise;

structure of business functions and business processes of the enterprise;

structures of flows of materials and information at the enterprise.

Figure 6 - Integrated view of the "Enterprise Architecture"

In addition to the four main types of enterprise architecture, others are possible, corresponding to other points of view, for example:

IT architecture is the structure of a set of automated information systems (information technology) of an enterprise;

The business architecture is the architecture of an enterprise considered without its IT architecture.

4 How to obtain and use Enterprise Architecture

The management of an enterprise can obtain an AP in two ways: the first is to develop an AP by the staff of the enterprise, the second is to turn to external consultants.

The first path will require the management of the enterprise:

formation of a working group, which then will need to be transformed into a permanent architectural service of the enterprise;

selection and acquisition of ready-made specialized computer program for electronic modeling of AP and training of enterprise specialists in its use;

independent development and documentation of the methodological support of the EA;

independent development of AP.

The development of the AP by external consultants will require the management of the enterprise to conclude a contract for the performance of work:

for the direct development of the AP;

on the development and documentation of the methodological support of the EA;

on the creation of an architectural service of the enterprise.

The computer programs for electronic modeling of business processes and system structures that exist on the market make it possible to convert databases of electronic models from their specialized formats to the www-format and then publish them on the internal (intranet) site of the enterprise. This allows realizing

convenient and license-free access for managers and specialists of the enterprise to electronic model AP.

Subsequently, the formed and prepared architectural service of the enterprise can independently solve the problems of modeling options for the future state of the AP in the interests of acceptance by management strategic decisions for enterprise development.

List of sources used

1. Zinder E. "3D-enterprise" - a model of the strategy of a transforming system. "Director of Information Service", No. 4, 2000. http://www.sept2000.ru/articles/2008/03/03/1/.

2. Zinder E. Enterprise Architecture in Context business reengineering. "Intelligent Enterprise / Corporate Systems", No. 4, No. 7, 2008.

3. Galaktionov V. System architecture and its place in enterprise architecture. "Director of Information Service", No. 5, 2002.

4. Danilin A., Slyusarenko A. Architecture and strategy. "Yin" and "Yang" of information technology enterprises. M. Internet University of Information Technology, 2005.

5. Drozhzhinov V., Shtrik A. Standardization of the architecture of US government departments. PC Week/RE. No. 28, No. 31, 2005.

6. Zachman John A. The Zachman Framework.http://www.zachmaninternational.com/

7. The Office of Management and Budget. Federal Enterprise Architecture (FEA).http://www.whitehouse.gov/omb/e-gov/fea/

8. Schekkerman J. Extended Enterprise Architecture Framework Essentials Guide. Institute for Enterprise Architecture Developments, 2006.http://www.enterprise-architecture.info/

9. The Open Group Architecture Framework (TOGAF).http://www.opengroup.org/architecture/togaf8doc/arch/toc.html

10. Generalized Enterprise Reference Architecture and Methodology (GERAM). IFIP–IFAC, 1999.

11. Ivanova I.A. Management: Tutorial. - M.: RIOR Publishing House, 2004.

We have already noted that there is no single correct definition what is enterprise architecture. Various consulting companies, industry associations, professional associations use slightly different concepts and methods to describe this concept. Moreover, these concepts and methodologies are in constant flux, so trying to accurately describe what an enterprise architecture is in a way that reflects today's thinking is "shooting a moving target."

Generally speaking, when developing and using enterprise architecture, of course, it is advisable to adhere to any one methodology that would provide unity in approaches and appropriate sets of tools for describing the architecture. We briefly review the most well-known techniques in "Architecture description techniques. Zachman and Gartner models, META Group and TOGAF techniques" and "NASCIO. 4 + 1 models and SAM. Microsoft techniques and others. Choosing the "optimal" technique" . Here we detail our general idea about the concept of enterprise architecture.

The enterprise architecture is a dynamic and powerful tool that helps organizations understand their own structure and how they perform their work and functions. It provides a "map" of the enterprise and a "route plan" for change in both business and technology areas.

Typically, an enterprise architecture takes the form of a fairly broad set of models that describe the structure and functions of an enterprise. An important area of ​​application of these models is the systematization of the information technology planning process and the provision of better conditions for the process decision making.

The individual enterprise architecture models are logically organized so as to collectively provide an ever-increasing level of detail information about the enterprise - its goals and objectives implemented corporate programs and organizational structure, systems and data, technologies used and all other areas of interest.

This is a rather boring and dry definition of a tool that can, in fact, have a huge impact on solving complex problems and provide a fresh perspective on the complex and controversial situations that are constantly encountered in the activities of any organization. An enterprise architecture is not easy to create. On the other hand, the difficulties associated with this should not be exaggerated. The bottom line is that once developed, an enterprise architecture can bring significant benefits.

Enterprise architecture is more of a process than a static thing. We will not say that its creation is an easy fun walk. But nevertheless, it can be an attractive and, in a sense, bewitching activity. Enterprise architecture is not a simple subject, but we will try to make it less "intimidating and disheartening" in what follows. The methods of describing the architecture of an enterprise that already exist today make it possible to organize the corresponding process in the presence of even a minimal amount of initial information in an intuitive and natural manner. At the same time, the completeness of the description of the architecture can be increased gradually, as the understanding of the object of the description of the architecture grows - the structure and functions of the enterprise, as well as supporting information technologies.

When designing an enterprise architecture, you have to deal with a large number of dimensions and relationships between them that must be taken into account. Therefore, it is no coincidence that many of the techniques for describing architecture, which we will consider next, have their roots in such a discipline as systems analysis. Generally speaking, the development of an enterprise architecture is not a technical process that is exclusively related to information technology. Of course, for its development, as a rule, appropriate technological tools, but for the most part these are tools that allow you to create diagrams and texts, i.e. software packages familiar to most people. The use of these is sufficient simple tools based on appropriate methodologies, however, allows you to collect basic information about the activities of the organization, connect various facts and draw conclusions that simplify and clarify the complex decision-making process that is repeated in business every day. More important is the creative component of this process, which will be discussed in lectures 10-12.

A good enterprise architecture provides a balanced analysis of the facts about the organization and gives management ways to examine their organizations and how they operate, helps them formulate new strategies, and provides direction in the development planning process to keep organizations in line with ever-changing conditions and priorities. We are talking, of course, about medium-term and long-term planning horizons, both in terms of business and technology. A good enterprise architecture provides responsiveness and flexibility, which is reflected in the appropriate organizational forms, processes, systems, information and application systems portfolio.

The users of the enterprise architecture are a fairly large audience of specialists and managers:

• professionals in the field of creating information systems who are involved in relevant corporate projects to create applications that are important for the enterprise;
• system architects, who are responsible for creating the architecture of individual information systems;
• business analysts who lead the process of designing organizational structures and business processes;
• executives who are interested in a systematic, structured analysis of the problems and opportunities that open up for business.

If you look at the goals that are pursued by a variety of approaches to describing the architecture of an enterprise, then in successful, correct methods, you can find a lot in common:

• use for the analysis of multiple points of view on the object of study (the enterprise and its information systems) in order to "divide and conquer" in the process of combating the objective complexity of the real world. It is important to understand that no single point of view is sufficient to understand the whole;
• in order to provide a synthesis process, all models that are included in the architecture are associated with other models. They are either more detailed decompositions or related views. This wealth of relationships between models directly determines the quality of the architecture.

So, before continuing, here is another definition of enterprise architecture, which is given on the website www.geao.org of the "Global Enterprise Architecture Organization" (GEAO - Global Enterprise Architecture Organization):

"Enterprise architecture describes the ways in which the overall vision of an organization is reflected in the structure and dynamics of an enterprise. At various levels of abstraction, it provides a unified set of models, principles, guidelines, and policies that are used to create, evolve, and enforce systems at scale and the context of the entire enterprise as a whole.

Note that the term "system" here does not necessarily refer to computer system– it can also refer to organizational structures, management systems, etc. But this definition itself is rather abstract, so that we will try to give it an increasing degree of detail as we present it.

In the following text, we use information from several sources and try to compile it within the framework of some integrated concept of enterprise architecture, which includes the main elements of most methodologies. In particular, we will follow the recommendations.

We have already noted that the driving force behind enterprise architecture is a holistic vision that cuts across organizational boundaries. Shown in Fig. 4.1, the diagram proposed by GEAO illustrates the various levels of abstraction associated with enterprise description. Note that within one organization there is only one enterprise architecture, but at the same time, at the level of individual systems, there may be a large number of solution architectures. Enterprise architecture covers both business and IT aspects, as well as the development processes, architecture evolution, and the governance and control structures of those processes that move from the current state of the architecture to the desired future state.

Viktor Galaktionov, 05/20/2002
Magazine "Director IS", #05, 2002 // Publishing House "Open Systems" (http://www.osp.ru/)

AT modern conditions It is especially important to constantly and correctly align the IT aspects of the design of a modern automated enterprise with current business aspects. This should be done starting with the definition of the business architecture of the enterprise and the development of the system architecture (IT architecture) consistent with it. In this article, the author shares his practical experience in developing system architectures for large banks and gives specific advice on how this can be done, including for enterprises in other industries.

I am a geographer, not a traveller. I miss travellers. It is not geographers who count cities, rivers, mountains, seas, oceans and deserts. The geographer is too important a person, he has no time to roam. He doesn't leave his office. But he hosts travelers and writes down their stories.

Antoine de Saint-Exupery. "The little Prince". Chapter 15. Geographer

It is known that any business modern company more and more dependent on information technology. The development of certain business areas, for example, the development of the "card business" in banks, became possible only thanks to the emergence of modern IT. Of course, this is also true for enterprises in other industries. Therefore, we can hope that the experience presented can be used in the business of any other, non-banking company without significant adaptation efforts.
The features of the current level of development of banking information technologies lies in the fact that in many banks that were able to maintain their business after the 1998 crisis and today continue to actively develop and increase it, high-tech banking solutions are being introduced against the backdrop of ongoing operation. software systems and complexes of previous generations, often obsolete. On the other hand, a shutdown of the banking business even for a few hours, much less a shutdown for one or more days to decommission an obsolete software and the commissioning of a new one, in most cases will be tantamount to the loss of business. In this situation, at any moment in time, it is necessary to have a clear idea of ​​the current status of all implemented and operated information systems, as well as an equally clear understanding of their further development, taking into account the prospects for the development of the bank, its architecture as enterprise architecture. (In the English-language literature - methods, articles, standards - this corresponds to the term enterprise architecture.)
It should be noted that the enterprise architecture exists independently both on our consciousness and on the size of this enterprise - whether it be a global corporation, a small factory, a small commercial enterprise etc. A small enterprise has the same architecture as a large one, while they do not differ too much in terms of the composition of the components. However, some managers understand this and can afford to pay attention to all aspects of the organization of their own enterprise (as a rule, these are the heads of large companies), while others do not. It’s another matter that a small enterprise can have only two or three products, the mission and strategy are not explicitly fixed (this trouble, by the way, is common in large companies), the number of employees is 30 people, and two computers with MS are used in production. Word 97. But even in this case, this is all that constitutes the architecture of this enterprise.
The article presents a fairly detailed and at the same time pragmatic approach to organizing work on the analysis of the enterprise architecture as a whole and planning the system architecture, including its documentation. The main goals of documenting business knowledge (development of enterprise architecture) are to ensure the safety of investments in the business and business transparency at all levels.
Business transparency begins with a transparent understanding of the enterprise architecture, with a clear division into three interdependent levels: the strategic level, the business architecture level, and the systems architecture level. The system architecture is determined by the business architecture, and its design can only be based on the business architecture, which in turn depends on the strategy of the enterprise. This approach allows, in our opinion, not only to properly organize the work itself and make a correct division of functions and responsibilities of the business architect ("business developer") responsible for business development, that is, the business architecture of the enterprise, and the system architect, but also , most importantly, to build a balanced enterprise architecture that adequately corresponds to its mission and strategy.
The main definitions are given at the beginning of the article. Then the composition and content of the system architecture are considered, the relationship between the entities of business architecture and system architecture is analyzed. The phases and participants of the life cycle of the system architecture, in particular, the functions of the participants, are considered in sufficient detail. Finally, the structure of knowledge underlying the system architecture is presented in an abbreviated form, and final conclusions are drawn.

Basic concepts

Enterprise architecture- this is the most general and comprehensive representation of an enterprise, in this case, a bank, as an economic entity that has short-term and long-term goals for conducting its core business, defined by a mission in the regional and global, in our case, the financial and credit market, and a development strategy, external and internal resources necessary to fulfill the mission and achieve the goals set, as well as the established rules for conducting the main activity (business).
For the purposes of systems analysis, the architecture of an enterprise can be considered in two aspects:

• static - according to the state of the bank at some fixed point in time;
• dynamic - as a process of transition (migration) of the bank from the current state to some desired state in the future.

The enterprise architecture considered in statics consists of the following elements:

• mission and strategy, strategic goals and objectives;
• business architecture;
• system architecture.

Enterprise Architecture Considered in Dynamics is a coherent, coherent plan of action and coordinated projects required to transform an organization's current architecture to a state defined as a long-term goal, based on the organization's current and planned business goals and business processes.

Rice. 2.

Thus, the enterprise architecture in the general case is described by the following sequentially dependent sections (see Fig. 1 and Fig. 2):

• formulated mission and strategy of the bank, strategic goals and objectives;
• business architecture in the current (as is) and planned (to be) state,
• system architecture in the current (as is) and planned (to be) state;
• action plans and projects for the transition from the current state to the planned one.

On fig. Figure 1 shows that the implementation of the migration plan does not mean a freeze in the development of business and system architecture. Thus, the planned system architecture is the "to be" architecture only at a certain stage of the enterprise development. At the same time return to strategic level mission and strategic goals and objectives does not mean the need to revise the mission and strategy. But at the end of each cycle, an analysis of the effectiveness of the developed and implemented measures is necessarily carried out, if necessary, at the second iteration, the business architecture, system architecture are adjusted, and new migration plans are implemented. There can be several cycles at each moment of time, each such cycle does not necessarily affect the entire enterprise as a whole, the cycle can affect certain areas, certain business issues and can be recorded as a separate project.
With a phased migration plan, to fix the results achieved, it is possible to build intermediate (migration) one or more architectures.
Mission, strategy and business goals determine the direction of the bank's development and set long-term goals and objectives.
Business architecture based on the mission, development strategy and long-term business goals, determines the necessary organizational structure, the structure of sales channels and the functional model of the bank, documents used in the process of developing and implementing products. The functional model describes business processes aimed at the implementation of current tasks and long-term goals.
Business architecture includes:

• products and services offered and planned for sale by the bank (including individual schemes for their production), formalized in the form of a single register of products and services, which also contains client segmentation, tariffs and product owners;
• channels for the sale of products and services, built both on the basis of structural and territorial divisions of the bank, and on the basis of modern information technologies;
• functions and processes for the implementation of external and internal products and services, forming trees of functions and processes (hereinafter referred to as business functions and business processes);
• financial and administrative documents (both in paper and in in electronic format), formalized in the form of a single register (album of forms) of bank documents;
• document flows defined regulations on internal and external document flow;
• organizational structure, including staffing bank and its territorial subdivisions, which are independent economic units ( legal entities), committees, working groups and role functions of individual employees, job descriptions, regulations on departments and working bodies and other documents regulating the relationship and distribution of responsibility between bank employees, as well as between structural divisions jar.

System architecture(IT architecture, enterprise IS architecture) - defines a set of technological and technical solutions to ensure information support bank operation in accordance with the rules and concepts defined by the business architecture.
Further, by “solutions” we mean, depending on the context, not only specific equipment and software and information systems, but also the principles, standards and methodologies used in the development or selection of information and software systems, in the selection and configuration of equipment.
Migration plans determine the scenario of the bank's transition from the current state to a promising one, determined by strategic goals and objectives. Migration plans define both business and system architecture transformations. With staged migration, for the purpose of formalizing intermediate results, intermediate (migration) one or more business and system architectures are developed. Migration plans in accordance with the project management methodology adopted by the bank are formalized as separate projects, including, in particular:

• definition of a project as a set of tasks and activities;
• phases and deadlines for the implementation of the project as a whole and the tasks and activities that make up the project;
• analysis of the competitive environment and risks associated with the implementation of the project;
• the composition of the expenditure items of the project budget;
• criteria for the success of the project and the expected economic effect.

System architecture

The system architecture consists of three interrelated components - the application architecture, the data architecture, and the technical architecture (see Figure 3). The system architecture in the system of standards of a given enterprise determines the rules for the formation of its components and ensuring the interaction between them.

Rice. 3.

System Architecture Components

Application architecture includes:

• applied systems (applications) that ensure the execution of business functions and business processes;
• interfaces for the interaction of application systems with each other and with external systems and data sources or consumers;
• tools and methods for developing and maintaining applications.

The data architecture includes:

• automated databases that provide the accumulation, storage and processing of data determined by the business architecture;
• database or data storage management systems used for this purpose;
• rules and means of authorizing access to data.

Technical architecture consists of network architecture and platform architecture.
Network architecture includes:

• local and territorial computer networks, including physical own and leased communication channels and channel-forming equipment;
• communication protocols, services and addressing systems used in networks;
• emergency plans to ensure the uninterrupted operation of networks in emergency situations.

Platform architecture includes:

• computer hardware - servers, workstations, drives and other computer equipment;
• operating and control systems, utilities and office software systems;
• emergency plans to ensure the uninterrupted operation of equipment (mainly servers) and databases under emergency conditions.

To solve the problems of system architecture in the state of the company, as a rule, a dedicated System Architect Service. This service is responsible for the following tasks:

• coordination of work of IT departments on documenting the current system architecture at the initial stage and subsequent maintenance of the knowledge base about the system architecture up to date;
• determination of promising directions for the development of the system architecture in accordance with the strategic goals and objectives of the bank, detailed in the form of a promising business architecture;
• designing (together with other specialized departments in information technology) a promising system architecture and plans for migration from the current state to the future;
• formulation of requirements and restrictions to the created or implemented automation tools that ensure the quality and integrity of the system architecture;
• control of the consistency of system architectures developed within the framework of various projects;
• monitoring compliance with the requirements to ensure the quality and integrity of the system architecture by the bank's divisions involved in the development, maintenance and operation of information systems.

Separately, one should dwell on one fundamental issue: who develops the system architecture - a system architect or software developer, technologist. The correct decision is when the responsibility for the development of the system architecture is assigned to the IT departments that design, develop, test, maintain (including decommission) software and hardware systems and complexes. System architecture documentation is part of the mandatory design and operational documentation. This approach allows you to create a small system architect service. Otherwise, the development of a system architecture by a dedicated service requires a significant increase in the number of system architects, and development processes either slow down greatly, or the developed system architecture becomes inadequate already in the process of its development.

Relationships between system architecture and business architecture

The enterprise architecture is fully described by the following entities (see Figure 4):

1. Mission and strategy of the bank, strategic goals and objectives.
2. Products and business processes.
3. The documents.
4. Organizational structure.
5. Applications.
6. Data.
7. Equipment.
8. Action plans and projects for the transition from the current state to the planned one.

Rice. 4. Interrelation of entities of the top level of the enterprise architecture

On fig. 4 shows only top-level entities. Each of the entities breaks down into a set of more detailed entities. Thus, only the entity “Products” ultimately breaks down into more than ten tables, including food groups, tariff plans, target segments clients, etc.
Obviously, there are strong relationships between all these entities. For example, the implementation of a product is accompanied by certain documents, supported by information support by certain applications and modules that use certain databases. Various employees and departments are involved in the implementation of this product. The product has an owner.

Rice. 5. Enterprise architecture and the place of system architecture in it

On fig. Figure 5 provides an enlarged graphical representation of the enterprise architecture and its defining components.
An example of key relationships between the main elements of business architecture and systems architecture is shown in Fig. 6 in the form of an ER diagram.

Rice. 6.

Essences and relationships of two architectures

System Architecture Life Cycle

To regulate the life cycles (LC) of systems in general (including enterprises), as well as their information systems and software (PS), in particular, there are a number of standards. They provide for the possibility of adapting life cycle models, including phases (stages) to the specifics of a particular enterprise and project. Thus, the life cycle phases described in this and the next sections do not contradict the normative ones and are not a dogma. Their advantage in terms of use in this article is the simplicity and experience of practical application.

Rice. 7.

The system architecture life cycle consists of the following phases: (see Figure 7):

• initial documentation;
• usage;
• design;
• migration.

NOTE. After the migration phase is completed, the process is repeated, the next iteration begins with the use phase. The initial documentation phase in the development of new IS may be absent. System architecture development begins with the design phase.
During the use phase, evolutionary development system architecture in accordance with previously formulated principles and without changing the main technical and technological solutions.
EXAMPLE. Let the system architecture of the maintenance program be developed at the design phase accounting in the central office and branches and implemented (migration phase). Knowledge about the system architecture of this solution passes into the stage of use until new business requirements arise for the completion / modernization of the built system. Knowledge of the system architecture of the created solution is used by the company to build a data warehouse in order to consolidate information and subsequently receive management reporting. But on the basis of this knowledge, the system architecture of the data warehouse is designed, and then the management reporting systems, which subsequently, having passed their stages of migration, enter the phases of use. Thus, we can speak of a multi-layer system architecture model, in which the system architecture in different layers can be at different stages of the life cycle (see Fig. 8).

Rice. eight.

At the design phase, a promising (to be) system architecture is developed, new principles for building a system architecture are formulated, and new basic technical and technological solutions are developed in accordance with these principles. Usually the reason for the execution of this phase is significant changes in business architecture, the emergence of new business requirements that significantly affect the system architecture.
At the migration phase, a set of organizational, technical and technological measures is carried out to ensure the transition of the system architecture from the current state to a promising one or to the next intermediate state during phased migration in accordance with the migration plans prepared in the previous phase.
The system architecture life cycle is related to the software life cycle. The life cycle of software tools (PS) consists of the following main phases:

• feasibility study;
• development of technical specifications;
• development technical project;
• development and documentation of PS;
• PS testing;
• introduction of PS;
• operation of the substation;
• decommissioning of the PS.

The system architect controls design decisions throughout the software life cycle. Control is carried out in the form of coordination of design documents prepared and sent to the system architect by departments responsible for the implementation of one or another phase of the life cycle of the PS.
Descriptions of the phases of the life cycle of the system architecture, the scope of work on the system architecture carried out in each phase, the performers of these works, as well as the correspondence to the phases of the life cycle of the PS are presented below.

Initial Documentation

The phase of the life cycle of the system architecture "Initial Documentation" does not have a direct correspondence in the phases of the life cycle of software tools. In terms of content, this phase is represented by the functions of its active participants (see Table 1).

Table 1.

Usage

The following phases of the life cycle of software tools correspond to the phase of the life cycle of the system architecture "Use":

• Development of technical specifications for the PS.
• Development of the technical design of the PS.
• PS testing.

(See note, Fig. 8 and the example above. From the example, we see that the development of TOR, TP, testing and implementation of the data warehouse and management reporting system use knowledge of the system architecture of the accounting system in commercial operation, and the system architecture of which is currently in the usage phase, while the data warehouse system architecture is currently in the design phase.)
The functions of its active participants in the "Use" phase are presented in Table. 2.

Table 2.

Design

Here the question may arise: where did the development of the problem statement go? And is it needed at all? The phase of the life cycle of the system architecture "Design" corresponds to the following phases of the life cycle of software tools:

• Preparation of technical specifications for the PS.
• Preparation of the technical design of the PS.

Of course, we need, to put it in official language, the “Analysis of the automation object” phase, including the development of a problem statement, the formulation of business requirements, and, of course, there is such a phase. However, a detailed discussion of these issues is beyond the scope of the article, which is limited to consideration of system architecture.
Let me explain though. The need to change the business and, as a result, the need to restructure the business architecture may be due to:

1. mission or strategy changes;
2. changes in the market situation;
3. regulatory authorities.

After realizing this need, the formulation of business requirements occurs, but all this happens while we are still in the business architecture layer (see Figure 4). Arrows from the entities "Products" and "Documents" directed to the entities "Equipment", "Programs" and "Data" correspond to the problem statement (business requirements). Let's return to our example, from which we see that the development of TOR, TP, testing and implementation of a data warehouse use knowledge about the system architecture of an accounting system that is already in commercial operation, and its system architecture is currently in the use phase. The system architecture of the data warehouse is currently in the design phase (see Figure 8).
The functions of active participants in the "Design" phase are presented in Table. 3 .

Table 3

Migration

The phase of the life cycle of the system architecture "Migration" corresponds to the following phases of the life cycle of software tools:

• Software testing.
• Implementation of software.

The functions of active participants in the "Migration" phase are presented in Table. four .

Table 4

Thus, the system architecture is really affected in the following phases of the software life cycle:

• On phase "Development of technical specifications for the PS" an analysis of the existing system architecture is carried out with the aim of the possibility and expediency of using existing resources to solve newly set business problems. In addition, when preparing the terms of reference, the requirements and restrictions imposed by the existing system architecture are taken into account whenever possible.
• On phase "Development of the technical design of the PS" the actual formation or change of the system architecture is carried out, which is necessary for the implementation of the newly set business tasks. The requirements and constraints imposed by the existing system architecture are taken into account to ensure continuity and minimize upgrade costs.
• On the phases "Testing" and "Implementation" of the developed software, the requirements of the system architecture are used to form the necessary technological environment for testing and operating these PS.

The composition of the knowledge base on system architecture

Since only the lists of what you need to know about system architecture are very large for presentation in a journal article (they amount to dozens of positions), only sections of the relevant knowledge base are described below and an attempt is made to at least outline the content of these sections.
The system architecture knowledge base should consist of at least three sections:

1. Current system architecture.
2. Perspective (planned) system architecture.
3. Migration plans.

The sections "Current system architecture" and "Prospective system architecture" have the same structure and consist of the following subsections:

1. Principles of building system architecture.
2. Basic technical and technological solutions.
3. Requirements and standards.
4. Applied architecture.
5. Technical architecture.
6. Data architecture.

Construction principles

The requirements and restrictions imposed on the system architecture from the side of the business architecture are given. All requirements and restrictions are indicated - both formulated directly in the business architecture, and additional ones formulated by the system architect.
A description of the principles of building a system architecture arising from the above requirements and restrictions is given.

Major Decisions

The main technical and technological solutions that form the basis of the system architecture are described. For example, it could be a decision to use the AS/400 computer as the main hardware platform of the bank's information system, or a decision to use the DB2 DBMS as the main tool for managing the bank's information resources.
Each decision is accompanied by a comment explaining how this decision corresponds to the principles of building a system architecture formulated above.
The main decisions made during the design of the system architecture are drawn up in separate documents, with a brief summary of the background, the essence of the problem and the adopted fundamental solution to the problem, which is mandatory in the future when designing, developing and implementing an information system.

Requirements and standards

All requirements, standards, and constraints that the system architecture complies with are specified. If necessary, individual standards (requirements, restrictions) or references to them can be duplicated in subsequent chapters.
References (code, name, edition, etc.) to external standards are given. If necessary, full or partial texts of external standards are given.
Internal standards (enterprise standards) are described, indicating the code (if assigned), name, edition and approving body.
Additional requirements and restrictions are described that the system architecture and information infrastructure elements that have not received the status of a standard must satisfy.
It is explained which particular principles of building a system architecture or adopted basic technical and technological solutions necessitated the use / consideration of this standard / requirement or restriction.

Application architecture

Applied systems (applications) that ensure the execution of business functions and business processes and their interaction are described. The level of detail of the description should correspond to the program module, understood as a program unit, independently stored as a file or section of the library.

Technical architecture

Network architecture

Contains descriptions of the territorial communication infrastructure and local area networks (LAN).

Platform architecture

Contains a description of operating systems and equipment separately for servers and workstations.

Data architecture

Databases and data stores

Contains a description of databases and otherwise organized information arrays.

Database management systems

Contains a description of the database management systems used.

Migration plan

Contains a migration plan from the current system architecture to the future.
If a phased migration is expected, then intermediate migration plans are also included here.
As mentioned earlier, the migration plan is formalized as a draft. Thus, for each plan, the section includes all documents stipulated by the Bank's project management methodology, both approved and those under development or approval.

Conclusion

We have shown above that the composition and content of knowledge about system architecture is a deeply structured set of highly interconnected information. Moreover, the relationships are not limited to relationships between the entities of the system architecture (see Fig. 3), but are also closely related to the entities of the business architecture. So, in practice, it often becomes necessary to find the answer to the following questions:

• Who in the bank performs this or that business function, how regularly does it, what event triggers the execution of this business function, is it automated or not, or is the execution of this business function?
• What information is input for a particular business function, who is the supplier of this information, in what form does it come?
• What software tools are used to perform a particular business function, what other IT functions do these programs perform, what databases and directories are used, what screens and what reports are generated by the program?
• What information is incoming and outgoing for a particular program, in what form does the incoming information come in and outgoing information is formed?
• How is the information interaction of two programs organized: through the formation / reading of a file, directly through the API, through e-mail, through middleware level systems, what is the structure of information exchange, what is the frequency?
• Which departments use a particular program, who needs to be notified when a program or any regulation changes?
• Is this or that IT function of the program currently being used, by whom, how often?

Of course, there are also many other issues that are somehow related to system and business architecture.
Due to the limited size of the journal article, the analysis of these issues is beyond its scope. We only note that for the structuring and documentation of this knowledge, the capabilities of MS Word or MS Excel are indispensable. Need to use more advanced software systems, but even more important is the use of appropriate techniques or even methodologies. One of these guidelines, which, according to the author's experience, meets the necessary requirements, is the "ARIS methodology" (ARchitecture of Integrated Information System). However, this is a completely different topic, perhaps for another article.

In many ways, the justification for the need to develop a business architecture model is associated with an understanding of the factors that push an enterprise to search for optimization solutions in the field of organizing activities. These factors may include macroeconomic trends, competitive environment, changes in business strategies, etc. Knowing these factors and linking them to the problem-solving capabilities of business architecture modeling is critical to supporting the project with the organization's top management.

The problem of substantiating the need and budgets of a project to create a business architecture model is associated not only with the identification of "driving" factors, but also with the complexity of substantiating the expected effects. In many cases, at the initial stage, it is only possible to declare estimates regarding the indirect improvement of the organization's business, which are difficult to compare with clearly defined financial benefits. Even in the event of the occurrence of events with quantifiable effects, proof of the direct connection of these events with the construction and implementation of a business architecture model in the management process of an organization is not always possible.

It is difficult to give any general approaches to substantiate the expected economic effects due to the emergence of an actual model of business architecture in the organization. In many ways, the final gain is determined by the uniqueness of the situation of each particular organization. This can be successful reengineering of business processes, optimization of information and technological infrastructure, reduction of time and costs for obtaining initial data when launching projects, etc., implemented on the basis of using the model.

In the most general approach, the effects of creating a business architecture model should be positioned with an increase in the overall manageability of the enterprise. With regard to the IT component of the enterprise architecture, world practice indicates the possibility of reducing costs per employee by up to 30%, while the absence of a documented IT architecture entails additional costs of up to 12-18% in a number of operational areas.

If it is necessary to obtain estimates on the "integral" effects from the implementation of the business architecture model, taking into account only financial benefits will not be sufficient to justify the investment. Therefore, it will be necessary to use more complex settlement mechanisms, including “non-financial” effects that are significant for the organization's activities. This type of effects should include the minimization of risks during various changes in the activities of the organization through the use of the capabilities of the business architecture model for simulating various scenario options, including obtaining various qualitative and quantitative assessments. Given the high dynamics of change and complexity modern organization, the issues of minimizing risks associated with restructuring issues are of particular importance.

A feature of investment projects to create a business architecture model is a rather long waiting time for clearly observed effects. To some extent, here we can draw an analogy with the expectations for the return of costs for staff training to improve the overall information or project culture. As part of the rationale for the effectiveness of the architecture of the IT components, the possibilities of using indicators such as Return on Assets (ROA) and Return on Opportunity are currently being considered.

One of the initial standard questions from the heads of the organization, who were not previously familiar with the possibilities and tasks of business process modeling, is to clarify the expected benefits from the results of modeling consulting work.

Often, standard answers to these questions are associated with an emphasis on optimizing the organization's business processes and, accordingly, listing a "base set" of optimization parameters:

♦ duplication of functions;

♦ bottlenecks;

♦ cost centers;

♦ quality of individual operations;

♦ redundant transactions;

♦ possibilities of automation;

♦ the possibility of introducing quality management systems;

♦ the possibility of certification according to ISO 900x.

With all the correctness of these answers, it must be recognized that from the point of view of the sequence of work and the achievement of results, they are not top priorities.

Quite independent, important and the first to be achieved is the result concerning the ordering and documentation of knowledge about the organization. As part of building a model, the following processes inevitably occur:

♦ inventory and extraction from various sources (including individual qualified employees) of information (knowledge) specific from the point of view of the organization's activities;

♦ structuring and systematization of the extracted information, taking into account the main goals and objectives of the organization;

♦ formalization and documentation of information (knowledge) about the organization.

Obviously, regardless of the goals of optimization, the qualitative accumulation, structuring and formalization of information (knowledge) are very important from the point of view of:

♦ technological support for the organization's know-how preservation processes;

♦ reducing dependence on key expert resources to transfer knowledge and competencies to new employees;

♦ increasing the level of manageability of the organization through formalization job requirements and instructions to staff.

As a rule, after the systematization and formalization of knowledge on the current state of the organization's activities, even before describing the processes and choosing a method for their optimization (reengineering), on the basis of specialized modeling tools, organizational and technological reserves are identified that can be used to improve the efficiency of the organization.

At the stage of systematization and formalization, the actual verification of the availability and clarity of the definition is carried out and, if necessary, the clarification of such important data for the organization as:

♦ tasks;

♦ performance indicators;

♦ regulations (instructions, orders, etc.) of business processes.

In a number of cases, it can be said that normative guidelines are as executable and verifiable in terms of the quality of execution as they are formalizable. In this sense, at the stage of systematization and formalization, the “workability” of targets and regulations (standards) is checked.

Therefore, the correct answer to a potential customer to the question “why do we need a model” of the organization’s business architecture is to indicate at least two fundamentally important results (goals):

♦ systematization and documentation (formalization) of information (knowledge) significant for activity, which ensures:

a) a technological basis for the intracorporate preservation and availability of specialized knowledge (know-how) of the organization;

b) increasing the level of manageability of the organization's resources due to the qualitative formalization of the regulations for their use (Fig. 1);

Rice. 1. Problems of knowledge management in the organization in terms of business processes

♦ creation of a methodological and technological basis for the stage-by-stage optimization (reengineering) of the organization, which allows for a technical and economic assessment of modernization measures, identification of organizational, functional and technological reserves to improve the efficiency of the organization (Fig. 2).

Rice. 2. Promising decisions on the use of knowledge about business processes when making management decisions

One of the additional arguments in favor of the need to model the organization's business architecture is global trends in standardizing the requirements for the mandatory presence of organization business process models. Evidence of these trends is the emergence of specialized standards and methodologies for enterprise architecture design.

As the main methodologies and standards, we should mention the "framework" standards for the development of enterprise architecture;

a) ISO 15704 - a standard for a formal description of the enterprise architecture, which was proposed by the working group IFAC / IFIP (International Federation of Automatic Control / International Federation for Information Processing);

b) ISO 15288 is a standard that defines life cycle systems;

c) ISO 12207 is a standard that defines the software life cycle.

There are over 30 additional "supporting" systems and software engineering standards (eg ISO 14258 defining the concepts and rules for enterprise modeling).

The development of a business architecture model is one of the logical next steps for those organizations that have begun to implement the concept of a service-oriented architecture (SOA). At its core, SOA reflects the features of the current modern situation in the mutual penetration of IT and business, when it is extremely difficult to draw a line between the organization's business functions and the information technologies that provide them.

From the point of view of SOA support, the business architecture model is the main tool for synchronizing business needs and information technology capabilities. It is the business architecture model that bears the main burden of providing conditions for a process approach to designing and optimizing the organization's business architecture itself, followed by IT design. According to the SOA concept, the business architecture should be based on a process-oriented enterprise model. The combination of this approach with the concept of service-oriented information technology architecture allows you to better link the process of developing information systems components with the mission, main tasks and functions of organizations. With SOA, organizations have the potential to develop a set of implementations of various business processes that can be reused by the enterprise as ready-made services.

Statements of tasks for business architecture modeling in the context of SOA support are aimed at ensuring the following requirements for IS design:

♦ explicit separation of the business logic of the applied system from the logic of information presentation;

♦ implementation of the business logic of the applied system in the form of a number of program modules (services) that are available from the outside (to users and other modules), most often in the "request-response" mode, through well-defined formal access interfaces.

At the same time, the “service consumer”, which can be an application system or another service, has the ability to call the service through interfaces using the appropriate communication mechanisms, and also clearly positions its place in the business process.

In addition to the “providing” role, namely, support for the implementation of the SOA concept, the business architecture model has an independent significance and the corresponding task definitions. High dynamics of changes in the environment modern business, cannot but have a strong influence on the speed and scope of the development of business modeling. Making long-term forecasts based on the stability of the situation is not possible in almost any area of ​​business. On the contrary, companies have to adapt to an ever-changing environment and develop the skills to quickly adapt to ongoing business changes. In this regard, concepts of organizations are currently being developed that contain special internal mechanisms that allow them to change in accordance with the requirements of the external environment.

The increasing role of business modeling is determined not only by the high dynamics of the organization's "life activity" environment, but also by the circumstances that the resource of opportunities to effectively respond to the "challenges" of the market only by means of IT has been significantly reduced. Increasingly, there are statements that chaos cannot be automated, that chaos automation is even more chaos, that modern IT cannot be considered a panacea for all business problems.

The main reserves for increasing the efficiency and competitiveness of enterprises are currently associated with the optimization of their business architecture, the consistent implementation of the process management model, and ensuring flexibility organizational structure and business processes related to value added management, etc. These opportunities are to a large extent provided by a detailed business architecture of the company, which should contain a description of the processes of change in the organization of the company's activities, as well as provide effective management these processes.

The development of a business architecture model allows the enterprise to be provided with a universal tool that contributes, first of all, to awareness of its own structure and methods of organization. production processes. This model allows you to form a plan to promote the organization in the field of business and emerging technologies.

A well-designed architecture can and should be used by the management of an enterprise in order to study the principles of its functioning, and also makes it possible to develop new, more advanced strategies, organize new ways of planning development, taking into account the need to meet constantly changing external conditions (of course, we are talking about planning in the medium and long term). Such an architecture allows for rapid response and flexibility, which is due to the choice of appropriate forms of organization, special development of processes and the use of certain classes of information systems.

In support of these theses regarding the role and place of business modeling, we can cite the statement of Gartner analyst Jim Sinur (Jim Sinur): modeling lately". In general, it should be noted that for various expert opinion most enterprises will lead projects that in one way or another will affect various aspects of the business process improvement problem, despite the mixed assessments of the business process reengineering practice of the mid-1990s.

In addition to methodological innovations and trends in the development of business organization and IT, the development of the market for business modeling needs is significantly influenced by modern approaches by assessing the level of development (maturity) of the organization. Within the framework of these approaches, the business architecture model is a mandatory component for assessing the organization.

As an example of the methodology used in developed countries for assessing the maturity of public organizations, we can cite the model of the US Financial Control Administration, which defines five levels of maturity.

The use of a business model in the activities of an organization opens up wide opportunities for qualitative and quantitative assessment of its effectiveness, including the use of generally accepted (standardized) methodologies and tools. In fact, the business model allows you to ensure the measurability of the key characteristics of the organization by using appropriate metrics: metrics for assessing the "quality" of the process itself, metrics for assessing direct results (output), metrics for assessing final results.

Process level metrics measure the effectiveness of the process itself. Typical metrics are cycle time, cost per transaction, or process output. Outcome metrics evaluate the ability of processes to produce a product or service as an output according to specifications. Typical metrics for evaluating direct results are the percentage of errors and the number of requests served per unit of time. Outcome evaluation metrics evaluate the process from the end user's (customer's) point of view and the performance of the organization's functions.

It is obvious that the task setting for modeling for a production (commercial) organization may differ significantly from the tasks of the state control (supervisory) body. For this reason, of course, specific adjustment of each of the high-level methods to the modeling area is necessary. The consulting services market responds quite adequately to this need. So, at present there are practically significant models for various sectors of the economy and government agencies, which are implemented on the basis of different methodologies and modeling tools, such as the ARIS methodology and the IDS Sheer AG family of software products based on it, the language UML modeling and Rational Rose object-oriented information systems development tool from IBM, IDEF methodology, DFD and AllFusion Modeling Suite (formerly BPwin and ERwin) from Computer Associates, etc.

Undoubtedly, when setting tasks by an enterprise in its own way, international certification and entering the markets of developed foreign countries, the development of business process models is especially relevant. For this reason, the initiation of these works at the enterprise is not a "tribute" to the new "fashion". Undoubtedly, the creation and subsequent support of models will not only positive influence on the overall image of the organization, but will also help to improve the overall management and production culture of the enterprise. To some extent, the awakening interest of organs state power(OGV) and the business community to business process modeling can be compared with the earlier and widely used process of introducing project management methods and technologies.

It should be noted that the OGVs of the Russian Federation, which are responsible for the formation of scientific and technical policy in various areas, the implementation of administrative reforms, reacted rather “sensitively” to the above global trends and determined target tasks for their consideration in the Russian Federation.

The state of formalization and, on its basis, optimization of the administrative and managerial processes of the OGV is defined in the document "Strategy for the Development and Use of Information and Communication Technologies in the Russian Federation" as the main indicators of planned activities. The table below reflects the current state, prospects and state policy on the introduction of business modeling in the activities of the Russian Federation's OGV (Table 1).

Such an increased attention of the state authorities of the Russian Federation to the problem of introducing formalized mechanisms for describing the activities of state organizations is quite justified. Despite the fact that, due to their specific nature, state organizations have greater (compared to commercial structures) inertia and selectivity in responding to market changes, the current "accumulated mass" of needs has reached a critical point.

Currently, the managerial and executive level of public organizations often faces much more significant problems than the commercial sector. First of all, it is the need to use mandatory in their activities the regulatory and legal framework, which is quite extensive, complex and often allows for ambiguous interpretation. The number of legal and by-laws of a federal and departmental nature is in the hundreds and thousands, the number of types of operational documents and data that are subject to processing in some ministries and departments reaches several hundred. Often the execution of processes is organized in such a way that one employee has a workload that exceeds reasonable standards, and at the same time he bears serious administrative and criminal liability. In these circumstances, the formation of conditions for the effective and legal work of civil servants is an extremely urgent task, and the state is taking appropriate steps to solve it:

♦ electronic administrative regulations are being introduced;

♦ mechanisms for information and consulting support are being formed;

♦ the organizational structure is being optimized.

This is confirmed by the administrative reform, initiatives for the large-scale introduction of electronic administrative regulations, the formation of e-government, etc. In all these projects, the formation and optimization of business models is a preliminary process that determines the basic initial data.

Related to the question "why do we need a model" is the question "who needs" a model. Question of definition potential consumers(users) of the model is the key to specifying and detailing the targets. Business process modeling can cover different aspects of the enterprise: the main and formative infrastructure of the enterprise. Accordingly, the circle of interested persons in the form of managers and performers will be determined by the direction of the organization's activity chosen (chosen) for modeling.

At the level of enterprise divisions, the following can act as interested consumers of the model: the administrative apparatus, information technology divisions, personnel divisions, legal divisions, etc.

At the same time, a fairly large audience of specialists and managers can act as users of the business architecture model of an enterprise within departments:

♦ business analytics in various areas of the subject (target) activity of the organization;

♦ developers of information and technological systems;

♦ system architects, who are responsible for creating the architecture of individual information systems;

♦ business analysts who lead the process of designing the organizational structure;

♦ managers who are interested in a systematic, structured analysis of the problems and opportunities that open up for the business, etc.

In principle, the initiative to conduct business process modeling can come from any department of the enterprise. It depends on the level of awareness of the heads of the department about the possibilities and usefulness of the models, the priority of the current tasks of optimizing activities, the completeness of modeling individual business processes of the enterprise.

In reality, in most cases, the initiative to develop business process models comes from the information technology departments of the organization. This is due to the need to automate certain areas of activity of enterprises against the backdrop of a general high activity in the implementation of IT in all areas of business and an ever-increasing share of enterprise budgets for the IT component.

With all the positiveness of the very fact of the activity of IT departments (as well as any other functional department) in the implementation of business modeling, it is correct to retain the initiative and control of this process for the top management of the organization. This will avoid a “narrow departmental” purely IT (or other) approach to modeling, aimed at solving a particular task after the fact - automating a separate process, and providing a solution to a corporate task - creating a tool for evaluating and optimizing business processes in the framework of achieving performance targets the entire organization.

Support and general management By introducing a business architecture model in an enterprise, they do not exclude or diminish the role of functional units in this work. The “wider” and “deeper” the model becomes, the “closer” it is to the user, the greater the number of stakeholders appears in its development and support.

As a result of modeling the activity of an enterprise within the framework of the process approach, “inevitably” there is a gradual (as the model is detailed) display of the role, place, effect introduced by all organizational and staff structures of the enterprise. For this reason, ensuring that the significance of the unit is adequately reflected in general model enterprises, as well as the subsequent search for an increase in the "contribution" to the target results of the enterprise, or a "reduction" in the costs of the unit, will provoke the heads of these units to actively participate in the construction of the business architecture model.

To a certain extent, the question “who needs a business model” can be compared with the question “who needs electronic document management". From some point on, the workflow is used by everyone, and each department takes part in setting tasks for the creation of specialized electronic regulations for supporting "its" part of the workflow and their "zealous" protection, and in relation to business modeling, each department begins to build "its own part" big building business architecture model.

Setting goals, implementing, implementing and scaling the results of business process modeling projects are significant milestones in changing the overall corporate culture of an enterprise. Employees gradually acquire knowledge, skills and experience of the process approach in carrying out their activities, clearly position themselves in the complex structure of the organization, master modern methods of evaluating the results of their work and finding ways to optimize it.

The creation of a business architecture model is a kind of collective information, technological and organizational environment for displaying and implementing the process approach of an enterprise. This environment, which, on the one hand, allows each interested person to "express" qualitative and quantitative proposals for improving the activities of the enterprise, and on the other hand, all participants to objectively evaluate the "positive" and "negative" aspects of the proposal.

In addition to increasing the "awareness" of the participants in the business processes of their mission in the activities of the enterprise, the "new" corporate culture ensures the obligatory documentation and preservation of the history of all changes related to the target activity of the enterprise. Such a pedantic and qualitatively formalized attitude to the years of accumulated knowledge in the organization is the basis for their effective use.

Expansion of interested participants in the construction of the model and the formation of a new corporate management culture to a greater extent is a condition and / or consequence of the modeling project. Practical steps for the implementation of the project are formed on the basis of understanding the content of the target tasks for modeling.

Modeling tasks follow from the goals formulated by the organization to improve its activities. As noted above, the target tasks for modeling business processes are distributed in two main areas:

1) systematization and formalization - the construction of descriptive models;

2) construction of analytical and optimization models.

Within the selected areas, an additional division of areas can be carried out, taking into account the presence of two main types of research, namely the business processes themselves and the resources involved in business processes. Based on this, such subtasks as:

1) qualitative and quantitative assessment (optimization) of implemented business processes;

2) qualitative and quantitative assessment (optimization) of the use of the organization's resources within the framework of ongoing business processes.

In relation to business processes, modeling tasks can be divided into types of processes: core, enabling, external interaction and development (see Chapter 2). With regard to "non-process" research objects, modeling tasks can be specified for the processes of formalizing the goals of the enterprise, organizational structure, technological structure, information structure, architecture of business functions, regulatory framework, key indicators activities, etc.

Additional systematization of modeling tasks can be linked to the implemented methods for constructing and using an enterprise business architecture model. Examples of such tasks can be: functional cost analysis, simulation modeling, systematization and formalization.

In practice, the following topical questions are grouped according to the selected areas of setting the tasks of modeling business processes, to which the organization's management would like to receive reasoned answers:

♦ What are the integral cost and time costs required to implement a particular business process (subprocess)?

♦ What composition of organizational, technological and informational resources, as well as regulations, is necessary to perform a particular business process?

♦ What is the dynamics of the use of organizational, technological and information resources necessary to complete a particular business process?

♦ What resources (organizational, technological and informational) or regulations are the main limiting factors for expanding the organization's ability to increase the qualitative and quantitative characteristics of the business tasks being solved?

♦ What operations (job functions) are assigned to a specific official unit in the framework of the target activity of the organization?

♦ What list of operations ( routing) should be performed by the official unit upon the occurrence of a specific standard or non-standard situation related to the implementation of the target activity of the organization?

♦ What qualitative and quantitative improvements should be expected after the modernization (introduction of new) information systems, legal acts, organizational units, production technologies, etc.

The above directions of task setting form a group of conditionally called tasks for the technological design of the model (“architectural” tasks). At the same time, objectively, there is an independent group of tasks associated with the logic of organizing the execution of a modeling project:

♦ definition of stages;

♦ definition of roles in the project;

♦ formation and management in the project team, etc.

This list of tasks, as well as the implementation of "architectural" tasks, will be discussed in more detail in other sections of the book.

It should be noted that the qualitative formulation of problem statements for modeling business processes in relation to the profile, current state and priority of the organization's problems is a key condition for the success of the project. It should be clearly understood that not only all interested, but also competent persons should participate in setting goals. When solving such issues, it is necessary to exclude possible situations of replacing business competence (at the level of legal, technological, managerial) with IT competence and vice versa.

A quite natural and justified question after finding out who needs a business architecture model and why is to clarify the parameters and the fundamental possibility of paying back this kind of consulting project.

Such a statement of the question, as well as the formation of an answer to it, is not much different from the situation when it turns out why the concept of an information system is needed when initiating large-scale informatization projects of an organization.

Efforts to build business architecture, which is presented in the form of business models, quickly pay for themselves and have a large number of additional benefits. The benefits of building a business architecture model of models lie in two planes: additional features business and reduce costs. It is estimated that the creation of business models and the associated cost optimization, even without radical business changes, can provide up to 10% savings. And when modeling alternative business process options, organizations can save up to 20%.

I started working with one company on the topic of enterprise architecture (Enterprise Architecture) and decided to correct my understanding of EA, to make it clearer and simpler. The 1987 publication of John A. Zachman's "A Framework for Information Systems Architecture" is generally credited as the birth date of EA, although the term itself has appeared in earlier writings. Despite the fact that the architecture of the enterprise is a rather young thing, it has already managed to spoil its reputation. Like any other architecture, enterprise architecture is not well defined (see, for example, 10 Definitions of Enterprise Architecture), but it does have a large number of failed projects (see Gartner Identifies Ten Enterprise Architecture Pitfalls or 8 Reasons Enterprise Architecture Programs Fail). Usually, after the completion of an enterprise architecture project, you can hear the following phrase: We have drawn all the necessary pictures, but we have no idea how to get at least some benefit from it.". Therefore, let's talk everything from the very beginning.

And we will start from afar. There are two points of view on the usefulness of information technology. According to the first point of view Information Technology allow you to increase labor productivity, i.e. people will work more efficiently if their activities are automated. There is also an opposite point of view, expressed, for example, in such books as “The Shine and Poverty of Information Technology. Why IT is not a competitive advantage" by Nicholas J. Carr or "What Business Wants from IT" by Terry White. Surprisingly, both of these points of view are correct. But let's narrow the circle of our reasoning and let's talk not about information technology in general, but only about business applications, i.e. systems that automate the business processes of the organization. At first, the development and implementation of such systems brings a tangible effect. When different employees begin to reflect similar operations in a single database accessible via the network from different workplaces, interact with each other through such solutions, and specialize in certain functions, their productivity increases. This is much better than calling each other on the phone or exchanging emotionally charged messages on e-mail. Therefore, various other processes begin to be automated, maybe not so frequent and not so necessary. The efficiency of such automation is not so high. The low-hanging apples have already been plucked, and we have to invent more sophisticated ways to achieve the result. At some point, the costs of using business applications become greater than the benefits derived from their use, but it is no longer possible to stop the overclocked locomotive. The reason for this threshold is the organic complexity of information systems (IT Complexity). In fact, at some point we just get confused about what we are doing, and information systems help us get even more confused. Architecture (enterprise) is just a way to control the complexity inherent in systems, to keep in mind a more or less adequate picture, while still allowing this complexity to be managed.

The next problem is that such a picture cannot be prepared for the future. (At this point, the architects will tell you a lot of buzzwords about different points of view, views, stakeholders and concerns). Therefore, to answer the question “Why do we do enterprise architecture?” needed from the very beginning. Let me highlight the three most common responses:

1. We have a strategy that answers the question of what we want, but we do not know how to do it.
2. We don't have a strategy, but we have a flood of change requests that we can't handle.
3. Information about our activities is contradictory and we do not have time to figure out in each case why this is happening.

(If you think there are other, more frequent options, please note it in the comments).

In the first case, we need to make Strategies –> Plan. It is mainly about business strategy. It usually looks like a set of some deltas between what you have and what you want, expressed in fairly simple terms: market share in terms of revenue, customer base, etc. In general, you know, a strategy is a document about tomorrow's hedgehogs, which will become today's mice. I will write about what should be done in this case in a separate message, but for now a few words about how to organize such a process. In my opinion, the organizational form of enterprise architecture development is a project lasting 8-16 weeks. Methodology - TOGAF ADM, etc. Resources should be attracted, mainly internal. The results of the project are: a roadmap, a list of organizational and process changes, risks, proposals for monitoring and managing movement in a given direction. In general, everything that is done in traditional projects during the planning phase is called a beautiful word master plan. About the team of such a project, a set of activities and artifacts - the same in one of the following messages.

Option number 2: Change management. Instead of a strategy, there is a set of different goals for different business customers. Some need to reduce costs, others need to bring new products and services to market, and still others need to improve customer satisfaction (see About Enterprise Architecture in a nutshell). All customers are respected people and everyone needs help. But the complexity has already grown and we do not understand how to help everyone at the same time. simple and Wrong way put everyone in line with beautiful name, for example, "A single list of priorities", and the method of distributing tasks among information systems - "Free cash desk!" - whoever can do it faster and cheaper, we will entrust him. The right decision- multifactorial classification of queries, in other words - taxonomy. Methodology - in the style of Zachman. Organization - the creation of a functional unit. In a previous note Are business analysts friends, neighbors, or distant relatives? I wrote that with the advent and adoption of the third version of BABOK, business analysts will be able to do this work. But so far they can't. Currently, business analysts are able to answer the question “What needs to be done?”, And solution architects can answer the question “How to do it?”. It also requires an answer to the question “Why?”, how this change is related to existing products and processes, other changes, applications.

And finally, the situation when complexity has already won and the leaders of the organization have an awareness of this. about those same Pictures, which are not there when they are needed in order to quickly sort out a controversial problem and which lie completely useless cargo the rest of the time. This situation is talking about an architectural repository. There may be pictures describing the architecture somewhere, but if they cannot be obtained within a minute or two, then the manager, and any manager, will not do it himself, but will ask someone else to get the picture (“Call the architect here !"). If a person does not work with the application at least once every 1-2 weeks, then he will not do it at all. If the developer of the information system does not have simple, understandable and ready-to-use APIs for obtaining types of clients, a list of branches, a functional organizational structure, etc., then he will definitely add another plate in his information system, in which he will force users to enter data from these directories again. I am not aware of any EA Tool that is equally suitable for demonstrating beautiful pictures to top managers and at the same time possessing innate interoperability for integration into real business applications. I hope that such, sooner or later, will appear. And then option number three will turn into a simple project for the implementation of an information system and its subsequent use and development.

To be continued (enterprise architecture story)!