User:Mdd/ArchiMate

ArchiMate is an open and independent enterprise architecture modeling language to support the description, analysis and visualization of architecture within and across business domains in an unambiguous way.

ArchiMate is a technical standard from The Open Group and is based on the concepts of the IEEE 1471 standard. It is supported by various tool vendors and consulting firms. ArchiMate is also a registered trademark of The Open Group. The Open Group has introduced a certification program for ArchiMate 2.0.

ArchiMate distinguishes itself from other languages such as Unified Modeling Language (UML) and Business Process Modeling Notation (BPMN) by its enterprise modelling scope.

Overview
Just like an architectural drawing in classical building architecture describes the various aspects of the construction and use of a building, ArchiMate offers a common language for describing the construction and operation of business processes, organizational structures, information flows, IT systems, and technical infrastructure. This insight helps the different stakeholders to design, assess, and communicate the consequences of decisions and changes within and between these business domains.

An architecture framework is used to structure the concepts and relationships of the ArchiMate language. It divides the enterprise architecture into a business, application and technology layer. In each layer, three aspects are considered: active elements that exhibit behavior (e.g. Process and Function), an internal structure and elements that define use or communicate information.

One of the objectives of the ArchiMate language is to define the relationships between concepts in different architecture domains. The concepts of this language therefore hold the middle between the detailed concepts, that are used for modeling individual domains, for example, the UML for modeling software products., and BPMN which is used for business process modeling.

History
ArchiMate is partly based on the IEEE 1471 standard. It was developed in the Netherlands by a project team from the Telematica Instituut in cooperation with several Dutch partners from government, industry and academia. Among the partners were Ordina, Radboud Universiteit Nijmegen, the Leiden Institute for Advanced Computer Science (LIACS) and the Centrum Wiskunde & Informatica (CWI). Later, tests were performed in organizations such as ABN AMRO, the Dutch Tax and Customs Administration and the ABP.

The development process lasted from July 2002 to December 2004, and took about 35 man years and approximately 4 million euros. The development was funded by the Dutch government (Dutch Tax and Customs Administration), and business partners, including ABN AMRO and the ABP Pension Fund. There were different stages of this development process:
 * At first the state of the art of architecture concepts and description, and of the architecture support has been investigated.
 * Next requirements have been developed for the modeling language that enables coherent enterprise architecture descriptions, and concepts for architectural modelling have been formulated.
 * Resulting in the construction and validation of the ArchiMate Language and final presentation in the "ArchiMate Language Primer."

In 2008 the ownership and stewardship of ArchiMate was transferred to the Open Group. It is now managed by the ArchiMate Forum within The Open Group. In February 2009 The Open Group published the ArchiMate® 1.0 standard as a formal technical standard. In January 2012 the ArchiMate® 2.0 standard was released.

ArchiMate topics
ArchiMate is an integrated architectural approach that describes and visualises the different business domains and their relations. Using these integrated architectures aids stakeholders in assessing the impact of design choices and changes.

Architecture
Organisations need to adapt increasingly fast and anticipate changing customer requirements and business goals. This need influences the entire chain of activities of a business, from the organisational structure to the network infrastructure. How can you control the impact of these changes? Architecture may be the answer.

Architecture is a consistent whole of principles, methods and models that are used in the design and realisation of organisational structure, business processes, information systems, and infrastructure. However, these domains are not approached in an integrated way, which makes it difficult to judge the effects of proposed changes. Every domain speaks its own language, draws its own models, and uses its own techniques and tools. Communication and decision making across domains is seriously impaired.

ArchiMate provides this integration. ArchiMate is an architecture language and visualisation techniques that picture these domains and their relations. ArchiMate will provide the architect with instruments that support and improve the architecture process.

Layers
ArchiMate has layered and service-oriented look on architectural models. The higher layers make use of services that are provided by the lower layers. Although, at an abstract level, the concepts that are used within each layer are similar, we define more concrete concepts that are specific for a certain layer. In this context, we distinguish three main layers:
 * The Business layer about business processes, services, functions and events of business units. This layer "offers products and services to external customers, which are realized in the organization by business processes performed by business actors and roles".


 * The Application layer about software applications that "support the components in the business with application services".


 * The Technology layer deals "with the hardware and communication infrastructure to support the Application Layer. This layer offers infrastructural services needed to run applications, realized by computer and communication hardware and system software".

Each of these main layers can be further divided in sub-layers. For example, in the Business layer, the primary business processes realising the products of a company may make use of a layer of secondary (supporting) business processes; in the Application layer, the end-user applications may make use of generic services offered by supporting applications. On top of the Business layer, a separate Environment layer may be added, modelling the external customers that make use of the services of the organisation (although these may also be considered part of the Business layer).

In line with service orientation, the most important relation between layers is formed by use relations, which show how the higher layers make use of the services of lower layers. However, a second type of link is formed by realisation relations: elements in lower layers may realise comparable elements in higher layers; e.g., a ‘data object’ (Application layer) may realise a ‘business object’ (Business layer); or an ‘artifact’ (Technology layer) may realise either a ‘data object’ or an ‘application component’ (Application layer).

General structure of models within the different layers
The general structure of models within the different layers is similar. The same types of concepts and relations are used, although their exact nature and granularity differ.

First, we distinguish the structural or static aspect and the behavioural or dynamic aspect. Behavioural concepts are assigned to structural concepts, to show who or what displays the behaviour. In the example, role, interface and collaboration are assigned to business process, organisational service and business interaction, respectively.

Second, we make a distinction between an external view and an internal view on systems. When looking at the behavioural aspect, these views reflect the principles of service orientation as introduced in the previous section. The service concept represents a unit of essential functionality that a system exposes to its environment. For the external users, only this external functionality, together with non-functional aspects such as the quality of service, costs etc., are relevant. If required, these can be specified in a contract or service level agreement. Services are accessible through interfaces, which constitute the external view on the structural aspect.

Although for the external users only the external view is relevant, the design of organisations or systems and their internal operations and management also requires knowledge about the internal realisation of the services and interfaces. For this realisation, we make a distinction between behaviour that is performed by an individual structural element (e.g., actor, role component, etc.), or collective behaviour (interaction) that is performed by a collaboration of multiple structural elements.

In addition to active structural elements (the business actors, application components and devices that display actual behaviour, i.e., the ‘subjects’ of activity), we also recognise passive structural elements, i.e., the objects on which behaviour is performed. In the domain of information-intensive organisations, which is the main focus of our language, these are usually information objects in the business layer and data objects in the application layer, but they may also be used to represent physical objects.