ArchiMate or the convenient limitations of ADOit?
Some time ago I wrote about the considerations to make when defining an Enterprise Architecture Repository (EAR). One of these considerations is the meta-model. I generally stick to the principle: “adhere to standards unless …”. This means that by default I would base an EAR on the industry standard ArchiMate.
Some EAR tools like Sparx Enterprise Architect support this standard (though not necessarily all aspects of it, like e.g. the derivation concept: see this link.
Other EA-tools however may offer a proprietary meta-model.
ADOIT is such a tool. I got acquainted with it through two of my customers. ADOIT is a product from the BOC-group, which you may know for their Process Modelling tool ADONIS.
The meta-model of ADOIT is basically rather similar to ArchiMate, though there are significant differences as well. As I am familiar with ArchiMate through earlier EAR-projects I used that as a reference to compare to ADOIT. This exercise resulted in an overview of the deltas between both meta-models and led to a better understanding on their strengths and limitations. I would like to share my findings, so you may benefit too.
First, I will present the ArchiMate model, next the ADOIT meta-model and finally the comparison between both.
ArchiMate
ArchiMate consists of several functional groups of object-types that may be used to record the Enterprise Architecture in all it facets. It supports the (Togaf recognized) Business, Application and Technical architecture layer, and extends these with a physical layer, motivational objects and a layer to plan transitions. (See the earlier link for the ArchiMate specification).
The meta model consists of the object-types as depicted in the figure below:
Note that the ArchiMate specification defines a generic set of relationship-types that may be used between specific objects. However, ArchiMate allows to leave certain objects out of a view if they are less relevant. The mechanism of “relation derivation” allows to “fill up” any relational gaps between objects that may not be related directly. It supports indirect relations between these objects which are identifiable through a derivation rule. This makes it possible to virtually relate all objects to each other in any way if required.
ADOIT
ADOIT metamodel just like ArchiMate consists of grouped object-types, of which Business, Application and Technology appear in both meta models.
ADOIT provides the following definitions for the object-types:
| Object | |
| Governance | |
| Goal | A high-level statement of intent or direction for an organisation. Typically used to measure success of an organisation |
| Architecture Priciple | Principles are general rules and guidelines, intended to be enduring and seldom amended, that inform and support the way in which an organization sets about fulfilling its mission (TOGAF (TM) ). |
| Control Objective | Control objectives provide a complete set of high-level requirements for effective and practical governance and management of enterprise IT.
They are: |
| Risk | |
| Risk | T risk is a part of business risk—specifically, the business risk associated with the use, ownership, operation, involvement, influence and adoption of IT within an enterprise. It consists of IT-related events that could potentially impact the business. It can occur with both uncertain frequency and magnitude, and it creates challenges in meeting strategic goals and objectives (Risk IT, ISACA) |
| IT Asset | An IT asset is any company-owned application, technology, facility or data that is used in the course of business activities. In general all elements of the current state and future state of the EA are IT assets. CobiT refers to IT assets as IT resources. |
| Business | |
| Domain | A domain is a means for categorising architecture objects. This might take place from different point of views, such as tailoring domains based on business processes, products, organisational units or locations. |
| Business Capability | A business capability represents an aggregated business function. In other words, the highest level of drilled-down business functions is called business capability. A business capability is the ability to perform certain business functions and deliver business results or values. |
| Business Process | A business process is a series of interrelated processes or activities which are performed in a logical sequence. The goal is to deliever a good or service and thus, contribute (directly or indirectly) to the corporate value creation. A business process has a defined starting and end point with focus on customer needs, and is often recurrent. |
| Business Function | Through decomposition from a business capability derived, business functions are fine-grained functions used/required by business processes. Business functions can be formed regardless of relevant aspects to the organisation or IT. Furthermore, a function hierarchy can be created. Business functions are not necessarily driven by IT. |
| Product | Products are units sold for a certain price. These units may be either material or immaterial products or services. Products can be composed from other products or product components |
| IT Service | A service provided to one or more customers by an IT Service Provider. An IT Service is based on the use of information technology and supports the customer’s business processes. An IT service is made up from a combination of people, processes and technology and should be defined in a service level agreement. (ITIL V3) |
| Contract | Contracts can be of the following types: Service Level Agreement, Operational Level Agreement, Underpinning Contract, and Licence Contract. |
| Org. Unit | An organizational unit refers to an independent unit in an organisation. Organisational units have their own ressources, an independent management structure, strategy and goals. An organisational unit can also refer to partner organisations or third parties. Example: Finance department, IT department. |
| Location | A location refers to a geographical place where IT architecture artefacts (applications, application components, infrastructure elements) are situated. Locations include countries, places, buildings, rooms and other venues |
| Stakeholder | Stakeholder is generally refered to as a specific person who is responsible for architecture artefacts or who is assigned as responsible for particular architecture artefacts. According to the user rights concept, which is directly linked to the concept of responsibility, the stakeholder is granted write access to the artefact where he or she is assigned to as the responsible person. |
| Role | It refers to a role either performing functional tasks or technical tasks. These tasks can be carried out by one or more persons or even different groups of persons |
| Inf. Systems | |
| Application cluster | An application cluster refers to the logical aggregation of applications |
| Application | Applications describe the software used in a company or organisation from a functional point of view. In other words, applications support the business with their functions. From an outsider’s view, applications refer to definite and independent IT systems with defined interfaces to other systems |
| Application Component | An application component refers to a modular, exchangeable and deployable component of an application |
| Service | In business terms, a service refers to a well-defined and business-oriented functionality which supports business processes. It is imperative for the business user to understand the service definition without knowing IT jargon or specific terms and terminology. In information technology, a service refers to a distinguishable, packaged and reusable software resource. It is characterised by a description, an interface and configurable guidelines for the usage of the service. |
| Interface | An interface enables the communication between applications and/or application components. This communication is established when one or more architecture artefacts provide an interface and other architecture artefacts (such as applications) use this interface to access the data or functions of the element that provides the interface. |
| Business Object | A business object refers to an aggregated type of data which represent real-world objects (such as customer, bill, product or contract) in the corporate data model. In other words, business objects represent packaged data or information which are usually defined by the business side of the company. The structuring of the business objects enables business processes, applications and services to use and exchange business objects. The so-called CRUD procedures (Create, Read, Update, Delete) can be performed on business objects. If the data processing is supported by IT, it should be ensured that only one application or service “creates” the business object (Create, Update, Delete). This will ensure the consistency of the business objects. Business objects can be interrelated and in addition, a business object hierarchy can be created. This helps break down abstract business objects. |
| Technology Arch | |
| Technology package | A technology package refers to packaged technologies. These packages are used to facilitate the management of technologies and more important reuse these packages in association with other IT systems. Furthermore, technology packages represent a suite of technologies to provide infrastructure that supports the delivery of applications and other artefacts of the information system layer |
| Technology | A technology refers to a product consisting of hardware or software or both. Technologies can be classified into different categories, such as operating system, database or server |
| Infra element | A infrastructure element refers to a resource (often a server or cluster) used for operating applications, application components or databases etc. In other words, infrastructure elements are considered the production environment of the mentioned architecture objects. |
| Network element | Network elements are analog and digital devices and supporting equipment that provide communication services such as switching, multiplexing, and transport services to subscribers. Examples are router, switch, hub, repeater etc |
| Database | In the EA context, a database refers to a data storage device where business objects can be managed in a structured way. Business objects can be created, read, updated or deleted by applications, application components or services. |
| Transformation | |
| Project | A project refers to a series of activities which change the enterprise architecture. For instance, a transformation from the baseline architecture to the future architecture is carried out by projects. |
| Demand | A demand refers to a functional requirement regarding one or more architecture artefacts, for example business processes, organisational units or applications. Demands are usually carried out by projects and thus, have an impact on the enterprise architecture |
As a quick scan points out there are several similarities with ArchiMate, but quite a few differences as well.
Relations seem to be stricter in ADOIT than in ArchiMate. The model consists of a limited set of relations between the objects, as described in the matrix below.
The model shows that the ADOit meta model provides a very proprietary way of relating objects to each other. This is very different from the ArchiMate approach of a limited set of generic relationship-types.
Note further that ADOit does not explicitly support derived relations in modelling, unlike ArchiMate.
ADOit is very object oriented. It is primarily about administratively about maintaining lists of architecture object, by filling attributes. The (very specific) relations to other (existing) objects may be defined likewise. There is a modeling feature as well, but I have not seen it be used.
ArchiMate by default cares more about drawing models of objects and relations, an basically cares less about the attributes (unless the ArchiMate based meta-model is extended with attributes)
Comparison
To comparing both models with each other we map ArchiMate to the ADOIT-model and the other way around too.
Mapping ADOIT on ArchiMate
The figure below depicts the similarities and differences when mapping ADOIT upon ArchiMate. It displays all the ArchiMate objects and using color-codes it depicts how they are covered (or not) by ADOit.
It shows that the Business Architecture and Application Architecture layers of ArchiMate are quiet well supported, the other layers less.
Mapping ArchiMate on ADOIT
The figure below depicts the similarities and differences when mapping ArchiMate upon ADOIT. The figure below depicts the similarities and differences when mapping ADOIT upon ArchiMate. It displays all the ArchiMate objects and using color-codes it depicts how they are covered (or not) by ADOit.
It shows that ArchiMate almost covers the entire ADOit meta-model.
