An interpreter is required The problem is further complicated by the fact that each of the four (PAEI) - types puts a different meaning into the words "to be", "want" and "required" based on the peculiarity of their own picture of the world. An entrepreneur, as a rule, makes decisions, perceiving

Required: Knowledge of Economics In order to prepare oneself for a career in public relations, one must obtain a solid education in economics. Being hired as a professional, he will have to deal with financial aspects

Step 6: Applying the Architecture Any organization wishing to use a process architecture must develop the necessary discipline. This means that all relevant designs must consider the architecture and identify where they deviate from the agreed

Sample Architecture General Targets: Achieve a 200% increase in sales revenue over the next three years; ensure profit growth of 150% over the next three years. General principles: our corporate values: best value for money

Why do we need the concept of "approval"? Why do we use the term "affirmation"? If it says "some statement is missing", then the logical tree does not mention some important element(cause, effect, intermediate goal or task, etc.). Using

What is required for this? If there is a desire, it is not at all difficult to create the benefits listed. Take, for example, the sharing of skills and experience within a unit. This requires a well-functioning unit with the capacity to

Chapter 1 Why You Need a Business Architecture Model: Standard Business Process Modeling Problem Statements Much of the rationale for developing a business architecture model is based on understanding the factors that push an enterprise to seek optimization.

Some Experience Required These entrepreneurial plans brought back memories of our first experience with VCs.

It takes a genius. Average ability is no longer enough. We are developing. What is average today will be below average tomorrow. We are not on a fairground carousel, where it is enough just to hold on to a copper ring so as not to fall. We are constantly moving forward. going on

Modern information technologies (IT) are becoming an integral part of any enterprise. Today, for many enterprises, they are not just a way to automate routine operations (technological substrate), but an effective tool in the competition. Modern IT systems are designed to quickly adapt to new business needs (its goals and objectives) and fully comply with the enterprise architecture (EnterpriseArchitectureEA).

There is a lot of talk today about the effectiveness of information technology in the enterprise, but at the same time, many of the analysts of large companies (for example, Clif Finkelstein) believe that enterprises have simply moved from a state of manual chaos to a state of automated chaos. Accordingly, any large enterprises require structuring and documenting both business processes and the information technologies that support them.

Why do we need enterprise architecture? The question of the need for enterprise architecture and information technology architecture arises quite often. The concept of "architecture" originally referred to the field of urban planning. In order to build a house or design a city, it is necessary to have a specific plan, a drawing that allows you to evaluate the entire structure as a whole and calculate the costs of its implementation. The plan of the building (city) must clearly comply with the functional requirements of the customer for structures of this class.

The introduction of information technology in an enterprise, like construction, is complex laborious process, but at the same time, many large companies spend huge cash on the introduction of various information systems without the slightest idea of ​​​​the general concept of enterprise development. Can you imagine Big City in which the construction of individual buildings is carried out chaotically, without architectural plans and a long-term development concept?

Building an integrated information system modern enterprise can be compared in complexity to the design of a city, where information systems correspond to buildings. Information systems, like individual buildings, require maintenance and proper operation, repair and modernization. But the life cycle of an information system is significantly shorter life cycle building.

When building a complex information system of an enterprise (usually including many information systems or subsystems of different functionality), we need to have documented information about the current state and a concept for the development of our information technologies in the future.

Under enterprise architecture (EA - Enterprise Architecture), usually understood as a complete description (model) of the structure of an enterprise as a system, including a description of the key elements of this system, the links between them.

The enterprise architecture defines the overall structure and function of systems (business and IT) throughout the organization as a whole (including partners and other organizations that form the so-called "real-time enterprise") and provides a common framework (framework), standards and guidelines for architecture level individual projects. The shared vision provided by the enterprise architecture enables a unified designing systems that are adequate in terms of meeting the needs of the organization, and capable of interoperability and integration where needed.

Enterprise architecture is based on the "Architectural View" of systems, defined in ANSI/IEEE 1471 as "the fundamental organization of a system, consisting of a set of components, their interconnections, and external environment, and the principles that guide their creation and development.

The enterprise architecture describes the activities of the company from two main positions:

· Business architecture describes an enterprise in logical terms, such as interacting business processes and business rules, required information, structure, and information flows.

· Information Technology Architecture describes an enterprise in terms of technical concepts such as hardware, software, security, and safety.

Documenting and optimizing the architecture of information technology provides us with a reduction in the complexity of information systems and simplifies their integration. Optimization of the company's business processes and optimization of the functionality of information systems used to automate business processes increases the flow of investment in information technology. Enterprise architecture primarily combines information technology architecture and business architecture into a single whole, providing a comprehensive view of both existing areas (Figure 1.1.).

The enterprise architecture is an important critical element that connects information technology, business needs of the enterprise and integrates processes strategic business– planning, applied information systems and their maintenance processes.

At the same time, the architecture of the enterprise is inextricably linked with the main work processes:

strategy and planning at the enterprise level;

management of corporate projects.

Figure 1.1. Interconnection of business and IT

The development of a strategy for a modern enterprise (Strategy and Planning) and corporate project management (Enterprise program management) include a direction directly related to information technology. Modern tendencies consider IT projects and strategic initiatives as a specific company asset that can be managed similarly to financial assets.

Information Technology Portfolio Management(BusinessandITportfoliomanagement) is an investment management process in the field of IT project management. A portfolio is understood as a set of projects executed on a common pool of resources (finance, people, equipment, materials, energy), while the pool of resources and the results of all portfolio projects are within the competence of one responsibility center.

Analysts at METAGroup believed that this was an area of ​​intersection of enterprise architecture, enterprise strategy and corporate project management (Figure 1.2.). At the same time, strategy and planning provide the basis for the development of an enterprise IT strategy, in accordance with which projects for the implementation (modernization) of information systems appear. Project management - can be considered, first of all, as a mechanism that ensures the transition from the current state to the planned one, or, in other words, the transition from the current enterprise architecture to the target architecture.

Figure 1.2. IT portfolio management.

Presentation of information technologies in the form of assets allows an enterprise to correctly evaluate and prioritize investments and manage IT projects (assets) taking into account an acceptable level of risk, and thus plan investments in this area. It is believed that IT portfolio management should pursue three main goals:

maximizing the value of the portfolio;

· synchronization of IT portfolio with business requirements;

· finding the optimal balance between risk and potential return on the IT portfolio.

The enterprise architecture is one of the elements of IT portfolio management and provides the necessary information about business processes and the technologies needed to automate them. The enterprise architecture not only provides the basis for developing a portfolio of assets, but also provides the entire lifecycle of many IT assets.

The enterprise architecture allows you to see the entire enterprise. Create a chain showing the impact of individual elements of the enterprise development strategy on its business processes, and their dependence on information systems and technological elements.

Allocate various levels abstractions of the enterprise architecture, but each of them has a single set of models, principles, guidelines, and which are used to create and develop systems in the context of the activities of the entire enterprise as a whole. The following three levels of abstraction can be distinguished (Figure 1.3.): the level of enterprise architecture; the level of architecture of individual solutions; application layer (design and development of solutions).

Enterprise Architecture Layer- describes the high-level elements of the architecture, focused on creating a common development concept across the entire enterprise, as a whole. At this level, the main goals and objectives of the enterprise, its development strategy are considered, on the basis of which an IT strategy and a high-level architecture are developed. Here the general structure of information systems within the entire organization as a whole is determined, and their main functions are highlighted.

The level of enterprise architecture is, first of all, the general scheme of functioning of the entire enterprise as a whole, which makes it possible to design information systems that meet the needs of the entire enterprise and their effective integration. The construction of such a scheme allows not only to show which business processes and information systems ensure the achievement of the main goals of the enterprise, but also to avoid their duplication, to increase the efficiency of collaboration.

Decision level– defines the structure and functions within individual projects. At this level, detailed information about applications, business processes and their relationships is formed. It defines the structure of information systems, their interfaces and functions. Plans and schemes for their development are determined, a service level agreement (SLA) is being developed.

The project level architecture describes exactly how new information systems will fit into the context of the entire enterprise, with whom they will interact and what technologies they will use.

Figure 1.3. Context and abstraction levels of enterprise architecture.

Application layer, which includes the design of a separate solution and its architecture, plans for the implementation of projects. At this level, work is already directly with information systems. Defines the structure and functions of individual applications that are developed to provide specific functionality. This is where the implementation of the standards and guidelines defined at the higher levels takes place.

An information system, at this level, is considered as a complex complex object that dynamically changes in time. The concrete implementation of the system includes the application instances and their physical location, the actual data flows, and the implementation of the control processes.

When making changes to the enterprise architecture, you can use various methods of separation into layers of abstraction. This is due to the fact that each level of abstraction uses its own models that describe certain subject areas. For example, when introducing information technology in an enterprise, it is customary to distinguish the following levels of abstraction:

· Context level(why?) focuses primarily on leadership and justifies the need for projects.

· Conceptual level(what?) defines General requirements to the project and possible options its implementation.

· logic level(how?) describes how the project will be implemented.

· Physical layer defines solutions, standards and technologies to implement the project.

The number of abstraction levels and their type may vary depending on the tasks. The main advantage of abstraction layers is to allow the enterprise to be decomposed into separate elements for subsequent detailed consideration. The concept of dividing the architecture of an enterprise into different levels of abstraction allows managers to clearly see the impact of planned changes on the entire enterprise as a whole.

Thus, we can say that “architecture is an investment in standards of processes, technologies and interfaces in order to improve the capabilities of organizations and reduce the cost of developing and maintaining information systems, and corporate IT architecture is the vision, principles and standards that organizations are guided by when developing and implementation of technologies.

The Enterprise Architecture is a management tool that provides a decision-making process for information technology investments that blur the line between the business and the IT department.

Traditionally, it is believed that new information technology initiatives should manifest themselves in the form of business requirements, and new information systems should meet precisely these requirements. But the business must, at the same time, receive and take into account the “signals” from the IT department, which, accordingly, must show the new opportunities that the enterprise has when introducing new IS. Thus, the architecture of the enterprise can be considered as a new stage in the development of organizational principles for building the activities of the enterprise, ensuring its efficient functioning(Figure 1.4.).

Figure 1.4. The evolution of organizational principles.

Any enterprise requires the systematic development of its structure, business processes, information systems and their integration with each other. The architecture of the enterprise is actually a plan for the development of the enterprise ( target architecture) and a documented scheme of what is happening in the company at the current time ( current architecture).

Current architecture- describes the current state of the enterprise architecture. Also called architecture as is (AS-IS) or the baseline of an existing architecture.

The current architecture is a reflection of an objective reality that includes existing components (business processes, information systems, technological elements) and their connections. This is a set of models with inevitable simplifications, limitations and subjective distortions.

The process of developing the current architecture is, first of all, the process of documenting and maintaining information about the state of the enterprise in an up-to-date form, which ensures the registration and control of information about all elements of the enterprise architecture, including maintaining a database of architectural objects; management accounting and state accounting.

The current architecture development process is similar to the ITIL/ITSM (Configuration Management) process. To simplify the work of developing the current architecture, many companies use the Configuration Item Database (CMDB), supplementing it with the necessary information.

Target Architecture - describes the desired future state of the enterprise or "what needs to be built" (TO-BE). In other words, the target architecture is the future model of the enterprise.

The target architecture can be called an ideal enterprise model, which is based on:

strategic requirements for business processes and information technology;

information on the identified "bottlenecks" and ways to eliminate them;

· Analysis of technological trends and business environment of the enterprise.

The target architecture (to-be model) and the current architecture (as-is model) make it possible to describe the initial and final state of the enterprise - before and after making changes to its structure, leaving the change process itself unattended.

The process of transition from the current enterprise architecture to the target one takes the enterprise to a new spiral of development and, thus, we can say that the enterprise architecture is characterized by a certain life cycle, similar to the life cycle of information systems.

Modern approaches to building enterprise architecture traditionally divide it into several layers (subject areas). Quantity architectural layers varies with different methods. Below we will look at the layers used in most of the existing methodologies(Figure 1.5.):

Figure 1.5. Basic layers of enterprise architecture

· Strategic goals and objectives of the enterprise.

· Business - enterprise architecture.

· Architecture of information technologies (IT architecture of the enterprise).

The architecture of information technology, in turn, is divided into:

Information architecture (Enterprise Information Architecture).

Architecture of applied solutions (Enterprise Solution Architecture).

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. Usually, EA's date of birth is considered to be John A. Zachman's 1987 publication "A Framework for Information Systems Architecture", although the term itself has appeared in more early works. 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 can 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 via 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 inherent complexity of 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, organizational form 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 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 Enterprise Architecture for a couple of sentences). 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. A simple and wrong way to line everyone up in one line with a beautiful name, for example, "Single list of priorities", and a way to distribute tasks among information systems - "Free cash desk!" - whoever can do it faster and cheaper, we will entrust him. The correct solution is a multifactorial classification of queries, in other words, a 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 head, and any manager, will not do it himself, but will ask someone else to get a 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 demonstration beautiful pictures 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 (story about enterprise architecture)!

The TSF software outside the core consists of trusted applications that are used to implement security features. Note that shared libraries, including PAM modules in some cases, are used by trusted applications. However, there is no instance where the shared library itself is treated as a trusted object. Trusted commands can be grouped as follows.

• System initialization
• Identification and authentication
• Network Applications
• batch processing
• System management
• User level audit
• Cryptographic support
• Virtual machine support

The execution components of the kernel can be divided into three parts: the main kernel, kernel threads, and kernel modules, depending on how they will be executed.

• The core core includes code that is executed to provide a service, such as servicing a user system call or servicing an exception event or interrupt. Most compiled kernel code falls into this category.
• Kernel threads. To perform certain routine tasks, such as flushing disk caches or freeing up memory by swapping out unused page frames, the kernel creates internal processes or threads. Threads are scheduled just like regular processes, but they don't have a context in non-privileged mode. Kernel threads perform certain functions of the kernel C language. Kernel threads reside in kernel space, and only run in privileged mode.
• The kernel module and device driver kernel module are pieces of code that can be loaded and unloaded into and out of the kernel as needed. They extend the functionality of the kernel without the need to reboot the system. Once loaded, the kernel module object code can access other kernel code and data in the same way as statically linked kernel object code.

The kernel consists of logical subsystems that provide various functionality. Even though the kernel is the only executable program, the various services it provides can be separated and combined into different logical components. These components interact to provide specific functionality. The kernel consists of the following logical subsystems:

• File subsystem and I/O subsystem: This subsystem implements functions related to file system objects. Implemented functions include those that allow a process to create, maintain, interact with, and delete file system objects. These objects include regular files, directories, symbolic links, hard links, device-specific files, named pipes, and sockets.
• Process Subsystem: This subsystem implements functions related to process control and thread control. The implemented functions allow creating, scheduling, executing, and deleting processes and thread subjects.
• Memory Subsystem: This subsystem implements functions related to managing system memory resources. The implemented functions include those that create and manage virtual memory, including the management of pagination algorithms and page tables.
• Network subsystem: This subsystem implements UNIX and Internet domain sockets, as well as the algorithms used to schedule network packets.
• IPC Subsystem: This subsystem implements functions related to IPC mechanisms. Implemented features include those that facilitate the controlled exchange of information between processes by allowing them to share data and synchronize their execution when interacting with a shared resource.
• Kernel Module Subsystem: This subsystem implements the infrastructure to support loadable modules. Implemented functions include loading, initializing, and unloading kernel modules.
• Linux security extensions: Linux security extensions implement various aspects of security that are provided throughout the kernel, including the framework of the Linux Security Module (LSM). The LSM framework serves as the basis for modules that allow you to implement various security policies, including SELinux. SELinux is an important logical subsystem. This subsystem implements the mandatory access control functions to achieve access between all subjects and objects.
• Device driver subsystem: This subsystem implements support for various hardware and software devices through a common, device-independent interface.
• Audit Subsystem: This subsystem implements functions related to recording security-critical events in the system. Implemented functions include those that capture each system call to record security-critical events and those that implement the collection and recording of control data.
• KVM Subsystem: This subsystem implements virtual machine life cycle maintenance. It performs statement completion, which is used for statements requiring only minor checks. For any other instruction completion, KVM invokes the user-space component of QEMU.
• Crypto API: This subsystem provides a kernel-internal cryptographic library for all kernel components. It provides cryptographic primitives for callers.

The kernel is the main part of the operating system. It interacts directly with the hardware, implements resource sharing, provides shared services for applications, and prevents applications from directly accessing hardware-dependent functions. The services provided by the kernel include:

1. Management of the execution of processes, including the operations of their creation, termination or suspension, and interprocess data exchange. They include:

• Equivalent scheduling of processes to run on the CPU.
• Separation of processes in the CPU using time-sharing mode.
• Process execution in the CPU.
• Suspend the kernel after its time quantum has elapsed.
• Allocation of kernel time to execute another process.
• Rescheduling kernel time to execute a suspended process.
• Manage process security related metadata such as UIDs, GIDs, SELinux labels, feature IDs.

• Permission granted by the kernel to processes to share a portion of their address space under certain conditions; however, in doing so, the kernel protects the process's own address space from outside interference.
• If the system is low on free memory, the kernel frees memory by writing the process temporarily to second-level memory or the swap partition.
• Consistent interaction with the machine's hardware to establish a mapping of virtual addresses to physical addresses, which establishes a mapping between compiler-generated addresses and physical addresses.

• Set limits on resources configured by the emulation application for this virtual machine.
• Running the program code of the virtual machine for execution.
• Handling the shutdown of virtual machines either by terminating the instruction or delaying the completion of the instruction to emulate user space.

• Allocation of secondary memory for efficient storage and retrieval of user data.
• Allocation of external memory for user files.
• Utilize unused storage space.
• Organization of the file system structure (using clear structuring principles).
• Protection of user files from unauthorized access.
• Organization of controlled access of processes to peripheral devices, such as terminals, tape drives, disk drives, and network devices.
• Organization of mutual access to data for subjects and objects, providing controlled access based on the DAC policy and any other policy implemented by the loaded LSM.

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) coordinated 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

Basic concepts

• 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.

• mission and strategy strategic goals and tasks;
• business architecture;
• system architecture.

Rice. 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.

• products and services offered and planned for sale by the bank (including individual schemes for their production), formalized in the form unified register products and services, which also contains customer 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 paper and in electronic format), formalized in the form of a single register (album of forms) of bank documents;
• document flows determined by regulations on internal and external document circulation;
• 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 divisions and working bodies and other documents regulating the relationship and distribution of responsibility between bank employees, as well as between structural divisions jar.

• 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

Rice. 3.

System Architecture Components

• applied systems (applications) that provide execution 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.

• 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.

• 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.

• 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 in emergency situations.

• 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.

Relationships between system architecture and business architecture

1. Mission and strategy of the bank, strategic goals and objectives.
2. Products and business processes.
3. Documentation.
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

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

Rice. 6.

Essences and relationships of two architectures

System Architecture Life Cycle

Rice. 7.

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

Rice. eight.

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

Initial Documentation

Table 1.

Usage

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

Table 2.

Design

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

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

Table 3

Migration

• Software testing.
• Implementation of software.

Table 4

• 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

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

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

Major Decisions

Requirements and standards

Application architecture

Technical architecture

Network architecture

Platform architecture

Data architecture

Contains a description of databases and otherwise organized information arrays.

Database management systems

Contains a description of the database management systems used.

Migration plan

Conclusion

• Who in the bank performs this or that business function, how regularly does it, what event causes 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 email, 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?