Application

📘

These modeling guidelines are for the Meta Model v4. For Meta Model v3 guidelines, see modeling guidelines for the Meta Model v3.

Definition

Applications are software systems or programs that process or analyze business data to support business tasks, processes, or aspects of an organization's business model.

Description

Enterprise Architecture Management aims to align an organization's business and IT strategies, and applications are vital in enabling and delivering the functionality required to achieve business objectives.

Applications are designed to perform specific functions or tasks. These functions can vary widely depending on the organization's needs, including accounting, customer relationship management (CRM), enterprise resource planning (ERP), human resources management, supply chain management, etc. Applications generate and consume data and rely on IT components (software, hardware, services) to function. LeanIX's Meta Model is application-centric, linking business and IT.

Overview of all relations to/from Application:

Applications Examples: Workday, Confluence, Zoom, AutoCAD, LeanIX Enterprise Architecture

ERP systems (e.g., SAP S/4HANA) and other large systems like Salesforce are more complex and are explained in dedicated modeling guides. For more, see Modeling Best Practices.

Optional Application Fact Sheet subtypes

The following subtypes are not included in the predefined Meta Model per default but can be added on demand. For both of them, we strongly recommend maintaining Fact Sheets through automated integrations (see “Advanced: Model Microservices & Deployments below)

• Business Application: When using one of the below optional subtypes, there is a need for a clearly distinguishable separate subtype for the Applications serving the business task. It's recommended to add a distinct subtype for Business Applications and create a direct relation between Business Applications and other subtypes through a self-referencing relation. This relation will help to model how Microservices and Deployments indirectly support Business Capabilities through Business Applications. For more information, see Self-Referencing Relations.
• Deployment: Deployments represent multiple operational instances of an Application that serve the same business task but in varying environments or for varying purposes (e.g., a testing/staging environment).

❗️

Deployments do not count for pricing because they are representations of the same application and serve the same business task. We reserve the right to enforce the “fair-use policy”: Deployment Fact Sheets without a relation to a Business Application violate the fair-use policy. They must not have relations to Business Capability or Business Context Fact Sheets.

• Microservice: Microservices are individually deployable building blocks of a more extensive application, typically self-developed. They are relevant to Enterprise Architects, particularly in transformation projects – i.e., transitioning from a monolithic architecture to a microservices one.

❗️

• Microservice Fact Sheets do not count for pricing because they cover part of the functionality of one or more Business Applications. While it makes sense to group them (e.g. by Business Capability), LeanIX reserves the right to check for suspicious behavior according to our fair-use policy if the ratio of total Microservice Fact Sheets to Business Applications exceeds 10:1.
• LeanIX considers commercial and logical packaging of software (modules) as Applications and not Microservices, as these packages support different business tasks, even if they rely on a single Microservice

📘

For a step-by-step guide to create the Fact Sheet subtype, see Create Fact Sheet Subtype.

Guidelines and Best Practices

The list of Applications needs to be easily understood by everyone in the organization.

• Consider Commercial off-the-shelf applications (e.g., Oracle Financials, Anaplan), Open source applications (e.g., Jenkins, Drupal), and applications your organization has custom-built across both cloud and on-premise deployments.
• If a spreadsheet (XLS file) or Sharepoint application supports your business, it’s likely an Application.
• Make clever usage of tags: Aspects like hosting or PII can start as tags and evolve later.
• We strongly recommend starting with logical applications for maturing your EA practice, focusing on quick wins around Application Portfolio Assessment. For advanced EA practices, it might be relevant to also model deployments and microservices, which can be done with Fact Sheet subtypes not part of the predefined Meta Model per default.
• Use the SaaS catalog to model SaaS services and related IT Components and Providers, which will be relevant to realize scenarios and reports further down the road (see example below).

How to model SaaS services efficiently

Following the definition of an application, SaaS services should be modeled as Applications (plus IT Component plus Provider) in LeanIX since they are typically programs that process data and help organizations fulfill functional requirements. The best way to do it is to use the SaaS Catalog to automatically add a description and automatically create the related IT Component and Provider.

Suppose your organization's stack is built on a significant number of SaaS services. In that case, we strongly advise you to use the LeanIX SaaS Discover integration (at no additional cost) to pull your most important SaaS services (e.g., from your SSO or HRIS) in a fast, secure, and highly automated way into LeanIX Enterprise Architecture where they will be modeled as Applications. Once the integration is established, you can easily match identified SaaS services to Applications, have IT Components and Providers created if wanted/needed, and take over/adapt the pre-filled information. Read more about how to use SaaS Discovery here.

You can find a detailed example of how to model a SaaS Application (example of LeanIX Enterprise Architecture) in the General Modeling Guidelines.

📘

Modeling IT Components and Providers is almost no effort in LeanIX if you use the SaaS catalog and SaaS Discovery (it doesn’t cost you any additional effort). Even if you don’t need IT Components and Providers now, we clearly see a benefit of having them in your inventory for scenarios in which you need to manage more complicated setups. E.g., you might have a traditional self-hosted application, where the provider of the server might be different than the one of the server, or a SaaS application that relies on an SSO IT Component.

Remember that in LeanIX, you always need to model IT Components to get the link between an Application and the Provider. Having IT Components provides you with transparency of the hosting, allows you to create relevant Reporting (e.g., Provider Cost Report), and gives you data needed to manage risks better.

How to model different versions

Applications in your organization have most likely not a version, but there might be some exceptional cases where versioning becomes relevant (see examples below). LeanIX offers a “Release Field" out of the box, allowing one to model different versions of the same Application. The release field is included in the "full name" and "display name "attributes, making distinguishing different versions in reports and diagrams easier.

⚠️

SaaS Versions

Many modern SaaS products use a versioning scheme, but updates are deployed continuously without dedicated release timing (e.g., LeanIX uses semantic versioning internally, but it doesn’t make sense to represent the daily changes in LeanIX Enterprise Architecture). When versions are constantly changing and all users are running the same cloud-hosted latest version, the version numbers are irrelevant, and we don’t recommend maintaining them on Application Fact Sheets.

On the other hand, if a SaaS application is updated with new version via regular releases, then maintaining different versions is recommended (e.g., ServiceNow with cities names, as they release new versions named after cities every six months.)

How to model Application hierarchies (parent/child relation)

Business applications are often a system of various entities (typically called "modules" or "applications") based on a common ecosystem or platform delivered by a provider (e.g., ERP systems, CRM systems). The following example shows a hierarchy with Adobe Creative Cloud:

• Adobe Creative Cloud is a suite that bundles applications that help e.g., designers to produce visual content. It is modeled as the parent.
• The actual applications that support the achievement of specific tasks (e.g., Adobe Photoshop for image editing) are modeled as children.
• Adobe Creative Cloud could also be part of a Design Platform that contains other Applications that support other functions, e.g., video editing.

Internally developed software products vs. Products

The functionality of a software product developed by your organization is defined as an Application in LeanIX Enterprise Architecture. Suppose the software is offered as a commercial product, then it can be modeled as a business "Product" (Fact Sheet subtype under Business Context) in addition and related to the Application. In the LeanIX ecosystem, these self-developed software products would be captured in LeanIX VSM, and this information can be pulled into LeanIX Enterprise Architecture on an aggregated level via the LeanIX Enterprise Architecture-VSM integration. Check out this documentation to learn how to activate the integration between LeanIX Enterprise Architecture and VSM. The video below shows in more detail which information LeanIX VSM gets from LeanIX Enterprise Architecture and vice versa.

📘

Note that the main owners and users of VSM are Engineering Teams and that the LeanIX Enterprise Architecture-VSM integration depends on and fosters a good collaboration between the EA and the Engineering Teams in your organization.

How to model external Applications

There is often a need to model Applications in LeanIX that your organization does not own or directly support but has to interface with (e.g., Applications of business partners, service providers, authorities, etc.). In such situations, it is recommended to consider the following two approaches:

1. For a general view of such external Applications in your architecture, create a single composite Application Fact Sheet (e.g., “External Application”) to represent all external Applications. For analyzing dependencies and data flow in reports and diagrams, link other (internal) Applications to this representation through an Interface. Additionally, establish connections to other Fact Sheet types for standard modeling and reporting to illustrate how external applications are involved in the architecture.
2. When external applications are crucial to your architecture, make separate Fact Sheets for each. This allows you to use all of LeanIX's capabilities for detailed views and analysis. Even if you don’t own and manage those applications, they impact your architecture and business the same way as internal Applications. Therefore, they are treated similarly to internal Applications for application-based pricing.

Advanced: How to model deployments

Modeling instances or deployments is not a frequent use case, but if your organization needs to model such cases, the general recommendation to do so in LeanIX is to follow a light-weight approach and model relevant instances or deployments as IT Components (see modeling guidelines for IT Components).

There are two scenarios where we recommend modeling Deployments on the level of Applications by using the Deployment Fact Sheet subtype:

• In the case of an automatic import from a CMDB. Concretely, the ServiceNow CSDM best practice establishes that "Application Services" are mapped to Deployments in LeanIX.
• In case you want to track different technical dependencies & risks for the instances.
  We don't recommend manual maintenance, used typically only in conjunction with a CMDB like ServiceNow.

❗️

Deployments do not count for pricing because they are representations of the same application and serve the same business task. We reserve the right to enforce the “fair-use policy”: Deployment Fact Sheets without a relation to a Business Application violate the fair-use policy. They must not have relations to Business Capability or Business Context Fact Sheets.

Advanced: How to model microservices

We see an increasing need for companies that develop a lot of their in-house software to capture those parts of their landscape accurately. In this scenario, microservices can be captured as Applications in LeanIX to:

• allow the compilation of a low-level data flow based on APIs
• allow the distinguishing of logical building blocks (microservices) from used technology (IT components)
• allow the linking of microservices to a business application (an explicit relation will be created).

If your organization needs to model microservices, the way to do it in LeanIX is to model them as an Application in the optional Microservices Fact Sheet subtype. This allows you to leverage the full capability of creating views in LeanIX Diagrams and Reports (e.g., Interface Circle Map, where you would see the data flow between Microservices). We don't recommend manually maintaining microservices in LeanIX Enterprise Architecture, but automatically managing microservices in LeanIX VSM and aggregating insights into LeanIX Enterprise Architecture (check the video tutorial further down).

Our best practice recommends modeling down to a level of specific microservices that make up core parts of the relevant applications and the responsible teams developing those. This allows views specifically on the technical dependencies of the product architecture, which is, e.g., relevant for technical transformations (re-architecting a product-relevant application).

A starting point for this is shown below. In this example,

• 'B2B Website.com' and 'B2B MobileApps' are modeled as Business Applications (remember that you always model this Fact Sheet subtype and link Microservices to it to comply with our fair-use policy). In general, multiple Microservices can form/relate to an Application. This relationship is many-to-many, which is why an explicit relation is recommended (not: 'parent/child' or 'required').
• 'Core Iris', 'event-mirror', 'functional validation', 'Payment Service', and 'Checkout Service' are modeled as Microservices that support one of the Business Applications (for some of them, you can see which IT Components they are using).
• You can see that 'Payment Service' and 'Checkout Service' are used by 'Team CartCrafters' (modeled as Team - Fact Sheet subtype of Organization).

The next step after a basic mapping of which microservices support the applications can be to detail the relationship between microservices by mapping out the APIs (modeled as API Fact Sheet; subtype of Interface Fact Sheet and data flows that connect them:

This modeling adds a deeper level of data flow representation than the standard Interface Fact Sheet type by showcasing the flow between individual microservices. The example above shows the data flow between the microservices underlying the two displayed products, both between the microservices under the applications themselves and those connecting the two applications.

❗️

Microservice Fact Sheets do not count for pricing because they cover part of the functionality of one or more Business Applications. While it makes sense to group them (e.g. by Business Capability), we reserve the right to enforce the “fair-use policy”: The ratio of total Fact Sheets to Business Applications shall not exceed 10:1.

📘

In both cases, it’s good practice to introduce a subtype “Business Application” to distinguish Deployments & Microservices from your logical applications clearly. Please remember that modeling/updating those Fact Sheet types manually is not recommended since it would create a lot of extra maintenance work and downstream issues, such as needing to adjust bookmarks for reports, inventory, etc.

How to model costs in LeanIX

If you want to model costs in LeanIX, this can be done on the Application Fact Sheet in LeanIX, on the relation between the Application and IT Component (see Cost Management documentation page for more information).

Antipatterns

This section addresses antipatterns involving ineffective or counterproductive ways of modeling Applications in LeanIX.

• Application vs. IT Component: A common pitfall when using LeanIX is the clear delineation between the Application and IT Component.
  • Classical business applications like ERP systems are clearly Applications.
  • Operating systems, databases, and virtual machines are clearly IT Components.
  • Consider the software architecture: Classical applications use all layers (data, logic, and presentation layer), but there are also applications without a presentation layer. If your entity (unsure whether it is an IT Component or an Application) doesn’t have a data layer or a business logic layer, then it is likely an IT Component. If it accesses and provides data in certain business logic to other Applications and possibly business users, then it is probably best modeled as an Application.
  • System software, technology services, or hardware (e.g., operating systems, databases, run-time environments, laptops, desktop computers, and other devices) are not Applications; they are IT Components in LeanIX.
  • When the content of a spreadsheet serves a business task, then the spreadsheet itself (e.g., quoting tool, usage analytics) is the Application rather than the spreadsheet software (e.g., Excel), which is an IT Component of the type Software.
• In most cases, using versioning for Applications doesn’t add value and should only be done when it plays a role in your use case.
• A direct link between Applications and Providers (without the IT Component in the middle), which is possible to establish with LeanIX’s configurable Meta Model, might be tempting to save time in the data collection process. However, this shortcut of avoiding the modeling of IT Components will lead to significant limitations in the reporting in the midterm, e.g., no cost reporting and limited reporting/insights for obsolescence risk management (with the LeanIX Technology Risk and Compliance).
• LeanIX is not suited to model a live microservices landscape: it will quickly be comprised of many moving pieces, and maintaining it in detail can become difficult, especially if you try to do so manually. Tracking every microservice, software library, and other pieces of technical detail all of the time will add clutter to your EA landscape. If you model microservices, do it in an automated way (as mentioned above) and focus on relevant insights to generate insights for your business.

Applicable Use Cases

All LeanIX use cases: Applications are a must-have for any use case you do with LeanIX, usually starting with Application Portfolio Assessment. We recommend always having Applications in place together with Business Capabilities and Organization, as these are the Fact Sheet types that allow you to create reports with meaningful insights.

Insights from Application Fact Sheet

Since Applications touch every use case and everything is centered around Applications in LeanIX, most of the Reports and Insights you can gain will have some relation to Applications. Check out the Reports section to learn more about the different Reports. Some of the most prominent and popular ones are Application Portfolio Report, Application Landscape Report, Matrix Report, and Interface Circle Map.

Further Resources