Translator Needed Complicating the problem further is that each of the four (PAEI)-types puts different meanings into the words "to be", "to want" and "to be required" based on their uniqueness. own picture 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 establish 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 some important element (cause, effect, intermediate goal or task, etc.) is not mentioned in the logical tree. 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

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 expand functionality kernel without having 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, 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 maintenance life cycle virtual machine. 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. These 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.
• A consistent interaction with the machine's hardware to establish a mapping of virtual addresses to physical addresses that 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.

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 technologies make it possible 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 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 others more frequent options please note it in the comments).

In the first case, we need to make Strategies –> Plan. It's about 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. About what should be done in this case, I will write in 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 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. A simple and wrong way to line everyone up with a pretty name like " single sheet 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 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 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 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 (enterprise architecture story)!

The second article about mythological consciousness will also be short. Today I will tell you what problems mythological consciousness leads to when modeling enterprise architecture.

The well-known Zachman model attempts to answer the question of what an enterprise architecture is and how it should be modeled. The basis of this model is the questions that are proposed to be answered: who, when, where, why and how does something on something. It seems to be a logical framework for describing enterprise architecture, and many people think that it is.

However, even a cursory glance at this framework leaves a feeling of dissatisfaction, because it is not clear how to answer the question: who and why machined the detail? Who: Ivan Ivanovich, or the turner, whose role was played by Ivan Ivanovich? Why: because the turner got the job, or because Ivan Ivanovich entered into a contract, according to which he undertakes to act as a turner in exchange for food? Why: because Ivan Ivanovich wants to eat, or because the part is needed in the assembly shop?

A deeper study of this framework makes one think about its applicability to the description technological processes. For example, let corn grow in a field. Applying the Zachman model, I have to answer questions. Who? Corn. What is he doing? Grows. Why? Because that's how the world works. For what? But who knows why corn grows ?!

A reader trained in describing enterprise architectures will quickly correct me. He will say that I am asking the wrong questions. It is necessary to ask: who grows, why he grows, what he grows. But then it turns out that I can describe the activity of the subject who grows corn, but I cannot describe the growth itself. Resigned to the fact that I cannot describe the growth process, I still have unresolved questions: who and why grows corn (see above)?

It turns out that by asking seemingly logical questions, at best I get a few answers, and at worst, I don’t get them at all. If we take the extreme case when we have a fully robotic enterprise in which there are no people at all, then the answer to the question "who?" will be - "no one". As a result, we can say nothing about this enterprise at all! True, there is one way out of this situation, a little crafty - you just need to use the mythical consciousness and animate the robots. Then, having animated the inanimate, we will be able to answer the question: who? Robot. Why? Because this robot is designed this way, or because the programmer programmed it this way. For the second question, we again get strange answers. Why did this happen, and what questions are really worth asking? I will try to briefly state my opinion on this subject by talking about the logical errors that I found in the Zachman model.

If you look at the questions that are asked in the Zachman model, you can see that they correspond exactly to the activity theory. Activity is a mental function of a subject (a group of subjects). Therefore, answering Zachman's questions, we build a model of the mental function of the subject (subjects). The science that studies the mental functions of subjects is called psychology. It turns out that Zachman answers the questions that psychologists ask: why does the subject do this or that action? Or how to motivate the subject to perform certain actions? These questions are certainly interesting and important, but are the answers to them a description of the enterprise architecture? To answer this question, you need to understand what is an enterprise?

How does the design of the enterprise actually take place and what artifacts arise in this process? Before designing an enterprise, a model of requirements for it is built. The requirements model is formed on the basis of the requirements that are presented to this enterprise by all its participants, contractors and stakeholders. An analogue in IT is the requirements for a software product. Further, based on these requirements, a model of enterprise processes is built with the required degree of detail. An analogue in IT will be a list of functions software product. Next, a model of functional objects is built, or, speaking specialized language, technical places that should participate in the processes listed above. An analogue in IT will be a description of procedures, and an explanation of which procedures are involved in which functions. Next, those pieces of equipment that can fulfill the roles of the listed technical places are selected. The counterpart in IT is software code.

An enterprise is a functional object that is created to meet certain requirements. In this sense, an enterprise is no different from an object such as a clock or a production line. Often, instead of the term functional object, you can hear the term technical place. A functional location differs from a piece of equipment in that the piece of equipment acts as a functional location. For example, a transformer plays the role of a voltage converter, while at different times different transformers can play the role of the same converter. Another example of a technical place is a position, department, division, state. For example, a turner is involved in the part manufacturing function. This is a technical place, the role of which can be performed by different pieces of equipment at different times ( individuals). I briefly wrote about the difficulties of modeling technical places and pieces of equipment in an article.

When modeling technical places, we describe the processes and participants in these processes. I note that it is the participants, and not the performers, that the transformer cannot convert voltage, because it is not an animated being. I wrote about this in a previous article. If, however, to say that a transformer “transforms” voltage, then this is a metonymy, which is revealed as follows: a transformer plays the role of a voltage converter, which (the converter) participates in the process of voltage conversion. You can read about metonymy in the book "Metaphors We Live By", authors: George Lakoff, Mark Johnson. Another common metonymy would be "a computer solves problems". Those who really believe that a transformer, or a computer actually does something, animate the inanimate, using the mythical consciousness.

Note that up to this point we have not said a word about goals, performers and cause-and-effect relationships. We only talked about requirements, about functions and participants of these functions - technical places. The goals remained at the stage of formation of requirements for the enterprise and they did not go further. We may or may not know these goals - it makes no difference to the enterprise model. The enterprise model answers the question: how do we meet requirements, not where those requirements come from. There are no performers either, because we don't need to use activity theory to describe the participants in an activity. We do not build causal relationships. If it is necessary to build a model of cause-and-effect relationships, then this is another additional model. This is the knowledge that technologists use when designing an enterprise, and I have not seen anyone build such models. This is branch knowledge, and they have been taught in institutes for many years. Modeling why a plane flies is unrealistically difficult, and no one does it. Just simulate the flight of an airplane.

So, the Zachman model does not include requirements for the enterprise, it includes a model of processes, but in a rather specific way - with an indication of the executors of the process, which, as I said, can only be found in the theory of activity, and does not separate the model of technical places and the model pieces of equipment.

As I said earlier, the Zachman model is more about activity. At the same time, it would be nice if the Zachman model was used for its intended purpose - as a way to describe activities. This would make it possible to analyze the motives and interest of people in their work, but the trouble is that this model is used incorrectly. For example, to the question “why does a turner sharpen a part?” you can get the answer: "it is needed in the assembly shop." But the need for it in the assembly shop does not answer the question why the turner sharpens the part. The answer was not to the question posed, but to some other one. For example, for such an answer, the question would be correct: in what process, or in what operation should the machined part be involved? Or at what workplace it is needed? You see, this is not a “why” question at all. In addition, I am very embarrassed by the ability of Zachman to endow a computer or information system with the ability to do something. Most likely, he does not animate them, but uses metonymy in modeling, which, in my opinion, is unacceptable.

The right questions are: What are the requirements for the enterprise? What processes take place in the enterprise? Which technical places are involved in which processes? Which pieces of equipment play the roles of which functional locations and when?

Actually, everything. Happy New Year, and see you soon!

We have already noted that there is no single correct definition of what an enterprise architecture is. Various consulting companies, industry associations, professional associations use slightly different concepts and techniques 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 understanding of 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, enterprise architecture design is not technical process, which is associated exclusively with information technology. Of course, for its development, as a rule, appropriate technological tools are used, 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 such fairly 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 appropriate organizational forms, processes, systems, information and a portfolio of applied systems.

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

• information systems professionals who are involved in relevant corporate projects creation of applications 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, control 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 an organization there is only one enterprise architecture, but at the same time, at the level of individual systems, there can be a large number of solution architectures (solution architecture). Enterprise architecture covers both business and IT aspects, as well as development processes, the evolution of the architecture and the management and control structure of these processes ( governance ) that provide a transition from current state architecture to the future desired state.