IT solutions architecture. Part 1. Enterprise architecture

I. Introduction

The architecture distributes masses and volumes.
Inspiration turns an inert stone into drama.
Le Corbusier.

Recently I encountered the following situation, one large IT company selected an architect for itself, with the goal of refining the computer platform of “own execution”. Such work, of course, required the involvement of highly qualified specialists. And how to do it cheaply and angrily, so that the drafted Varyag was “both a reader and a reaper and a igrets duda”? We decided without any frills software developer, to name the architect, and get in addition to the coder, also a professional who is able to deal with other people's decisions, to design them at their discretion, to make independent decisions, etc ...

When they began to find out, what about the organization in general, the situation with architecture, the following trends emerged. There are a number of highly skilled developers positioned as architects. In addition to directly creating code, they perform a fairly low-level design of various technological systems and set the vector and horizon of their development. The solutions are presented by them mainly in the form of text descriptions, diluted with a small number of schemes, mainly derived from component diagrams. Each of the architects is a unique and exclusive carrier of knowledge, and in fact is a bottleneck in the process of producing software products. Indeed, in practice, without his constant clarifying consultations, it is practically impossible to use the result of evon activities. A complete, logically built, structured picture of a complex solution is only in his head.

And there seems to be a lot of documentation, but it is scattered across project repositories, wiki systems, etc. It is extremely difficult to find a logically holistic description of the solution and recommendations for its use, and it’s not realistic to trace the branching private technical solutions: from the user's needs to the final delivery to the customer, this is despite the fact that a customer usually prepares a version for the base of the standard product, modified in accordance with its specific needs. But sometimes it is so necessary to track, for example, with whom the component is connected, which is supposed to be used when designing a new module. With whom he is, so to speak, divided by six handshakes, and what a disastrous influence all these unreported connections can have on the stability of his behavior.

A similar situation prevails in many large IT companies. It seems there are architects and architectural councils and other attributes of "high" architecture, and there is no order in this kingdom. According to the above symptoms, it turns out that the enterprise is rampant - “acute architectural failure”.
')
It became interesting to me to deal with all aspects of architecture, collecting in this article structured and consistently information about what is IT architecture, who are IT architects, and "what they eat with."

Ii. The definition of "architecture"

And what can you think about architecture?
She is like the sun: big, brilliant and she is near.
Roger Zelazny. (Master of Dreams)

Let's go over the definitions first.

The system architecture is a fundamental organization of the system, embodied in its elements, their relationships with each other and with the environment, as well as the principles that guide its design and evolution.

A very mean formulation and deploying it, illustrating the full meaning, is difficult. Therefore, we will try to narrow the problematic and push off something smaller, for example, an integral part of this system:

Software architecture (English software architecture) - a set of important decisions about the organization of a software system. The architecture includes:

• the choice of structural elements and their interfaces with which the system is composed, as well as their behavior in the framework of cooperation of structural elements;
• combining selected elements of structure and behavior into ever larger systems;
• architectural style that guides the entire organization - all elements, their interfaces, their cooperation and their connection (1)

Quite a concise definition, adding which you can come closer to understanding what is usually associated with a phenomenon - IT Architecture.

Firstly, it is a specially selected, set of structural elements, organized in specific ways to interact with each other, folding into a single software and hardware complex. I would also add: built in order to achieve certain business goals.

Secondly, the place of the “aggregate of these elements”, as parts, in larger systems, including behavior, interaction points, etc. That is, the possibility of abstracting the architecture under consideration to a higher level, and, accordingly, the specification of the architecture into sets of lower-level composite architectures.

Thirdly, the use by all participants of a single approach to the organization of decisions in the process of producing information systems.

If we are talking about a unified approach, let's clarify this question:

Architectural approach (English architectural framework) - agreements, principles and practices for describing the architecture established for a specific scope and / or a particular community of stakeholders (2).

Indeed, in the course of designing, developing, developing and modernizing a software system, “a set of decisions about its organization” (Architecture) requires constant discussion with all interested parties of the project, including business. Again, it’s important that everyone at the same time lined up one and the same picture, including the current actual state of the architecture.



So, having warmed up on the general positions and setting the direction for the study of the concept of Architecture, we will continue to delve into the essence of this phenomenon.

1. Sections IT Architects

Since the concept of IT architecture encompasses a whole bunch of aspects of software production, starting from defining automation goals and ending with the utilization of software that was outdated at some point, it is common to divide it into several parts:

1) Information Architecture (Enterprise Information Architecture, abbr. EIA), a set of methods and tools that describe the enterprise information model. Includes:

• databases and data storage;
• information flows (both within the organization and communication with the outside world).

2) The architecture of application solutions (Enterprise Solution Architecture abbr. ESA) - represents the architecture of applications, which includes a set of software products and interfaces between them. It is divided into two areas:

• field of application development;
• application portfolio.

3) Technical Architecture (Enterprise Technical Architecture Abt. ETA) - a set of software and hardware, methods and standards that ensure the effective functioning of applications. Describes a complete view of enterprise infrastructure, including:

• information about the infrastructure of the enterprise;
• system software (DBMS, integration systems);
• standards for software and hardware;
• security tools (hardware and software);
• infrastructure management systems.

Plus, the architecture of the subject of automation is added:

4) Enterprise Enterprise Architecture (EBA) - targeted construction of the organizational structure of the enterprise, linked to its mission, strategy, business goals. In the course of building a business architecture, the necessary business processes, information and material flows, as well as the organizational structure are determined.

Accordingly, to work with each of the above sections, it requires its own group of stakeholders with different qualifications and preferences, and possibly goals. Therefore, the numerous stages of the project lead to artifacts that describe aspects of architecture in different styles and genres. In addition, they are most often created by disparate tools, using a variety of notations, techniques, representations, etc.

Therefore, each section of the architecture corresponds to at least one group of stakeholders, which has its own views on the ideas and methods of describing the architecture. Let's find a definition for this reality.

Architectural description group (eng. Architectural view) - representation of the system as a whole in terms of a related set of interests. Each group of descriptions refers to one or more stakeholders. The term “description group” is used to express the system architecture with a certain description method (2).

Having understood briefly the concept, directions and sections of the architecture, as well as identifying discrepancies in the architecture views by different groups of stakeholders, we proceed to the analysis of these concepts (artifacts) themselves, reflecting the architecture.

2. Representations by IT Architects

I often observe situations when very interesting and promising plans are beaten in a swamp of incomprehension, only because of the isolation of the idea generator from the general level of consciousness of the trade community. In other words, he is trying to convey a concept that, in his thoughts, is folded into a coherent and coherent idea, presenting to others only its “bits”: “well, the rest is understandable.” And this “rest” is really not always clear for the electorate, and he votes against the crazy and incomprehensible from his point of view ideas, his indifference and ignorance. The author of the idea often just does not bother, why did things go wrong, and why no one was imbued with a miracle decision.

In all likelihood, some kind of liner was needed. But it may very well be that at first it was necessary to open up a whole new world to people, and only then, in its light, to convey this idea of ​​mine. It is akin to explaining Einstein's theory of relativity on it as a foreigner who does not speak your native language. Especially if you are somehow not very her ...

Obviously, for the effective presentation of architectural solutions to all interested parties, a certain method is required that allows them to be available, but in sufficient detail, to convey the essence to the widest possible circle of people. In this way, a standard adopted in an organization can be used - an architectural description and appropriate methods for their maintenance. For a more accurate understanding of this phenomenon, let us put in motion and their definition:

Architectural Description (English architectural description) - a work product used to express architecture (2).

Architectural Description Method (eng. Architectural viewpoint) - specification of agreements for the construction and use of a group of descriptions. A template or pattern for which specific groups of descriptions are developed by setting assignments and audiences for a group of descriptions, as well as techniques for creating and analyzing them. The description method establishes the conventions by which a description group is created, displayed, and analyzed. Thus, the description method determines the languages ​​(including notations, descriptions or types of products) used to define the description group, as well as all related modeling techniques or analysis techniques applied to the data of the description group. These languages ​​and techniques are used to obtain results related to addressed interests (2).

Thus, the selected architectural groups, using common architectural methods of description, significantly increase the efficiency of their work, achieving the most consistent and holistic perception of the problems discussed.

But is it possible to drive specialists of different directions with different qualifications, and perhaps a way of thinking, into a single framework, and is it really so necessary?

For example, a diagram describing the formation of goals and indicators based on the identification of glass holders, calls and their problems, see Figure 1, is very different in nature from diagrams with the network layout, as well as diagrams in UML and other notation.


Figure 1. Goal and Indicator Development Model

In practice, the use of heterogeneous artifacts is a big problem, since the possibility of end-to-end tracing of architectural solutions from goals and strategies to needs, then to the description of business processes and system functions, from them to the data structure and behavioral models, from models to screen layouts, etc, is lost. d. on the chain. After all, all these artifacts are created by specialists of different architectural groups that were formed on their own, selecting the best tools and techniques for years.

Fixing all these various descriptions and representations, a reasonable question arises: How can they be united in a comprehensive context?

For example, for the development of large information systems at the end of the last century, Zakman’s model (3) was used as a scheme for organizing architectural artifacts.
Zakman's model is based on the discipline of classical architecture and is designed to provide a general interpretation of architectural aspects and provide a set of perspectives, or frameworks, for describing complex corporate systems.

The model itself is represented in the form of a matrix — a table with five rows and six columns, see fig. 2. Each cell of the table - presents a set of artifacts that reveal one of the essential aspects of the architecture.


Figure 2. Representation of the Zackman model

It is noteworthy that the main idea of ​​the matrix, in addition to forcing to fill all the cells, without missing important characteristics of the system, consists in determining the sequence of filling. After all, only filling in some cells opens up the possibility of filling in the following on the basis of them, until the puzzles are folded into a whole picture. Thus, the architectural descriptions that are different in their conception fall into different cells of the matrix and they also link them into a single architectural canvas.

It is worth noting that in Figure 6, the sixth row no longer corresponds to the level of the description of the architecture, but to the level of the operating system or enterprise as a whole.

Zakman's model was eventually refined and served as the progenitor for many architectural frameworks and specifications.

One such actual specification is, for example, the ArchiMate graphical language containing a set of concepts for describing an enterprise architecture and a framework representing the logical structure for classifying this information. The latest version of the standard 3.0 was released in June 2016.

In ArchiMate, when creating models, the basic concepts of “element” and “relation” are used, see fig.3. On the basis of elements and relationships, models of the enterprise or its individual parts are built.


Figure 3. ArchiMate 3.0 Basic Concepts

The beauty of the approach is that the elements can be projections of the most diverse real entities and phenomena encountered in life. For example, motivational elements (stakeholders, motivation driver, goal, result, value, etc.), elements of organization and behavior (actors, roles, processes, functions, events, interaction, etc.), business elements (information asset , agreement, product / service, application component, application interface, automated function, etc., technological elements (node ​​/ resource, device, communication network, technological process, etc.). Each type of element is represented on the diagrams with its unique designation. Thus, in the same information space, so different reflections of entities, phenomena, events, actions, etc. that form the enterprise architecture can be combined.

The models themselves are located in one of the framework cells at the intersection of the Layer (presentation level) and Aspect. Schematically, the framework structure is shown in fig. four.


Figure 4. Layers of the ArchiMate 3.0 framework

As Layers, constructive sub-systems of an enterprise are considered, which form a certain self-contained representation (slice) of the organization. And Aspects, in turn, attribute elements to one of three main types:

1) The active structure element positions it as an entity that is capable of performing certain actions.

2) The passive structure element positions it as some object on which actions are performed.

3) A behavior element is defined as a unit of action performed by one or more active structural elements.

You can read more about the specification in the ArchiMate (4) review.

Such tools allow to combine heterogeneous aspects of architecture into a single information space using unified architectural description and methods, providing a trace between diagrams and elements.

Immersed in all this "carousel" of complexity and diversity, there is one important question: Is it always necessary to carry out such a complex and resource-intensive process of describing architecture? In fact, there are several approaches to its construction, for example:

1) The standard approach is to develop or select at the initial stage a general scheme and rules for describing the architecture. On the basis of the standards developed, the basic (current) architecture is described, and starting from it, the target (new) is being designed. Having determined the difference, they form arrangements for the transition from the basic architecture to the target one. Only after this begins the design, acquisition and development of system components. As drawbacks, one can single out: substantial initial investments, both financial and temporary. Also, this approach can lead to what is called "paralysis due to analysis."

2) The status quo approach. Development is considered as a reaction to those or other arising difficulties or impacts.

3) Segment approach, based on the model of the development of segments of the architecture within a general structured scheme. He focuses on the main areas of business. Allows you to reduce the possible risks, to ensure a reduction in initial costs and to achieve quick returns from the project There may be problems at the segment integration stage.

3. Section Summary

So let's make a brief squeeze of the material we reviewed:

1. The enterprise architecture links the business needs of the enterprise, information technologies, strategic business planning processes, applied information systems and their maintenance processes.
2. In the process of developing and maintaining an enterprise architecture, different groups of stakeholders are involved, having different requirements for its ideas (architectural approach);
3. For convenience, the architecture can be divided into sections, corresponding to different architectural zones and approaches;
4. For different architectural groups and approaches, there are different groups of architecture description (visualization).
5. For the convenience of organizing work with heterogeneous artifacts, they use architectural description methods, which are special frameworks and specifications, and allow working with all artifacts in a single visual space. Using such constructions helps, on the one hand, to logically split all architecture views into separate sections to simplify their formation and perception, and on the other, to ensure that the integrated architecture can be viewed from isolated points of view or appropriate levels of abstraction.
6. Depending on the needs and capabilities of the enterprise, you can choose one of several architectural approaches that differ in the volume and composition of work performed, which in turn determines the level of costs and the quality of design.

The next part of the article can be found by clicking on the link.