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:

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:

Even with the best definition, there may be situations that pose a challenge. Examples we will cover in this article include:

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.

Before we get into the definitions and examples let’s cover some of the principles we will follow throughout this document:

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.

In the Ardoq metamodel we define an application as:

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.

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 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.

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.

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.

There are a few ways to represent a database in relation to an Application, Application Module, or Technology Service.

In the example above we have two applications that leverage a separate standalone DB and they do this through a connection to an interface.

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 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.

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

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.

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).

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.

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.

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.

This presentation has more examples and patterns on how to model applications.

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.

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.

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:

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.

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.

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.