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. We will point out in this blog that many core things are missing in Archimate or are defined incorrectly.
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 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 as independent as possible. One would expect that independent refers to having no constraints concerning the usage or application of Archimate in other products, systems, organizations, or environments. But that is not the case.
Archimate definitely is not a standard like UML is. UML is an ISO standard (https://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail?csnumber=32624). Archimate and TOGAF are NOT. Archimate and TOGAF are commercial products promoted by consultancy organizations as standards!
I believe Archimate would be a better and more useful language if the Open Group treated it more like an Open and Independent language. The things that I address here in this blog should have already, for years, found their way into Archimate.
By referring to Archimate as an equal standard like UML is, in my opinion, confusing. I am often confronted by people modeling Archimate and asking me why Archimate causes so much discussion and why things are so ambiguous in Archimate. Its internal quality would be much better if it were a real ISO/IEC standard.
In this blog, I will explain why and how we have extended the Archimate metamodel 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 like our Dragon1 extension.
Activity, The Lost Entity Class
Before Archimate was handed over to the Open Group (its current owner), it looked like it contained an entity class called 'Activity'. As processes are defined as having activities in their 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 in Archimate versions 1, 2, or 3, you do not have any other symbol than the symbol for 'business process' to model activities with. However, 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 have to find out all about it yourself. You see 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 need to model the different types of activities.
Let us take a look at two common 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 this new business architecture principle needs to be implemented: Every Unique Patient Is Only Entered Once Through Thorough Identification. This principle will prevent the same person from having two data accounts in the company's 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. A new patient or new data cannot be entered into the core system without a valid passport. 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 an obvious picture of when what software application is used. Even without going into much detail about this. What could a business architect do if they did not model these activities? How can these kinds of activities be standardized 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 the types of furniture or people who will be using them.
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 everyone needs and that the other entity classes only some of us need can be included in the 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 think no enterprise, business, application, or IT architecture can be created without using the above entity classes. If you do, you are leaving out important 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 are core entity classes missing, but the definitions Archimate uses for their current entity classes are also incorrect and often confusing. For instance, the Archimate definition of a business process 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.
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 to.