dinsdag 20 december 2016 | Likes: 0 | Comments: 0

Mark Paauwe

VP Product Development

Dragon1 Inc

Pure Logic: Making Archimate More Useful

Prelude

The Archimate metamodel, unedited, is useful to model Business Process-Application landscapes. It is not that useful to model full Business Architectures or Application Architectures as it is incomplete for these exercises. This we will point out in this blog, many core things are missing in Archimate or defined wrongly.

Beware: Archimate is a self-proclaimed standard, not an ISO standard!

The Open Group, the current owner of Archimate, calls Archimate an open and independent modeling language for Enterprise Architecture that is supported by different tool vendors and consulting firms.

The Open Group names all of its products Open Group Standards and in short even standards. So it calls or self-proclaims Archimate as standard.

When we dive into these claims, it is not that open as it could be, as they urge you to pay membership fees if you want to be open about being a tool vendor or want to participate in the development of Archimate. Also it is not that independent as it could be. One would expect that independent refers to having no constraints with regards the usage or application of Archimate in other products, systems, organizations or environment. But that is not the case.

Archimate definitely is not a standard like UML is. UML is an ISO standard (http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=32624). Archimate and TOGAF are NOT. Archimate and TOGAF are commercial products promoted by consultancy organizations as standards!

In my opinion, Archimate would be a better and more useful language if the Open Group would treat it more as an Open and Independent language. The things that I address here in this blog should have already for years have found their way into Archimate.

By referring to Archimate as equal standard like UML, is, in my opinion, causing confusion. I am often confronted with people modeling Archimate and asking me why Archimate causes so much discussion and why things are so ambiguous in Archimate. I would say that if it were a real ISO/IEC standard, its internal quality would be much better.

In this blog I will explain why and how we have extended the Archimate metamodel by using entity classes everyone knows and most of us would have expected to be already in there. If you do not want more than high-level modeling of a business process-application landscape, you do not need to extend Archimate. In all other cases, you will definitely like our Dragon1 extension.

Activity, The Lost Entity Class

Before Archimate was handed over to the Open Group (its current owner), it looks like it contained an entity class called 'Activity'. As processes are defined as having activities in its core, we have placed Activity back into the metamodel.

Here is more about the Business Activity in Archimate.

If you want to create a process model now in Archimate version 1, 2 or 3, you do not have any other symbol than the symbol for 'business process' to model activities with. But as a process or a sub-process is fundamentally different from activity, this, of course, is not a good solution. The Archimate specification does not mention how to deal with modeling activities as part of a business process. So here you really have to find out it all by yourself. What you see is that they show you may model processes as sub-processes of processes. But sub-process is not defined as a term and a sub-process also is not equal to an activity.

If you want to model enterprise architecture or business architecture, you definitely need to model the different types of activities.

Let us take a look at two commons business processes in Home Care Companies: The Intake Process and Admission Process

Intake Process

  • Receive Referral Phone Call
  • Gather All Necessary Information
  • Log the Referral
  • Verify Insurance Benefits
  • Coordinate With Other Departments
  • Determine Whether to Accept or Reject Referral
  • Call Case Manager Back With Acceptance or Rejection
  • If accepting the referral, Agree on Pricing, Conditions and Terms

Admissions Process

  • Set Up the Patient in the Computer System
  • Gather Any Additional Missing Information
  • Call Patient to Explain Services and Benefits
  • Prepare Patient Packet with Initial Order
  • Procure Documentation/forward to Billing Department

Suppose there is this new business architecture principle that needs to be implemented: Every Unique Patient Is Only Entered Once By Means Of Thorough Identification. This principle will prevent that one and the same person actually has two data accounts in the companies' system, potentially causing fatal problems for some patients.

As a business architect you need to know in which processes and types of activities the patient data is entered and how you can take measures to prevent the same patient is entered twice. For instance, you want to effectively take the measure of patients needing to identify themselves always with a valid passport. And without a valid passport, a new patient or new data cannot be entered into the core system. But maybe the data needs to be entered in a temp system/database.

If you look at the lists of business activities for these two processes above, as a business architect you get a very clear picture of when what software application is used. Even without going into much details with this. Now, what could a business architect do if he or she would not model these activities? Or how to standardize these kinds of activities throughout the company?

Processes without activities are like empty shells: you have a grouping but the things you group are nowhere. It is like a building architect designing rooms and spaces without knowing or regarding the types of furniture or people will be using the rooms and spaces.

As a business architect you NEED to be able to model activities. Not only processes or sub-processes, but activities!

New Core Entity Classes

Archimate says in its specification document that it only exists out of core entity classes that are needed by everyone and that the other entity classes only some of us need, can be included in time of need.

Based on years of modeling architecture using Dragon1 we have defined the following entity classes as still missing in the core of Archimate:

  • Enterprise
  • Organization
  • Business
  • System
  • Infrastructure
  • (Business) Rule
  • Need
  • Mission
  • Vision
  • Architecture
  • Concept

At Dragon1 we actually think that no enterprise, business, application or IT architecture can be created without using the entity classes above. If you do, you are really leaving out import foundations.

Application Modeling and Process Modeling

To do basic application modeling and process modeling we have the following entity classes to be of importance:

  • Software Application
  • Software Module
  • Choice (Gateway in BPMN)
  • Decision
  • Activity (as mentioned in the first paragraph)

There's more to come

Not only core entity classes are missing, also the definitions Archimate uses for their current entity classes are not correctly and often confusing. For instance, the Archimate definition of a business process that fails to mention that a process aligns activities to optimize usage of resources (why would you else define or recognize processes).

The Dragon1 Modeling language contains over 200 default and defined entity classes. Using further practice and modeling experience we will continue to add core or missing entity classes to the metamodel and improve the definitions of Archimate entity classes.

Of course, all your input on this topic is welcome. You can send it to info@dragon1.com. All suggestions and hints will be discussed and replied on.