
Taxonomy is a $50 word that is one of the most important words in Enterprise Architecture. It’s tossed around a lot, and might go in and out of the ears of some — but it is super important. It means to establish what definition types you are capturing in your architecture; what you call them; and what they mean.
For example: in the US, a person holds a Job; in the UK they hold a Post. In the US, a soldier wears a uniform; in the UK a soldier wears a Kit.
Taxonomy is important in understanding your Information Technology (IT) architecture: what you establish as definition types for software and hardware; or applications and technologies; not to mention systems, and products.
Each of the major frameworks has done the work already for you — but even here it is often not enough.
IT Taxonomy for Major EA Frameworks
The Information Technology (IT) taxonomy for the main Enterprise Architecture frameworks varies:
- TOGAF 10’s metamodel specifies Logical Application Components (example, Enterprise Architecture tool), Physical Application Components (example, System Architect), Logical Technology Components (example, Database), Physical Technology Components (example, Microsoft SQL Server 2022), and Product. TOGAF 10 also specifies System as part of its Glossary of Supplementary Definitions, although System is not pictured in the core TOGAF 10 metamodel.
- UAF and DoDAF 2’s metamodels specify a System definition, a Software definition, and a Technology definition, for which you can have instances.
- ArchiMate‘s metamodel specifies Application Component (Logical), Application Component (Physical), and a Technology Service definition.
- sysML’s metamodel specifies Block, that can be of various Stereotypes, and have instances.
- Flexera’s Technopedia — which dubs itself “an IT Taxonomy” — tracks Software and Hardware versions of every vendor.
Categorization Theory
Further, if you are modeling or designing an architecture using the Solution Architecture templates of the major Cloud vendors — such as Microsoft Azure, Amazon Web Services (AWS), IBM Garage, or Google Cloud — you are using a litany of categorized items — each vendor providing their own sets of categorizations — within which you have to figure out which are software applications, technologies, services, and products.
For example, here’s a side-by-side look at how Google Cloud, Microsoft Azure, Amazon AWS, and IBM Garage offer up their Solution Architecture icon set with the following categories:
Amazon AWS | Google Cloud | IBM Garage | Microsoft Azure |
---|---|---|---|
Business Application | Application | Application | |
Machine Learning | Artificial Intelligence & Machine Learning | Watson AI | Machine Learning |
Application Integration | API | ||
Database | Database | Data | Data |
Storage | Storage | ||
Analytics | Data Analytics | Analytics | |
Blockchain | Blockchain | Blockchain | |
Compute | Compute | ||
Networking | Networking | Infrastructure | Technology |
Business Automation | Business Service | ||
Application Service | |||
Integration Services | Service Management | Platform Service | |
DevOps | DevOps | DevOps | |
IoT | Internet of Things | IoT | |
Security | Security | Security | Security |
Developer Tools | Developer Tools | ||
Front End Web & Mobile | |||
End User Computing | |||
Containers | |||
Robotics | |||
Media Services | |||
Migration | |||
Quantum | |||
Satellite | |||
Gametech | |||
Hybrid | |||
Operations | |||
Serverless | |||
General — where all other artifact types are put. | General — where all other artifact types are put. |
The VERSION of Things
Confused yet? Furthermore, what is often most important to understand in terms of an organization’s enterprise architecture is the VERSION of the software application, technology, service, or product in use.
It’s the VERSION of a software application that contains — or doesn’t contain — features, including new features and sunset features.
The major EA frameworks do not take Version into account. UAF and DoDAF specify Instances of things, including Systems, Software, and Technology — and on the instance you can specify a version as a numerical value. But you still need a definition type to capture the new, existing, and sunset features (a feature can be captured by a System Function, or Application Function).
Also, if you model instances of Systems, Software, and Technology — you may in many cases be capturing “too much information” about your EA. There is an art to Enterprise Architecture — you don’t want to capture too much, else it will be hard to maintain as things constantly change. You might be interested in licensing from an overall perspective, but when it comes to capabilities of the enterprise, and risk, you want to know what versions of apps are running and where.
Taxonomy Applies to All of EA
The importance of Taxonomy doesn’t end with IT — it exists throughout the EA; for example:
- When you talk about people, there are a variety of definition types used: Person, Stakeholder, Actor, and Persona.
- Whoever they are, they belong to Organizations, or Lines of Business, or Vendors. When it comes to modeling a Line of Business for example — do you model it as an Organization of type Line of Business, or a new definition type entirely called “Line of Business”? The answer is determined by a variety of factors: how different is the property set for Line of Business versus Organization, and its relationship to other artifact types in the EA. From a modeling perspective, you might not want your users to be sifting through a list of all Organizations when assigning a Line of Business to a system (although the list could be filtered to only show Organizations that are Lines of Business).
And don’t forget about services. We have:
- Application Services
- Microservices
- Business Services
- Platform or Technology Services
- etc
The Answers
The System Architect team has worked to provide solutions to clients for the questions above.
- System Architect’s TOGAF support provides
- Physical Application Version as a definition type. In the Physical Application Version you can specify “Application Functions” as “New Features”, “Sunset Features”, and “Existing Features.”
- This allows you to, for example, model System Architect 11.4.12 as a Physical Application Component Version, System Architect as a Physical Application Component, and Enterprise Architecture Tool as the Logical Application Component.
- A Physical Application Component Instance definition type is also introduced, for optional use.
- Physical Technology Component is already meant to capture the version of Technologies, as extrapolated from the TOGAF examples, which show version numbers on Physical Technology Components (but not Physical Application Components). To capture the Physical Technology Component type, we’ve introduced exactly that definition — Technology Component Type. This allows you to model, for example, Microsoft SQL Server 2022 as a Physical Technology Component, Microsoft SQL Server as a Technology Component Type, and Relational Database as a Logical Technology Component.
- Server Instance, Device Instance, and Database Instance are also introduced, which instantiate Physical Technology Component.
- Physical Application Version as a definition type. In the Physical Application Version you can specify “Application Functions” as “New Features”, “Sunset Features”, and “Existing Features.”
- For DoDAF 2 and UAF, we have done a lot of work on recent releases to improve modeling of instances. We have not as of yet introduced a definition type at the Version level, although it is easily do-able via usrprops. We will be working with the OMG Spec bodies to see if the community wants to add this to future versions of the UAF specification.
We’ll talk more about the Taxonomy of Services, and of Persons, Stakeholders, Actors, Persona, Organizations, Vendors, and Line of Business in another article. Perhaps two articles.
Be the first to comment