The concept of enterprise architecture

MARIA IACOB: Hi. My name is Maria Iacob. In the next minutes, I will talk about the what, why, and how of enterprise architectures. Let us start with answering the question of what enterprise architecture is. To come up with the definition of the concept, I will first have to explain the two words that make up its name– enterprise, and architecture. We look at an enterprise in the broad sense, which means it can be anything ranging from a simple department to a chain, or even a network of companies, or government agencies.

According to the Open Group, which is maybe the most relevant standardisation body in the area of enterprise architecture, an enterprise can be any collection of organisations that has a common set of goals. The scope of the enterprise should be clearly defined, agreed upon, and understood to be the same by all parties concerned. It should be also documented and made available. Let us now move to the general definition of a system architecture. As given by the ISO standard 42010, the definition quoted on this slide is defining a system architecture in terms of its structure, consisting of components, Their externally visible properties and relationships, And their are underlying principles. Simply said, a system structure with a vision for design and evolution.

If we combine the two definitions given above, we may conclude that enterprise architecture would focus on the description of an enterprise structure, and of the principal guiding its design and evolution over time. Within the Open Group, there has been a call for definitions of enterprise architecture. Of course, many definitions are possible. But the important thing to remember about architecture is that it basically refers to three things. Firstly, enterprise architecture is a product. It’s actually a high-level blueprint of the enterprise consisting of formal or less formal architectural descriptions. Such descriptions are realised sometimes by means of a modelling language. And the standard modelling language for architecture provided by the Open Group is called ArchiMate.

Secondly, enterprise architecture is also about a development process. It’s a way of working, for creating an architectural design. Such a methodology has been defined by the Open Group, and it’s called the Architecture Development Method, or, shortly, TOGAF ADM. In the broader sense, enterprise architecture is also a discipline. Both TOGAF and ArchiMate cover certain topics of this discipline. However, nowadays, the discipline of enterprise architecture is extending more and more through links with strategic management, portfolio management, operations management, organisational science, business analytics, software engineering, and many more. So why do we need enterprise architecture? Think about a small project like building a shed in your backyard.

You do not really need a full-fledged architecture to do that, although a few drawings and some calculations would do no harm. Now think about building a sport hall. Would you start without having first a precise architecture, blueprints for the floor plans, wiring, plumbing, clearly defined? The same goes for enterprise architecture. Large and complex organisations cannot be managed efficiently without a clear architecture. There are many arguments mentioned, both in the scientific and practitioner literature, to justify the necessity for enterprise architecture. I would like to mention a few of them. Architecture helps organisation choose a direction for the future, and define their own, and right, business strategy. It also allows the design, while taking different perspectives into account.

Maintain control in changing conditions. Master and manage complexity. And it also can become a risk-management instrument. But most importantly, enterprise architecture could help organisation align their business goals with their actual organisational resources and capabilities. The role of enterprise architecture in achieving the alignment between strategic business goals and organisational resources and capabilities also becomes apparent when we try to position our enterprise architecture within the enterprise. As you may see from this slide, enterprise architecture actually functions as a bridge between an enterprise’s motivational elements, expressed in terms of mission, vision, and business strategy, and its operations, embodied in the various business processes, the software architecture used by these processes, and the IT infrastructure present in the organisation.

Furthermore, enterprise architecture should be an integral part of any implementation and governance process, and the base for managing enterprise change. As I said a bit earlier, a comprehensive approach for architecture would have at least the following elements– a process, also called a method, for developing architectures; a viewpoints classification scheme that defines the different perspectives of interest in an architecture; and, finally, a language for describing architectures. The Open Group has an architecture framework that contains such a process, and many, many other things, like viewpoints, reference models, and other enterprise architecture techniques and resources.

On the other hand, ArchiMate, another Open Group international standard, is a comprehensive architecture specification language that also comes with a rich collection of architecture concepts, relationships, and with an architecture framework. TOGAF and ArchiMate complement each other well, and have a common conceptual foundation. This is also why, in recent years, they have been used in combination, and they are, more or less, the standard approach to develop enterprise architecture.

Let us now move to the last question, the how. So, how to specify an architecture? Let’s go back to the analogy with civil engineering. In any construction project, many stakeholders are involved, having their own role, their own interests, speaking their own language. The same holds for enterprise architecture. Furthermore, in constructions, each stakeholder creates and uses a specific type of blueprint, talks about specific activities, specific materials, and looks, in its own specific way, to the same object– the future building. With enterprise architecture, things happen in the very same way. Different stakeholders need different type of architecture models in order to look at the architecture. All these models can be built with the ArchiMate language.

So ArchiMate has several advantages, next to that of being an international standard. It has a graphical notation and a method model that makes possible a uniform and consistent specification of architectures. It comes with a framework, which has a simple and intuitive structure, and it allows the modeller to divide the whole enterprise in primarily three layers, the business, application, and technology layers; and three aspects that should be modelled in each of the layers, namely, information, structure, and behaviour. Each cell in the framework could be handled, modelled, and analysed separately, which leads to a decreased complexity of the architecture descriptions, and insurers its completeness.

The language is also endowed with the appropriate mechanics to allow the modeller not only to specify models for each of the layers and aspects, but also to explicitly model the dependencies between layers and aspects. And, last but not least, in the last decade a lot of research has been carried out that led to the creation of various model-based, qualitative and quantitative analysis techniques, such as performance analysis, cost analysis, analysis of security aspects. All these types of analysis could be used in order to monitor and manage enterprise changes.

ArchiMate consists of three components– a language core, which was defined in the version 1.0 of the standard, and some language extensions that appeared later, namely the motivation extension that made possible the specification of motivation models and linked them to enterprise architecture, and the implementation and migration extension that focuses more on the dynamic and time-related aspects of enterprise architecture, and made possible the link between enterprise architecture and programme and portfolio management. In the remainder of this video, we will also take a closer look to the ArchiMate core. The concepts and relationships included in the ArchiMate core are meant for creating architecture models that cover the central part of the ArchiMate framework, as shown on this slide.

To give you a better idea about the structure and contents of the ArchiMate core, we show in this figure a simplified version of the ArchiMate Metamodel, which is also mapped on the ArchiMate framework in order to make the semantics of the different concepts, and the relationships between them, more intuitive. You may have noticed that the Metamodel contains a certain pattern that is repeated in each and every of the architectural layers. Thus, within each layer, the behaviour elements can access the information elements that can be found in the Passive Structure column, while behaviour concepts are further assigned to Active Structure elements that are capable of performing behaviour. Furthermore, between layers, realisation and used by relationships are possible.

One of the most prominent concepts defining the ArchiMate core, and occurring in each of the enterprise layers, is that of a service. A service is a piece of externally observable behaviour which is offered to users in the environment surrounding the architecture framework where the service is realised. A service is mostly used in an architecture model to make possible the connections between layers. For more information, exact definitions, and examples of models regarding the language, concepts, and relationships, please consult the official standards specification. We conclude this video with an example of layered enterprise-architecture model to give you an idea of how the language may be used in practise.

Needless to say, that many other types of models can be created using the language. Various examples of which are given in the standard specifications, and can be simply found on the internet, as well. On this slide, you see the high-level architecture of an insurance company called ArchiSurance. More precisely, the model is focusing on a few business services, namely that of claim registration, claim payment, and some customer information service. These services are offered to policyholders, with the purpose of supporting them with the claim submission and handling process. The model also provides a high-level description of the different process steps related to claim handling, namely registration, acceptance, valuation, and payment.

And it gives information about the actor that is supposed to carry out this process. The claim handling process further uses a few application services, shown in this layer. These services are realised in the application layer by several application components, namely the CRM system, the policy administration system, and the financial application. Similarly to the business layer, the application layer uses, in turn, two infrastructure services that are realised by the technology layer of ArchiSurance. In this way, the architect can create an overview of ArchiSurance’s most relevant architectural elements, and of their relationships. Thank you for watching this video.