Enterprise architects see the enterprise as a system, each of the modules of which can be modeled in terms of roles and processes.
| External organization | A [logical or physical component] outside the business or system of interest that interacts with that business or system by requesting or providing services. |
| Actor | [A physical component] or a natural person capable of playing one or more roles in the execution of processes. (If non-human subjects are represented as applied and/or technological components, then the actors must be human.) |
| Organizational unit | [Physical component] or a single node in a management structure capable of performing one or more functions. It must have goals and objectives with measures and a manager. |
| Role | [Logical component], implemented or used by individual participants, defined in terms of the services provided and/or the processes performed and the abilities required. |
| Function | A logical component is a holistic set of behaviors required of any unit of an organization performing a function defined in terms of the services provided and/or the processes performed and the capabilities required. (This is a logical business opportunity that should not be confused with a managed organizational unit or a separate business service.) |
| Business process | [Process] performed by business participants with or without information technology. |
| Business service | A service that can be requested from a business or a component thereof. (not to be confused with a business function.) |
| Data object | A [data element] consisting of data elements that represent facts about a discrete business object or event. It can be set at a conceptual, logical, or physical level. This can be correlated with data stores and/or data streams input into or output from information security services. |
| IS (annex) service | [Service] that may be requested from a business-oriented component of an application by a human subject or other component of the application. |
| Application component | [Component] of business-oriented software (e.g. CRM, billing) Logically this is determined by the IT services provided, and sometimes also by the data objects it supports, and/or physically as a vendor/technology-specific product that can be hired, bought or created. |
| Platform service | [Service] that may be requested from a process component by an application component or other process component. |
| Technology component | [Component] of common infrastructure software (e.g. OS, DBMS) Logically defined by the platform services it provides and/or physically as a vendor/technology-specific product that can be hired or purchased. |
Corporate architects model the dynamic systems of the organization’s activities, information-dependent processes. logicalProcesses and data flows (i.e., roles and processes) that create and use data that a business needs to track or direct.
The systems being designed are zones of orderly behavior. The business system (furniture factory, marketplace, car factory) is a zone of stable and orderly behavior in the ever-evolving history of the enterprise. We can model its normal behavior.
Formalization is the representation of any substantive area (reasoning, evidence, classification procedures, information search, scientific theories) in the form of a formal system or calculus.
Example: The table of contents of the book is the formalization of its content parts, and the text of the book itself can be considered as a formalization by means of linguistic constructions of thoughts, ideas, thoughts of the author.The result of the formalization of scientific theory is, as a rule, a set of formulas, graphs, diagrams, tables, and so on.
What people say and do spontaneously, intellectually, or creatively can be referred to in business systems models, but only as a context of work that can be formalized and modeled in terms of regular event-driven behavior.
Business architects are not sociologists; business system architects do not model people; they model their roles.
Social systems are made up of actors who communicate and perform actions according to received messages and stored memories.
Business systems are social systems in which roles are formalized, messages are formalized in data streams, memory is formalized in data warehouses, and actions are performed in response to individual events.
Enterprise and solution architects don’t build airplanes, develop new drugs, design production lines, dig roads, or make movies. They seek to optimize and integrate business roles and processes by better leveraging the business information generated by those roles and processes. They don’t innovate in mechanical engineering, biochemistry, or creativity. They do seek new opportunities to digitize and integrate roles and processes, and to leverage the information gathered.
The need for such a corporate architecture is not new, and it will never disappear.
Corporate architects do not model everything that a business is or does; they focus on where the physical (manual, mechanical, material) world connects to the world of logical information; on the roles and processes that create or use information in the delivery of business products and services; and on improving business operations by integrating information created and used in the enterprise.
The Vocabulary of a Corporate Architect
How does a business system formalize a social system? Relationships between actors are defined by determining what actions a message might trigger, agreeing on the meaning of the messages being transmitted and stored memories.
To formalize and integrate behavior, parties must agree on the meanings of the symbols they create and use in messages and memory, which applies equally to people working on operating systems and architects modeling those systems.
Natural language is free and ambiguous. The words we use to describe things are verbal encodings of fuzzy mental models.
The Russian language has more than 200,000 words, different words have the same meaning, and one word has several meanings. For example, is “service” a process type, an instance of a transition process, a permanent function or a role responsible for different types of processes and instances? How is it different from “function” or “role”?
That doesn’t bother us in everyday conversations. But the professional specification of business systems is a different matter. If the graphical symbols in the system modeling language are just words, because people use them naturally, then the modeling language will be as big, vague, and ambiguous as natural language.
Of course, we don’t use words in a logical and orderly way. However, that’s exactly what we’re aiming for when describing formalized systems that need to be built, deployed and used by others. Professional systems architects need a controlled vocabulary. A business system description language should strictly and unambiguously distinguish between types of system elements (such as service, function, and interface) so that business system architects can use them in a consistent manner and easily understand each other.
The professional language of system modeling should be more disciplined than natural language.This should help architects describe system participants and actions using a small number of characters/words – the meaning of which is not ambiguous to avoid the vagueness of natural language.
UML is a graphical description language for object modeling in the field of software development, for modeling business processes, system design and displaying organizational structures.
*ArchiMate is an open and independent enterprise architecture modeling language to support the description, analysis and visualization of architecture inside and outside of business processes in an unambiguous way.
Harmonizing the vocabulary is a huge challenge. Using a variety of tools (which is necessary in practice) complicates the task. Harmonizing all the divisions of global business is even more difficult. The state of the industry leaves much to be desired. UML is controlled but limited and difficult to understand. ArchiMate is poorly controlled and conceptually unstable. TOGAF is free and inconsistent.
SYSTEM MODELIZATION PROVISIONS
To avoid confusion and harmonize architectural documents, use UML and ArchiMate, modeling languages designed to describe the structure and operation of complex business systems. UML can be challenging to learn, but it presents the basics of systems theory differently from ArchiMate. It is important to know that UML includes two basic principles for how systems work.
Discrete (from the Latin discretus – divided, intermittent) property opposed to continuity, intermittentness.
- All behavior is controlled by events, or discretely.
- All actions are performed by active structural elements (called active objects in UML; actors, components, and nodes in ArchiMate).
It is possible to express and extend the principles of UML using the concepts of ArchiMate.
encapsulation means that the systems and actors or components are placed in a shell called an I/O interface.
Behavior Describes how individual events trigger and execute standard patterns of action in a business system.
Structure indicates that actions in the system are performed by actors or components occupying a certain space and requiring addressing.
Data data A data object contains a data structure or element that is relevant to creators and users.
Abstraction Separation of system descriptions from existing or planned operating systems.
Typification It involves modeling types rather than specific instances.
Numerous business systems have been developed, created and used as a basis for learning the principles and problems described below.
1. Incapsulation
The purpose of creating a business system is to influence objects and events around it. The description of a business system involves defining the relationship between the system and the environment. Developers begin by identifying external objects and add them to the system model.
Principle 1.1: Systems are constrained by environment
Simply put, a social, business or software system is enclosed in a shell that exists only in the mind, not in reality. This table shows that the appearance of the system serves as the input-output boundary with which external objects operate. The internal content of the system reflects the actions of the participants or components within that shell.
| Environment | External objects and events | |
| System system | Appearance | Events/Services <presented in> Interfaces |
| The inside look | Processes «executed» by participants and components |
In some ways, the system and its associated external objects come together to form a larger system, but defining the boundaries of the system is vital; it tells us what the system designer designed and what didn’t.
Principle 1.2: Systems are nested and overlapping
Systems are arranged like nesting dolls. External and internal boundaries can be defined at any level of system detail. What seems external to one system can be internal to another. Each element of a system can be considered as a separate system. These elements, functions and roles can be encapsulated and described by the services they provide. ArchiMate emphasizes that systems are not only nested, but also intersect.
Principle 1.3: Component-based interfaces and stand-alone interfaces
The interface of a hardware device is the part that puts its body in three-dimensional space, but the idea of the world through material objects can be misleading, because the actions of people and computers are distributed in space.
The interface to the human or computer action system is logical and can be separated from it. It seems that the user interface is part of the word processor, but it can also provide access to other components, such as interactive help, a library of graphics objects or error reports.
The MS Outlook user interface is separate from the MS Exchange application. Service-oriented architecture (SOA) involves separating interfaces from components that do work. Thus, components and interfaces can be loosely coupled. One interface can be implemented using multiple components, and one component can implement some or all of the interfaces.
ArchiMate has different designations for interfaces and components. So architects can define an interface whose services are provided by two or more internal elements. They can also define an element that provides services through two or more interfaces. Unfortunately, ArchiMate has three problems with the relationship between components and interfaces:
- ArchiMate claims that components are “consisting of” interfaces, and that one interface is part of one and only one component, negating the possibility of loose connectivity between components and interfaces.
- If a component has the same address as its interface, the component is In this case, you don’t need to draw individual rectangles on the diagram.
- The ArchiMate interface definition focuses on the interfaces provided, not the interfaces required. Provided The interface defines the services that the system or component (acting as a server) provides and can serve clients. Required The interface defines the services on which the system or component (acting as a client) depends and which are delegated to the servers.
Principle 1.4: Business interfaces are not platform communication channels
A social, business, or software system is encapsulated logically rather than physically. An entity-to-subject or business-to-business interface can be defined in a document that lists the business services being called. Because actors and components are distributed, they must exchange individual communication events to trigger events and respond to calls. There must also be a physical communication channel through which communication events can be transmitted. In ArchiMate’s examples, there is confusion between the concept of a logical business interface (announcing what services can be called) and the physical infrastructure channels through which services can be called.
2. Behavior
The basic idea of systems theory is that the activity of a system is limited to its environment and occurs at the boundary between input and output. Architects study systems of activity by analyzing the repetitive actions (processes) that participants and elements (objects) perform in response to certain situations (stimuli).
The distinction between structure and behavior, fundamental to systems theory, seems clear in simple illustrations.
| System system | Structural elements | Behavioral elements |
| Solar system | planetary | sun-orbit |
| The human body | hearts, lungs and skin | breathing, running and sweating |
| Household services | butlers, guests and silverware | Greeting guests and polishing silver |
| Software | interfaces, classes, objects | operations |
But sometimes it’s hard to understand the difference between structure and behavior. In a certain sense, every active element of a structure has a behavior, and every behavior has a structure. The butler’s role or functions are determined by his actions. Every butler’s action has its logic and evolves over time. If you take all the actions out of the role or component description, it’s just a passive structure. It’s like when all the operations are removed from the class definition in UML and only the data types are left.
So, how do you make an unambiguous distinction between behavior and structure? The distinction made in UML is reinforced by unambiguous concepts of time and space. The distinction made in ArchiMate is based on linguistic concepts of subject, verb and object; these concepts are more blurred and lead to some confusion in the interpretation of the ArchiMate standard.
Behavior 2.1: Structure as a difference in time and space
Physicists claim that our world is in four-dimensional space-time. Each element or subject responds to information based on its memories and performs the corresponding actions, receiving a stream of input. Despite the fact that each element has its own «control stream», it is called a structural element, because it is a structure that can be placed in space and made to perform tasks over time.
General systems theory says that the system of activity is within its environment and is limited by input and output processes. Corporate architects look at systems of activity, classifying them by
- Regular behavior (repeated processes over time)
- actors and components (individual objects in space) in response to
- events (inputs or triggers).
| System system | Time-limited behaviour | Addressable structures |
| Appearance | Developments and results | I/O boundaries |
| The inside look | Ordinary behavior | Actors or components |
The behavior of a system is determined by the inputs and the results that external objects see. For example, you can send and receive emails without knowing how your email system works. The external structure is a place where external objects can run and view the results of behavior. The email application has two interfaces: one for people, the other for other programs. The table below is an example of such a structure.
| Time-limited behaviour | Addressable structures | |
| Appearance | Send an email, receive an email | Human interface, API |
| The inside look | (invisible) | E-mail application |
The difference between structure and behavior lies not so much in linguistic features as in spatial-temporal differences.
- Standard patterns of behavior in a business system are triggered by individual events and evolve over time.
- Actions in this system are performed by participants or elements occupying a certain space and requiring addressing.
Accepting these premises leads to a simple and reliable universal metamodel.
| System system | Time-limited behaviour | Addressable structures |
| What’s happening, what’s being done. | What can be found to achieve the goal | |
| What external organizations see | Events and services | Interfaces |
| Internal work | Processes | Persons and components |
General systems theory proposes to look at the behavior of a system as a whole. System design begins with determining the behavior to be followed by selecting, buying, or creating the structural elements to perform that behavior. In contrast, analysis of the underlying TOGAF system begins with examining existing structural components and creating a catalog of services based on them.
An “Archimatic” View of Structure and Behavior
*SVO — word order typology (in a sentence) — one of the methods of typological classification of languages, taking into account the basic order of words in the sentence: subject (English subject), predicated (English verb) and direct addition (English object).
The ArchiMate modeling language is based on the grammar of SVO natural language sentences. Most human languages use the SVO or SOV sequence in sentences. Curiously, the general metamodel ArchiMate is represented in the OVS sequence. The table below shows some of the keywords used in the ArchiMate modeling language, according to the OVS structure of its overall metamodel.
| Parts of Natural Supply | Object | verb | Theme |
| System aspects of ArchiMate | Passive structural element | Element of conduct | Active structural element |
| Elements of ArchiMate system | Business object, data object | Service, process, function | Subject, component, node, interface |
Linguistic concepts are flexible. Not all sentences have a subject and an object. The same thing can be a subject and an object in the same sentence. Nouns are used as verbs; verbs are used as nouns. Questions to be studied include: If a multiservice component is called a structural component, then why is a multiservice function (also a logical component) called a behavioral function?
This table shows the basic concepts of the general metamodel ArchiMate.
| ArchiMate | Behavior patterns | Structures |
| Appearance | Services | Interfaces |
| The inside look | Internal behavioural elements | Internal active structural elements |
The dictionary in the table isn’t very convenient. Maybe you can use other terms instead, like «actions» and «actors,» «performances» and «performers,» «operations» and «operators,» «developments» and «employees»? ArchiMate can’t do this because it doesn’t take into account the separation of space and time. The following table presents the words that ArchiMate uses to describe the external and internal aspects, as well as the behavior and structure of each level of the subject area of traditional architecture.
| Levels of architecture | Behavior patterns | Structures |
| Business-level | Business service | Business interface |
| Business process/function | Role/Personate | |
| Application level | Application service | Application interface |
| Application function | Application component | |
| Infrastructure level | Infrastructure services | Infrastructure interface |
| Function of infrastructure | Node. |
Multi-operation classes in UML are considered structural elements, and operations represent behavior patterns. However, in ArchiMate, the distinction between structure and behavior can be unclear, perhaps due to confusion between structure and behavior, and between type and instance. Instead, ArchiMate relies on the distinction between nouns and verbs in natural language.We can convert any noun (e.g., a broker) into a verb (brokerig) without changing the architecture of the system. Brokerage is not a service in the understanding of ArchiMate, where a functional unit should have a specific result. To better align ArchiMate with systems theory.
It is important to remember that all standard behaviors in a business system are triggered by individual events and executed over time. Enterprise architects take a service-oriented approach to business systems, where actors and components perform specific actions in response to individual event reports. To determine the details of a particular behavior, inputs, outputs, preconditions, post-conditions, and non-functional characteristics (such as a service contract or use case template).
Principle 2.1: An event type describes similar events that trigger behavioral elements.
External events cause participants or components to change the internal state of the system and/or provide services. Some services/processes do not change the state of the system. Some events fail, some only start reporting services/processes. If the process initiated by the event consumes a resource (say, electricity) that is not included in the model of the system, then such state change is outside the framework of the system in question.
WSDL is the interface definition language used to define «web services.» Where do you put a web service in this table?
| Levels of architecture | Behavior patterns | Structures |
| Application level | Application service | Application interface |
| Application function | Application component |
You could imagine a web service using the ArchiMate application service symbol, and the Internet using the application interface symbol. What does the ArchiMate standard really say? An interface is defined as a structure that provides one or more services, each of which is a functional unit with its own specific output.
- ArchiMate has determined that interface Thus, web-service An access point where one or more operations of a web service are open/accessible to customers.
- ArchiMate has determined that servicethen operation A web service is a unit of behavior with a specific result that a web service provides to its customers by hiding internal procedures..
| Levels of architecture | Behavior patterns | Structures |
| Application level | Web service operation | Web-service |
| Application process | Application component |
The use of ArchiMate and illustrations are at odds with its standard definitions of concept. The practice is at odds with systems theory, where, for example, applications are labeled as “services” (or “microservices”), interfaces are labeled as “services,” platform communication channels are labeled as “business interfaces,” the result being a mix of structure with behavior, confusion of architecture layers, and loss of coherence.
If we all agreed that a service is a separate unit of behavior that moves from a particular event to a particular outcome, then opposing interpretations of the term “service” would be unlikely.
Some suggest that services driven by individual events are too detailed for architects to worry about. This is misleading. Some services are short and/or secondary; others are long and/or critical. In practice, architects are interested in important services. If a system or component provides too many services to be displayed on a diagram, an architect may merge shorter services into a longer service or otherwise merge services into clusters. But service clustering creates a logical function/component rather than a larger service.
ArchiMate does not assume that behavior is event-dependent, and blurs the notions of event, process, and state change: it states that an event can begin or be the result of behavior.
Principle 2.1: Architects model multiple types of triggers
In UML, the behavior arrow from A to B is the transition arrow, it involves handing over control. In ArchiMate, the trigger from A to B may or may not be the transition arrow. It describes the temporal or causal relationship between instances A and B. Does that mean that A stops and B starts? No. Where A and B are coarse functions, it usually means that some part inside A triggers some behavioral element. inside B, and there is usually an accompanying data stream.