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 application components, can impact your analysis and ultimately your ability to answer key business questions. It is 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 adding 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:

The three component types that are most commonly used in modeling applications are Application, Application Module, and Technology Service. 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:

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 is a child component of an Application component. Application Modules that directly support other applications will almost always have their own interface(s).

Note: Earlier versions of the Ardoq metamodel also included an Application Group component type which was used for large software packages of separate applications e.g. Microsoft Office Suite. This component type has now been removed and is not recommended because it complicates application modeling and creates issues within the metamodel. If needed, larger software packages such as MS Office should be modeled as parent applications.

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, Data Store 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. If the component would be recognized by business users as a business system in its own right, it would usually be represented with an Application component.

There is a occasionally some overlap between a technology service and an application. 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.

If you’re still unsure which component type to use the considerations below may be helpful:

If you need to perform business analysis such as cost roll-ups or rationalization then it is recommended to use the Application component type as the Ardoq Solutions 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 or parts of applications. Again, this can be harder to decide than you’d expect. Nonetheless, it is 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) are often referred to as Applications in their own right by 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.

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, as well 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 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 deployments of those technologies, as there may be multiple deployments for each technology product, each of which may have its own associated data. So the operational deployments are modeled as individual components 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.

When mapping from ServiceNow it is recommended to create an additional component type, Application Instance, to accommodate the concept of the Service Instance (or Application Service prior to CSDM 5.0). This concept exists within the Common Service Data Model (CSDM) to group configuration items associated with different service instances of an application e.g. Development environment, Test environment, and Production environment. This relationship is natively managed within Ardoq as a feature of the relationship between an Application and its supporting Technology Services. In order to simplify the integration with ServiceNow it is recommended that this new component type is added within a separate workspace to support seamless data transfer between ServiceNow and Ardoq. An example of the component mapping for ServiceNow is shown below:

For full details on how to implement the Ardoq to CSDM mapping please refer to How to map from the ServiceNow CSDM to Ardoq Solutions.

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.