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 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 as independent as it could be. 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!
In my opinion, Archimate would be a better and more useful language if the Open Group would treat it more like 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 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. 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 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 now in Archimate versions 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 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 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 there is this new business architecture principle that 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. 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 detail about this. Now, what could a business architect do if he or she did 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 the types of furniture or people who 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 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 that no enterprise, business, application, or IT architecture can be created without using the entity classes above. 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 core entity classes are missing, but also the definitions Archimate uses for their current entity classes are not correct 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.
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 to.