Contents
Introduction
Modern applications may consist of several layers. Because of this complexity, it is often challenging to decide how best to categorize and record information in order to generate a model. Your decisions about how to record components, can impact your analysis and ultimately your ability to answer key business questions. It’s therefore critical to carefully consider each component and build a solid foundation.
In this article we will provide general guidance on:
How to identify and model complex business systems
How to categorize components in Ardoq
Implications of choosing various component types in your models and analysis
By carefully considering the definitions and examples provided, you can simplify your work and improve the quality of your output.
As you start out on your Application Portfolio Management (APM) journey, you may very quickly run into this question: What exactly is an Application, and how do I model them in Ardoq?
As you review that long list of items in your Applications spreadsheet, or perhaps imported from your CMDB, it will likely contain many items, some may be applications and some may not. But before we talk about the definition of what is an application and what isn't, let’s talk about why we need to review definitions in the first place.
We document applications or technologies to achieve certain objectives or outcomes, not just as a routine task. Different outcomes require different levels of modeling precision. For example, you may need to model an application to a certain level of detail to meet governance requirements, but if you don't have those requirements then you don’t need to model to that same level of detail.
Before you start importing data or defining workspaces, consider the following criteria to help you define an application:
When looking at the current and/or target landscape your audience should be able to see the "applications" that they talk about in daily work conversations
The information and level of detail needed about application costs
The technology product information
The need to reference specific maintenance team(s)
The need to identify separate deployable functionality
Whether you need to reference business and technical capabilities
Even with the best definition, there may be situations that pose a challenge. Examples we will cover in this article include:
COTS applications hosted on-prem
Applications within middleware infrastructure such as integration middleware, low-code solutions, and analytics platforms
Applications that are Platforms that host multiple smaller applications. E.g., Salesforce SFDC with SalesCloud, ServiceCloud, etc.
Self-developed applications or solutions that consist of multiple deployed services each running on their own runtime environment
Based on our experience, we have found that these scenarios will cover a vast majority of cases, and, when there is a lack of clear examples, we apply the following 3 key principles.
3 Principles for Modeling Components
Before we get into the definitions and examples let’s cover some of the principles we will follow throughout this document:
Use hierarchies (parent-child relationships) to represent decomposition. Other dependency or utilization relationships will be represented using references (Read more on this topic).
One should only model to the level of detail that is required to achieve the desired business outcomes. To model all these various application and technology types in a consistent way with high fidelity can be very challenging. Therefore you should model at the minimum level of detail that is needed for your purpose.
The language of the model, and therefore the component types that are adopted, should reflect the meaning and the modeling context that makes the best sense to the organization. The distinction between different types in the metamodel should reflect the different concepts understood by people across the organization.
An example illustrates how this last principle has influenced our design of the metamodel. In a traditional retail bank, a business system developed with a microservice architecture will be recognized by its business staff as an application. But the underlying microservices sit within the realm of the software developers. Modeling this with an Application that is supported by a set of Application Modules (the microservices) fits the language of the organization, and allows them to easily create visualizations that suit different internal audiences. The microservices can be easily filtered out when presenting a business view.
The same solution, developed at a FinTech organization, might be perceived very differently. Here, the business staff may be very familiar with the microservices architecture, and all might think of these as applications with which they, the business users, compose services. They may choose to model the same microservices as individual Application components.
We’ve chosen to make Application, Application Module, and Technology Service component types functionally similar. They can occupy the same roles across our Use Cases (e.g. IT Cost Management) and can have the same types of children, parents and references. This gives the modeler more flexibility in terms of choosing different component types to model their software ecosystem, making the creation of visualizations to suit different audiences easier. It is a good idea to develop a set of guidelines that determine what types of software asset you will model with these three types for your organization: each organization can develop its own application modeling language. But always bear in mind that you should only model to the level of detail that you need (following the modeling criteria given in the introduction above).
Check out our Seven Principles for Creating a Great Enterprise Architecture Metamodel article for more principles on modeling in Ardoq.
Ardoq Definitions
Application
In the Ardoq metamodel we define an application as:
“A deployed and running software solution that provides specific business or technology capability, performs a defined task or analyzes specific information. It has meaning for, and its name will be recognized by, its business users. It may be part of (i.e. a child component of) an Application Group (e.g. MS Word as part of MS Office) or a larger Application (e.g. SAP Finance Module as part of SAP).”
Now that we have defined what an application is, let’s get to some of the other definitions for components that will be covered in this document.
Application Module
A deployed and running software component that has meaning for, and will be recognized by, the team that developed or supports it. It is unlikely to be referenced, by name, by business users, as its role is to support one or more applications that they do recognize. It may be a component (represented as a child component) of an Application or another Application Module, or it may be a standalone component (e.g. A scheduling microservice may be used by multiple applications but it's not at the level of recognition to be classified as an application itself, so it would be documented as a standalone application module.). Application modules may also help realize business or technical capabilities similar to Applications. Standalone Modules or Application Modules that support multiple applications will almost always have their own interface(s). Even Application Modules that support a single Application will most likely have it’s own interface.
Application Group
Application group component types are used to package up a family or suite of applications (e.g. Microsoft Office) that are grouped together to represent their licensing, or deployment together as defined by the manufacturer. If the parent grouping would be recognized by, and referred to as, a single coherent business system by business users, it should be represented as an Application component instead. Application Group components do not carry the same metadata fields or references as an application.
Interface
A dedicated point of interaction between two or more applications or other technology components (e.g. Application Module or Technology Service). It implements functionality to enable interoperability and exchange of information, including agreed behavior, common semantics, and defined security and availability.
Data Store (a.k.a Database)
A persistent dataset that may consist of one or more linked tables or files containing structured data, such as a database (as distinct from its host database management system, which is represented as a Technology Service). It may directly support users through a dedicated user interface, or support Application, Application Module or Technology Service components.
Figure 1 - Application A with a database modeled as a child module
There are a few ways to represent a database in relation to an Application, Application Module, or Technology Service.
A database that is part of an application, but an in-memory database module (as seen in Figure 1 above)
A database that is considered part of the application but it’s a separately deployable module. On the same or a different server.
A database that is used by multiple applications. It’s not part of a single application, and it’s maintained separately. Connection to this DB is through an integration (see below).
In the example above we have two applications that leverage a separate standalone DB and they do this through a connection to an interface.
Technology Service
A technology service is a component that provides technology support or hosting services for an Application, Application Module, Server or other Technology Service components. Examples include deployed instances of database management systems, virtual machine platforms for operating systems or applications, RPA and workflow platforms, data warehouses, BI and reporting platforms. If the component would be recognized by business users as a business system in its own right, it may alternatively be represented with an Application component.
Technology Service or Application
There is a deliberate overlap between a technology service and an application. This reflects the sophisticated blend of capabilities that software systems offer today. Scripting, “point and click” coding and configuration, and visual programming, have blurred the distinction between what in the past would have more clearly separated Technology Services from Applications.
So if you are faced with a dilemma as to which component type you should use to represent a software system, how should you decide? Start by re-reading the two definitions, given above. In the vast majority of cases, you will be able to make a clear choice: most systems’ function and behavior is either clearly that of a service supporting other applications, or of providing business functionality to its users.
The two component types share common fields (e.g lifecycle, governance, etc), enabling one to choose one or the other. If you’re still unsure which component type to use we recommend using the component type that best fits the language used in your organization:
If a software system is recognized and talked about by business users as a business system, you should model it as an Application. It will appear, by default, in visualizations where you are showing Applications to business stakeholders.
If a software system provides services to multiple business systems, perhaps by hosting differently configured or coded solutions serving different business teams or realizing different business capabilities, you should model it as a Technology Service. In this situation, the underlying software system is part of the language of technology specialists, but less often referred to by business users, who talk about the individual business systems it hosts. Examples here might include workflow engines and data analytics platforms.
If a software system primarily realizes a Business Capability, it is probably best modeled as an Application. If it primarily realizes a Technical Capability, it is more likely to be viewed as a Technology Service. See What Are Technical Capabilities for more information about the distinction between Business and Technical Capabilities.
If your need is to model your IT landscape then either Technical Service or Application type(s) will work. If you need to perform more complex analysis such as cost roll-ups or rationalization then it’s recommended using the application component type as the Ardoq use cases perform this analysis on Applications. For more information on some of the key metadata differences between Applications and Technology Services check out the Application Rationalization Metamodel the IT Cost Management Metamodel and the Application Hosting Metamodel articles.
Server
A Server, while very similar in function to a Technology Service, represents a physical or logical processing unit that supports an Application, Application Module, Technology Service or other Server components. The Server component type is offered as an alternative that may provide a more meaningful name, but is conceptually similar to the Technology Service. See the Application Hosting Metamodel for more information
Node
Ardoq defines the concept of the node component type as an abstracted object for grouping logical, computational, or physical resources that host, manipulate, or interact with other computational or physical resources. See the Application Hosting Metamodel for more information.
Technology Product
An item of software, hardware or firmware available for deployment. This is a catalog entry, not a deployed running instance. It has Deploys To reference links to deployed running instances. It allows version, licensing, vulnerability, lifecycle, vendor and manufacturer information to be held once rather than replicated with each deployed instance. The catalog is typically organized in a hierarchy of Folders with leaf nodes as Technology Product components to represent specific versions, releases and builds. Composite Technology Product components may be defined representing standard “builds or stacks” containing multiple Deploys To references from other Technology Product components (e.g. a standard database server combining hardware, operating system and database management system Technology Product components).
Modeling Complex Business Systems
Now that we have some good working definitions, let's look at some different ways to identify what an application is and how to decompose it into its parts.
All of Something or Part of Something?
The first step in deciding what is and what isn’t an application is to ask whether they are single applications, groups of applications, or parts of applications. Again, this is often harder to decide than you’d expect. Nonetheless, it’s important.
Business systems and their constituent applications and components are modeled using component types and nested to reflect their parent/child hierarchy:
An Application component represents a business system or application that has meaning to and is referred to as an application by, its business users. An Application Module is a component of a business system or application functionality that has meaning to its developers or maintainers but is not typically referenced as an application by its business users. In all other respects, Applications and Application Modules behave in Ardoq in the same way. Their children, if they have any, represent their decomposition.
Figure 2
As seen in Figure 2. SAP is an Application, but individual modules - e.g., SAP Finance (FI) is often referred to as an Application in its own right by its business users. SAP FI realizes specific business capabilities, and can have its own references to owners and experts, etc.
An Application Module may have Application Module children if the representation of further decomposition is useful in the model. For example, you may have a customer-facing application and within that application are several modules to manage customer accounts, manage customer orders and provide customer service. The customer service module may then decompose into several additional modules that deliver specific functionality such as support chat, chatbot services, order look-up services, scheduling services, etc.
An Application Group component may be used to collate a set of Application components as a family or suite of applications where the group itself would not be recognized as a single application, but where the group makes sense in relation to packaging, licensing, or deployment as defined by the manufacturer. Application groups do not share the same metadata (e.g. Technical Fit, Business Fit, etc) or reference information (e.g. Ownership, Capability Realization) requirements as an Application. If you need to collect specific information or ownership then consider using an application type instead of a group.
Where an application or application module provides information to other applications or modules, the interface through which it provides these integration services is represented with an Interface component. The applications or modules it serves are connected to the Interface component with Connects To references. The Interface may, in turn, contain Supplies references to Data Entity components to indicate what information is supplied via the interface. See the Getting Started with Application Integration Management article for more details.
The Software Stack
Software doesn’t exist in isolation but as part of a vertical ‘stack’. From the Application at the highest level down to the lowest level of the stack, the software that any IT system needs to run: Operating systems, databases, run-time environments, and even virtual machines that directly emulate hardware.
First, let’s cover databases.
Databases
The way in which a database is modeled depends on its relationship with other components. Often, a database is an embedded part of an application, acting as the persistent store for the application and not interfacing with any other application. In this situation, it may not be necessary to represent the database as a separate component within the application, but if it is (for example because it is deployed on a different server from other components of the application) then it is modeled as a Data Store within the Application (i.e. a child).
Sometimes a database serves more than one application. In this situation, such a database is modeled as a stand-alone Data Store component that can have reference connections to more than one Application and, where required, their constituent Application Modules.
A Data Store’s underlying database management system is often used to host multiple Data Stores. Where there is a need to model the running instance of the database management system separately, we use the Technology Service component for this. So a single deployment of a database management system that is host to two databases (which may, in turn, serve multiple different applications), would be modeled as follows:
Now let’s look at some of the other supporting technologies in the vertical stack.
Platforms and Infrastructure
Two component types are used to represent the software and hardware infrastructure that host, or provide services to, applications, their modules and databases: Technology Service and Server. Technology Service is used to represent deployed instances of any software infrastructure that acts as a host for, or provides software services to, running software. Examples include operating systems, database management systems, virtual machine platforms, servlet engines, application servers, container platforms, and cloud platforms and services. It is also used to represent a service that supports the running of Applications or Application Modules. Examples include the Microsoft Power Apps, the AWS Lambda Service, and other code and component libraries and services.
Separately modeling the Server and Technology Service may not always be necessary. It might be sufficient to represent the whole as an Application that is connected to other applications, where there is no need to represent each client separately. For example, a reporting engine could be viewed simply as an Application whose Interface is connected from other Applications. If there is no value in separately modeling business reports within the engine, then a single component will suffice. Platforms such as Salesforce, SAP, ServiceNow, could be represented as Technology Services that host Applications, or as simple Applications. As articulated in Principle 3, the approach should be determined by the uses to which the model will be put, the language that makes best sense to the model’s users, and the business outcomes that are being sought.
Finally the Server is used to represent a deployed physical or logical server. The reference Supports / Is Supported By is used to associate an Application, Application Module or Data Store with its host. We discuss this relationship in much greater detail in the Application Hosting Metamodel article.
Now for the bottom of the stack, the Technology Products. As defined previously in the Technology Portfolio Management; Purpose Scope and Rationale. A technology product is “An abstract catalog entry, not a deployed running instance.” Catalog entries representing technology products and their individual versions are modeled using the Technology Product component type. A hierarchical catalog can be represented using nested components of the same type with the parent/child relationship. This allows the catalog to document different versions of products in detail if required. The Windows Server operating system catalog entries might be modeled like this:
You may also choose to define composite Technology Product components that represent standard combinations of other Technology Product components. These are connected with the Deploys To reference. An example, shown below, might be a catalog entry that defines a standard database server configuration in your organization:
Product or an Instance?
It is important to emphasize that Technology Product components are used to represent abstract, master descriptions of products, individual or composite, like entries in a catalog. Application software products, database management systems, operating systems and physical products such as servers, laptops and mobile phones are all represented in the same way with the Technology Product component type. These components do not represent operational instances of those technologies, as there may be multiple instances for each technology product, each of which may have its own associated data. So the operational instances are modeled as individual instances of a different component type: Applications and Application Modules for software, Technology Services for platform-like services such as operating systems, database management systems, container platforms, cloud platform services and the like, and Servers and Nodes for physical and virtual hardware.
A straightforward approach to representing a server that is running an operating system and a database management system would be as follows:
A node containing multiple servers, hosting virtual machines each running a standard application server, can be modeled as follows:
However, it may be necessary to show how different technologies, running on the same node or server, may be supporting different applications or databases. With the above approach, any application supported by a node or server is assumed to be supported by all of the technologies deployed to that node or server. If there is a need to show how technologies running in one place relate to each other, and support applications or databases differently, these can be modeled as separate but connected services, using the Technology Service component type:
The above example shows how an application is running in Windows Server 2022 alongside an Oracle database, hosted on the same server in Oracle 19c. The increased complexity that follows from the introduction of two Technology Service components in the Server may be worthwhile since it allows us to understand the relationship between the Technology Service and the higher-level solutions they support. If a vulnerability was identified related to this particular version of Oracle, it would be easy to establish that the Data Store would be impacted, while the Application would not.
Get Started and Refine
The guidelines we’ve articulated are here to help you get started in modeling your application portfolio in Ardoq. Our approach is not the only way and may need adjusting based on the needs of your organization. However, our recommendation is based on our most successful customers is keeping it simple, using the recommended approach to get useful business value, and then refactoring using the flexibility of Ardoq. Architecture modeling is only as useful when it drives business decisions. Our advice is to understand the above, then get going and refine from real-world feedback. You’ll arrive at a place where you have confidence in your data, your analysis, and the decisions it drives.
Modeling Patterns
There are many different ways of modeling your applications and decomposing them into their constituent parts and knowing which way to model it can be challenging. For patterns and examples of how to model and decompose your applications please refer to the Application Modeling Examples presentation.