Development of ideas about the architecture of the...

Development of enterprise architecture views

The term architecture means a lot of similar concepts, but they are used in various applications. There are several hundred known formal architectural definitions.

In English-language sources - in techniques, articles, standards - the term "enterprise architecture" corresponds to the term enterprise architecture.

J. A. Zahman in 1987 in the article "Structure of the architecture of information systems" first he called his concept the architectural structure of information systems, and subsequently - the structure of the enterprise architecture.

The publications, mostly on the Internet, contain a large number of recommendations, materials of analytical companies, theoretical and practical developments in the field of IT architecture of organizations such as the Board of Directors of Information Technologies of the US Government (CIO Council) and others.

>

Since Zahman proposed the term "architecture" as applied to the information system, a definition in the programming style was originally distributed: "The architecture of the system consists of several components, external properties and interfaces, constraints and constraints, and the architecture of these internal components."

Table 8.1

Brief description of enterprise architecture concepts

Years of creation

Name, company (agency), author

The main idea of ​​the concept (model)

1987

The model of JA Zachman.

The enterprise model is represented as a set of consistent descriptions that correspond to the cells of the formalized matrix.

On the matrix columns, the main aspects of the activity are separated (objects - what & quot ;, actions - how & quot ;, locations- & quot ;, where & quot ;, people-who & quot ;, time- when and motives- why ). On the lines - various descriptions of the system from the point of view of business executives, managers and developers.

The matrix takes into account the architecture-relevant aspects of the enterprise. Matrix filling occurs from the top down

1994

US Department of Defense Technical Defense Framework for Information Management

1992

Enterprise Architecture Planning [7, 18], Stephen Spivak

The EAP methodology provides insight into the enterprise in terms of its business functions and information provision requirements.

Segment approach - 4 levels,

The 7 blocks that define the architecture, and the corresponding plan for its implementation. The model is based on the simplified Zachman matrix of 1987.

The essence of the EAP process is to determine the upper strings of this matrix (this includes the concept of technical means). The EAP methodology is a planning tool, but not a detailed architecture design. Planning results are used as the basis for the integrated development of application systems and technologies that provide business needs. The distinctive features of this approach to architectural planning are the following:

• the basis of the business needs, rather than technological factors:

• The focus is more on data and information needs than on processes;

• Representatives of business units are more responsible for the process than IT specialists. Spivak's approach was used by such organizations as: US Department of Energy, US Air Force Headquarters

1995

Model 4 + 1 (more precisely 2The 4 + + 1) View Model of Architecture, Philippe Kructen

It is suggested to use five views. The four main views in this methodology are as follows:

Logical representation. Responds to the question: what should the system do in terms of end users? For illustration, class diagrams can be used (in UML notation).

Process view. Allows for non-functional system requirements, including performance and availability. Describes the issues of concurrent execution and synchronization of processes.

Physical representation. Describes the placement of system software components on hardware platforms and aspects related to the physical location of the system.

Presentation of the development level. Describes the actual organization of the system modules, dividing it into subsystems that can be developed independently.

The architecture of the system is largely determined by the scenarios that unite all the views together.

Usage scenarios are described as a sequence of interaction between objects and processes. They reflect the most important requirements that the system must satisfy. This view is in some ways redundant and intersects with the four previous ones, but it is important for the following reasons: usage scenarios allow you to identify the elements of the architecture that are required for an efficiently running system; Using scripts, you can check and illustrate that the architecture is working and complete

1996

Strategic architecture model SAM (Strategic Architecture Model), English consulting company Systems Advisers Ltd

SAM is a superstructure over the Zachman enterprise architecture model. It provides common structures for defining architectures and mechanisms that allow you to organize and analyze information about the architecture.

SAM uses the notation of "spheres of interest *" to represent a holistic set of facts about the enterprise and "relationships" that link these facts to "useful" group.

The following categories of spheres are highlighted in the SAM model.

Stable - Fundamental structures that include business functions, raw data, business components, and infrastructure.

Movable is a simulation area that an organization can change quickly enough.

Dynamic are the main modeling areas in which an enterprise operates, as well as the actions that are required to move toward achieving goals and objectives through interrelated projects.

Spheres of Interest SAM allows you to systematize all information related to a particular subject

1996-1997

3D model enterprises, Evgeny Zinder

The time axis has been introduced, where the intervals for the implementation of various projects and stages of the development of IP and the whole enterprise are located.

The other axes are the Zachman matrix:

1) the axis of the level of design and use of IP;

2) the axis of the collateral section and the work aspect of the AND C;

3) the time axis in which the enterprise and its IS develops.

Strategic and detailed analysis can be viewed as both different stages,

which demonstrates the principle of adapting the circuit to the life cycles of different types. The nature of the location of the architectural components of IP in this third dimension is very diverse, since in real life many of the enterprise's transformation processes run in parallel and iteratively.

The scheme can be broken down into the following steps:

The first step is a general discussion of the 3D schema by enterprise managers and their departments. It aims to achieve a common understanding of all types of entities of this scheme as components and representations of the system in their life processes - the processes of creation and subsequent transformations.

The second step is the division of works to build the most common model of a 3D enterprise between managers. The coordinator of all the works can be a deputy director general or a director for development.

The third step is// strong> to involve specialists and middle managers with assigning specific sites to them, that is, modeling areas, at the levels of the 3D model, starting from the second and lower.

The fourth step is the initial and informal description of those particular models that are relevant to immersion in the general model "as is."

The fifth step is the consideration of a set of particular models with their interrelationships

1999

The generalized architecture and methodology of GERAM, the CIMOSA Association, the 1FIP-IFAC working group

The GERAM (Generalized Enterprise Reference Architecture and Methodology) methodology is included as an application in the current core standard for enterprise architecture - ISO 15704: 2000, Requirements for enterprise-reference archite ctures and methodologies. and is still being considered in new standards (for example, ISO 19439: 2006, "Enterprise integration Framework for enterprise modelling").

The GERAM scheme provided for [7]:

• four groups of aspects of the enterprise architecture, called Views - model types ( functions & quot ;, data, resources, quot ;, organization ), assignments (can be associated with the column WHY Zachman), implementations, and physical representations (hardware, BUT) and the ability to define additional aspects;

• a description of all aspects or some part of them in each of the seven or eight phases of the formation of the architecture and functioning of the enterprise;

• Specification of the architecture model at three levels - generalized, level of partial models and specific models

2002-2006

The architecture of the federal organization FEA - Federal Enterprise Arhitecture, US Administration of Administration and Budget

In 1999, the Board of Directors of Information Technology of the main government bodies (CIO Council) proposed the structure of the architecture of the federal organization (FEAF). Version 1.1 of ISO 15704.

In 2002, the FEAF methodology was reworked into the FEA.

FEA can be considered both as a methodology for creating an enterprise architecture, and as a result of applying this methodology to a specific organizational structure - the US Government.

The FEA idea is mainly aimed at creating a segment architecture for a subset of the overall enterprise architecture (in the case of the FEA, the enterprise is the federal government, and the subset is the government agency). The diagram of segments of the federal government is shown in the figure. The figure shows that many segments are used in many agencies and all or almost all of these segments can be reused.

FEA is the most complete methodology: it includes a comprehensive taxonomy, as in Zachman's methodology, and the architectural process, as in the TOGAF model

December 2003

DOE/DoDAF Framework - Department of Defense Architecture Framework, US Department of Defense

DoDAF contains the rules, guidelines and documents that should be used to design and describe the architecture of the various systems used by the US military.

The architecture describes three views:

• operational;

• System;

• Presentation of technical parameters. Each of them is used to reflect different architectural characteristics

and attributes. There are intersections - some of the attributes unite two different representations, which provides integrity, unity and uniformity in the description of the architecture.

The most important element and strength of the technique are the so-called architectural products. These are graphical, textual, tabular descriptions that are created in the process of describing the architecture and which capture characteristics relevant to the process.

2003

TOGAF - The Open Group Architectural Framework, The Open Group Consortium

The TOGAF model is used to describe the integration components used by the support of a wide range of enterprise applications. As an architectural process , the TOGAF model complements Zahman's model. Zachman shows how to classify artifacts. The TOGAF model describes the process of creating artifacts.

In the TOGAF model, the enterprise architecture is divided into four categories.

1. Business Architecture - describes the processes used to achieve business goals.

2. Application Architecture - describes the structure of specific applications and their interaction with each other.

3. Data architecture - describes the structure of enterprise data warehouses

and procedures for accessing them.

4. Technological architecture - describes the hardware and software infrastructure in which applications are started and interacted

2005

Gartner Model, Gartner Company

The Gartner methodology is neither a taxonomy (like the Zachman model) nor a process (like TOGAF), nor a full methodology (like FEA). This methodology is a set of practical recommendations for building an enterprise architecture, developed by Gartner, one of the world's most famous research and consulting IT organizations. Gartner believes that the architecture of an enterprise should begin with what the organization intends to achieve, rather than from the current state of affairs. After the organization has formed a unified view of its development, you can consider the impact of this representation on the architecture of the business, the technological architecture, the information architecture and the architecture of solutions.

In this approach, recommendations are formulated concerning the development of an architecture in the form of a series of steps and tasks of participants, which, however, are not detailed to the level of models of the architecture development process.

The Gartner architecture description technique is a three-dimensional cube consisting of the following elements:

• horizontal layers - business architecture. These are four related, interdependent and more complex levels;

• vertical domains - an information architecture that includes Applications, Data, Integration, Access;

• Vertical elements of the technical architecture, including Infrastructure, System Management, Security. In this case, the above-described layers of business architecture intersect with all elements of information and technical architectures

2005

Meta Group methodology. Company Meta Group

A distinctive feature of the META methodology is a more detailed and formalized description of the process of developing the architecture and all its components.

The architecture is implemented in practice through the process of managing IT programs and projects.

Provides for the joint participation of representatives of business units and IT in developing a common understanding of the set of requirements.

The organization of the architecture development process and the creation of the initial enterprise architecture version, according to the Meta Group, consists in the following stages:

1. Vision of common requirements in architecture.

2. Development of the concept of architecture.

3. Architectural modeling.

The technique offers formalized templates that provide the development of basic documents: "Vision of General Requirements" and Principles of conceptual architecture

However, soon E. Singer proposed a broader definition: "The architecture of an enterprise is not at all the architecture of information systems or technologies; This concept covers both the organization of business (public management activities, if this ministry), and basic technologies (for example, machines, ATMs, technological processes, etc.), and employees of all types and grades, and information technology ". .

Architectural view on systems (both IT systems and business systems) is defined in ANSI/IEEE 1471-2000 as a fundamental organization of the system, consisting of a set of components, their relationships with each other and with the external environment, as well as the principles that guide them in their creation and development. "

The formal definition in the IEEE 1471 standard of the Institute of Electrical and Electronics Engineers for the definition of architecture suggests a metamodel. This standard defines such abstract architectural elements as representations, systems, environments, rationales, stakeholders, etc. In accordance with this view, the "system has some architecture that can be described in a certain way from different points of view depending on the interest of those people (participants) who are considering the architecture of the system. To each point of view on the architecture of the system there corresponds a certain representation, the basis of which is a certain set of models .

However, this standard does not define the structure of the enterprise architecture itself. For example, it says that you need to have different representations of the architecture, but it does not specify what kind of representations this should be.

For the enterprise architecture, a formal description was first formulated in the ISO 15704 standard, which was proposed by the IFAC/IFIP working group (International Federation of Automatic Control/International Federation for Information Processing). The idea was to develop the most general, so-called reference model of the enterprise architecture, which would encompass the process of development of the enterprise in time as a project, and take into account the role of the human factor. Then the architecture of individual subsystems, including enterprise IT systems, can be developed as specific refinements of such a general model.

Developed as an annex to this standard, this general reference architecture model is called GERAM (Generalized Enterprise Reference Architecture and Methodology). In fact, GERAM is an abstract description of a general-level architecture that can be used for binding and comparing among themselves various practical models of architectures. In particular, it defines concepts such as the product & quot ;, life cycle & quot ;, personnel role in the system, process modeling applied to the tasks of describing the functioning of the enterprise.

In the National Standard of the United States, architecture is defined as the "description (model) of the main device (structure) and links, parts of the system (physical or conceptual object or entity)".

It is proposed to distinguish between two types of architectures relevant to enterprise integration, namely:

a) system architectures (sometimes called "type 1" architectures) that extend to system design, for example, a computerized system that is part of an enterprise integration system;

b) standard projects of the enterprise (sometimes called architectures of type 2), which affect the organization of the development and implementation of the project, for example, the integration of the enterprise or other enterprise development program.

In some works, types such as system architecture (system architecture - System Architecture) and software architecture (software architecture - Software Architecture) are selected.

However, although the methodology of describing and designing the architecture of individual application systems has much in common with approaches to describing the architecture of an enterprise as a whole, nevertheless the architecture of software systems is a separate field of knowledge, which is devoted to a large number of relevant publications.

Under the software architecture depending on the context, can be understood as the architecture of application interaction within the enterprise information system (i.e., application architecture), and software module architecture or interaction architecture of various classes within a single application.

Each of the architectures, in turn, can be viewed with this or that level of detail. So, for software architectures, the following levels of the architecture description are distinguished:

conceptual architecture - defines the components of the system and their purpose, usually in an informal manner. This view is often used for discussion with non-technical specialists, such as management, business managers and end users of the system's functional characteristics (what the system should be able to do, basically from the perspective of the end user):

logical architecture - highlights, first of all, the interaction of system components, interfaces and protocols used. This view allows you to effectively organize parallel development;

physical implementation - describes the binding to specific host locations, hardware types, environment characteristics, such as operating systems, etc.

An interesting example of the analysis of various aspects of the software architect's work is proposed in the IEEE 1471-2000 standard.

In accordance with Gartner's definitions architecture is:

• A general plan or concept used to create a system, such as a building or information system, or an "abstract description of the system, its structure, components, and their interrelations";

• a family of guidelines, concepts, rules, templates, interfaces and standards used in the construction of a set of enterprise information technologies.

The first definition is focused on the description of existing and future systems, the second - on the process of their construction.

Galaktionov VI offers to consider the architecture of an enterprise in two aspects:

• static - at some fixed time;

• dynamic - as a process of transition (migration) from the current state to some desired state in the future.

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

• mission and strategy, strategic goals and objectives;

• business architecture;

• system architecture.

The architecture of the enterprise considered in the dynamics is a logically connected whole plan of actions and coordinated projects necessary to transform the existing architecture of the organization to a state defined as a long-term goal that is based on the current and planned business goals and business processes of the organization.

Thus, the enterprise architecture is generally described by the following sequentially dependent sections.

Designing a system architecture involves dividing the system into the most large components and accepting constructive solutions which, after accepting , are difficult to change. If later it turns out that something to change is easier than it seemed at first, it's "something" is easily excluded from the architectural category.

The static slice of the system architecture at a certain point in time includes:

• Application architecture - the functional and component composition of the information system

• Data architecture - ways to interact systems and store data;

• hardware architecture - the technical means/solutions used.

Other aspects of the system architecture are:

• Ways and plans for migration from the current state of the architecture to the target architecture;

• ways to transfer implementations between environments;

• cost of the solution, including capital and operating expenses.

In this VI Galaktionov believes that there is more than one way to describe the architecture. The degree of importance of each of these methods varies at different stages of the life cycle.

Danilin A.V. and Slyusarenko A.I. spend analysis of architecture definitions and suggest, depending on the context, to define the architecture of the system as [7]:

1) a multidimensional description or plan of a conceived or developed system at the level of its components, detailed enough to guide its implementation, as well as the principles and guidelines that guide the design and development of the system over time;

2) the structure of the existing system as a totality of all components and their interrelationships.

In the second variant of this definition, the architecture of enterprises was always.

Based on the methodology of Gartner, according to which the approach to the formulation of the architecture should be based on the analysis of business processes and supporting applications, the authors of [7] conclude that "the architecture of the enterprise is one of the tools of organizational changes of the whole enterprise in general, using IT, and especially that part of the organization that is responsible for information technology, "and that" the notion of the architecture of an enterprise has its roots in a discipline called "system m " .

And give a more detailed explanation of this idea as follows:

"A distinctive characteristic of the decisions made with respect to architecture is that these decisions must be made taking into account a broad, or systemic, perspective. Any decision that can be made locally (for example, within a subsystem) is not architectural for the system as a whole. This makes it possible to distinguish between detailed design and decision making about the practical implementation of the system, on the one hand, and architectural solutions, on the other. The first solutions have a local influence, and the second - a systematic one. Therefore, for project solutions, a corresponding broader perspective is needed, allowing to take into account the systemic influence of higher-level decisions, which makes it possible to achieve the desired level of compromises and agreements between the components to ensure the proper level of quality of the system as a whole. "

However, in [7] it is noted that organizations experience constant difficulties in synchronizing the goals and objectives of business and the development processes of their information systems. There is, as it were, the cloud of uncertainty between the definition of the organization and its IT infrastructure providing its goals and objectives.

The architecture of information technology and the architecture of the enterprise as a whole, according to the authors [7], is the main mechanism for interpreting and realizing the organization's goals. This is achieved through the creation of a certain number of interrelated architectural representations, which, using various techniques of describing the architecture, break down the architecture of the enterprise into a different number of models and definitions related to such areas as business, information, application systems, technological infrastructure.

Business models describe the organization's strategy, management structures, requirements, constraints and rules, as well as basic business processes, including relationships and dependencies between them. That is, business models describe at the level of the enterprise as a whole how the basic functions of the organization are realized, including organizational and functional structures, roles and responsibilities, location, time, types of files and databases and other information stores.

Information architecture identifies key assets related to structured and unstructured information required for business, including location, time, types of files and databases and other information stores.

Application Architecture describes those systems that provide the necessary functionality to implement the logic of the organization's business processes.

From the perspective of the technological architecture , important models include a description of the IT services that are required to implement the three other areas of the architecture listed above.

In this case logical models of IT services are built in an abstract, technologically independent form and leave the freedom for the optimal choice of specific technologies. But in the end, the enterprise architecture ends with physical models , which are determined by the technologies, hardware and software platforms chosen to implement IT services.

Hierarchical construction of the architecture allows to facilitate its perception by the person.

In definitions, at least three different aspects can be distinguished:

• hierarchy of architectures of different organizational systems;

• the relationship between objective reality and subjective perception;

• the relationship between the system-wide architecture and private architectures.

You can talk about the architecture of an enterprise as a whole, the architecture of the level of individual projects or a family of products, the architecture of a single application system.

In this case, all types of architecture should use similar means of description and presentation of results, rely on methods of decomposition (structuring) of complex systems, and the architecture is a certain model of a real system that dynamically changes, preserving the correspondence to the original.

IT professionals understand the IT architecture as a fairly broad range of concepts - a structured family of technical guides, including concepts, principles, rules, templates and interfaces, and the interrelationships among them that are used to develop existing and create new information systems. In contrast, business professionals do not view this issue as a matter of exclusively technology. On the contrary, they talk in terms of business models, business processes and sometimes - business architecture.

In the evolution of the concept of "enterprise architecture" This term represented an increasingly complex and comprehensive description (by description and purpose) of information technology to support the main activities of the organization and, as a result, an ever wider range of benefits.

In earlier works, IT architecture was understood primarily as a technological architecture or architecture that defines the infrastructure of the information system. The work on describing the architecture was focused on the formation of technological standards and principles, including the inventory of various technologies used in the organization. This approach allows to achieve certain private benefits, primarily related to a reduction in the cost of procurement and operation of information systems, a reduction in the cost of application development and training of personnel. However, it was limited, as it did not imply an orientation toward solving business problems.

The next step was the notion of the enterprise information technology architecture enterprise scale (EWITA - Enterprise-wide information technology architecture). This meant that efforts to describe the architecture of an enterprise should include a description of the architecture of the information and architecture of the application systems, and not just the technological level. The main line of work was to share common data, eliminate duplication of business functions, coordinate the management of users, resources, information security through improvements in portfolio management of application systems. Corporate information technology architecture of the enterprise scale describes how the components of the information system are interconnected; Similarly, the business architecture describes how business elements are linked together.

This approach ensures more efficient interaction of various structural divisions of the enterprise, joint access to information from various departments and external organizations (customers, partners, suppliers); Reduction of duplication from the point of view of parallel implementation of application-related application systems for various business units; solving problems that affect the interests of several departments, for example, the integration and interaction of information systems.

An important logical step for an effective description of existing processes in the enterprise and planned changes was the introduction of the Enterprise Architecture concept, which combines the enterprise IT architecture with business architecture and allows to achieve its strategic goals.

The advantages of such inclusion of a business architecture in the context of considering an integrated architecture of the enterprise are its great ability to change, which ensures the dynamism ( agility ) and the synchronization of information technology capabilities with the business strategy, ensuring the variability of the business strategy due to the possibility of changes in the supporting processes and technological solutions; the best prospects, from the point of view of using the capabilities of information technology but the formation of a business strategy.

Thus, the concept of an enterprise architecture was the result of searching for a holistic approach that would provide an overview of the organization as a single system.

Introduced the concepts of enterprise architecture, application architecture, data architecture, technological architecture, which allows us to briefly characterize the various multidimensional structures of different strata of IS - strata of data, software applications, client-servers, technological stratum, enterprise IP in general, i. enterprise architectures.

The enterprise architecture concept is a multidimensional model describing its structure and functions, allows to obtain a detailed description of its information system, including goals and objectives, processes and their organization, technologies used.

The concepts structures and architectures are used ambiguously:

• Or the concept of structure characterizes the structure, location, order, i.e. IC configuration - architecture structure in Zachman;

• or there is a point of view, according to which, under the architecture refers to the description of the system in terms of end-user interfaces

interaction with the external environment, i.e. as an external view of the IS, and the structure are described in the form of interacting subsystems, i.e. internal IC configuration. At the same time, each subsystem can be divided into component parts in the hierarchy, up to the modules of application programs accepted for indivisible elements. Thus, the concept of a structure is represented in the form of a hierarchy (tree-like or stratified) that includes several levels of partitioning, and the resulting structural units, in turn, can be represented as an architectural description with respect to external structural units.

Also We Can Offer!

Other services that we offer

If you don’t see the necessary subject, paper type, or topic in our list of available services and examples, don’t worry! We have a number of other academic disciplines to suit the needs of anyone who visits this website looking for help.

How to ...

We made your life easier with putting together a big number of articles and guidelines on how to plan and write different types of assignments (Essay, Research Paper, Dissertation etc)