How to Create an Application Landscape Diagram

Create animated Application Landscape diagrams yourself starting with a free Trial Account here. Take a peek at the tutorial Interactive Application Landscape.

Why do you start creating Application Landscape Diagrams?

An Application Landscape (as printed A0-sized poster or interactive overview) is an architecture product that always should be present in your EA baseline, even if it is out of date. To have something is better than to have nothing, because it always saves time and thus money searching for certain application interdependencies.

And of course with an static or interactive overview of the applications you can do some effective deduplication.


Dragon1 Application Landscape Diagram
Click on the image to view an example EA blueprint with the application layer

What is an Application Landscape?

An application landscape itself is a coherent set of interconnected applications often within an enterprise, business or organization. An application landscape diagram or also called system landscape and system architecture diagram is the visualization of an application landscape.

Click here to watch, share or embed this visualization

The Architecture Repository and the Visual Designer of Dragon1 EA Tool are the applications that are used to create this application landscape.

Architecture Repository

Visual Designer

An application landscape shows the logical and physical modularity, functionality and technology of software applications and middleware applications. And sometimes also together with the databases they use, where what objects are handled and stored, the interfaces they communicate with, the locations and hardware/operating systems they are deployed on, but also the users and processes they support.

There is no sharp line to say what should or should not be on an application landscape. It is more a matter of what the viewer (stakeholder) is interested to see or look at. If you look at a mountain landscape, houses and people might be there, but you do not see them because you are not looking at them.

You will accomplish a lot with an application landscape, depending on what information about the applications you provide. You should not focus on names of suppliers or products. Instead you should focus on the process ownership, IT costs, business benefits, functionality, modularity, technology, interfacing standards, data exchange formats and versions. 

Do not worry if you have only 20 software applications or 2000 software applications. They always fit onto an A0 sized Application Landscape Diagram. It depends on you how well it is done. This step by step guide helps you.

Dragon1 Application Landscape Diagram

“Do you want to earn time & money by eliminating duplicate functionality and obsolete applications?”

HOW TO Create an Application Landscape Diagram

An overview of the steps to take how to create an Application Landscape Diagram is here below:


Click to enlarge the Dragon1 Architecture View Layout
  1. Assignment
    1. Think twice before creating an application landscape without an assignment (of the proper owner/client).
    2. Make an inventory of current problems with applications together with their users. Verify if applications to them are only software or maybe also hardware.
    3. Show an example Application Landscape Diagram(see figure 3) to the owner/client (the CIO) you want to get an assignment from.
    4. State the benefits of having an application landscape visualized, such as effective application rationalization, managing complexity or less misunderstandings with suppliers.
    5. Get an assignment from the owner/client (CIO) to create an AS-IS Application Landscape that afterwards really is used, managed and updated.
    6. Communicate you have been given the assignment to get sponsors and hands to help you.


    Click to enlarge the Dragon1 App. Meta model Example
  2. Modeling
    1. Decide on a taxonomy (the theoretical structure) or re-engineer the ontology (the practical structure) of your software applications: How are applications decomposed in your opinion or according to the industry reference architecture? Are applications groups of modules, services or functionality? Are information systems groups of applications? Do information domains group applications across information systems? Do applications handle business objects? Etc..., Etc.. Yes or No?
    2. Define the sorts and types of entities: Are the core business applications vs non core business applications vs supporting business and office applications? And are there data-source databases and replicated-data databases?
    3. Create an application meta model (what entity classes are you going to use? Using a modeling language and the taxonomy or ontology in the step before.
    4. You could also create an enterprise meta model to relate your applications to products, processes and hardware devices. But focus on applications is important now.
    5. Write down the business rules that should apply: such as: Every business processes is support by one core information system. Or: All financial functionality should come from ERP systems. Startup a background collection process for the inventory of all current business rules and application architecture principles.
    6. Be sure to define every term you use on the application landscape.


    Click to enlarge Example Data Collection
  3. Data Collection - Filling up your user model
    1. Make interview rounds with users and administrators of applications.
    2. Collect information about your applications in an excel sheet or in an ea tool repository. Sometimes you can export data from a cmdb tool to start with.
    3. When collecting information about applications, at least use the following attributes: unique identifier, calling name, product name, functional name, application platform, operating system, supplier name, version, list of functionality, list of objects handled, list of interfaces, cost, number of user licenses, age.
    4. Collect status information about the applications: do the comply to standard, criteria, business rules and application architecture principles?

  4. Creating a view - Setting a filter on the data in the model
    1. Make the context and scope clear on the visualization via the set of data you show. Include data of the organization and its business units in the view, resulting in a picture in the background to project the application landscape on. Is the landscape created because of rationalization purposes or some other reason? Are we showing the whole company or just a business unit?
    2. If you regard applications as service provider for groups of functionality, you should model and draw these. If you want to use the application diagram to standardize on types of interfaces or to improve working with a single source of truth, you will have to model and draw types interfaces and what source data is stored and handled where.
    3. It is a best practice to collect more information (in detail and attributes) than you will show. This enables you for instance to report consolidated data and verify data.
    4. If you are making the application landscape for the CFO, be sure to include financial data, if you are making the application landscape for the CIO be sure to include technology data, if you are making the application landscape for the COO be sure to include processes and business continuity information.

    Common Dragon1 Application Landscape views are:

    1. Management Overview (next to a detailed view)
    2. Application Modules Functions View
    3. Replaceable Application Modules View
    4. Loosely coupling view
    5. Dependency View (of Applications, Objects, Interfaces and Databases)
    6. Applications Reuse View
    7. Deduplication options of Applications, Modules and Functions View
    8. Obsolete & Outdated applications view (I often call this the dead tree view)
    9. Single Software Suppliers/Products Dependency view (where are we dependent of one supplier for solutions)
    10. Too Expensive Applications view
    11. Single Point of Failure (SPOF) view
    12. TCO View
    13. Ownership & Status view
    14. Software Update Maintenance view
    15. Users vs Licenses view
    16. Roles Access View
    17. Security Leaks view
    18. Architecture Principles View
    19. Open Standards vs Proprietary View
    20. Industry Standards Compliancy View
    21. Reference Architecture Compliancy View
    22. Applications Lifecycle View
    23. Project Impact View (With processes, applications and technical systems)
    24. Business functions View per domain
    25. Applications functions view per domain
    26. Technical details view vs Functional details view
    27. Impact of change view (insert or remove information systems, application groups/suites, applications, modules or application functions)
    28. Date time filter
    29. Organization specific AS-IS, Plateaus & TO-BE Views
    30. Single source of truth view of data & applications (overview of sources for certain business/information objects)
    31. Vendors / Supplier view
    32. Data dictionary view
    33. Application Service Management View *** - cases available on how to save costs

    Click to enlarge Example Application Domains View
  5. Visualizing - Giving a graphical representation of the data in the view
    1. Your application diagram should be in a version with and without issues and indicators. The one with is used for strategic decision making. The clean one is used for showing off.
    2. Draw a domain view (see figure 2) of your application landscape. Link owners, managers, users and administrators to the domains. Define and write down the scope and context of the domains, how they are or should be managed. You work mainly with domains to decomplex the landscape. Write down carefully how these domains interact. How dependent are they to each other?
    3. Choose an optical overall pattern layout for your application landscape and a pattern layout per domain or system. Example patterns are layers, bars, u-shapes, circles, random groups or chaotic distribution. With a pattern you immediately tell something. Just compare it with a landscape map of a city. That tell you if things are organized or not and what solutions are workable when solving certain problems. This goes also for your application landscape. You can have a domain with applications point to point with one central core application. And in other domains you may work with a service bus.
    4. Make sure that you have different symbol/color combinations for different types of technical and functional software applications. If you draw a garden you do not draw all plants and trees in the shame shape!
    5. Always use a color scheme and font scheme and be sure to check out the company policy on logos, presentations and fonts and colors.
    6. Know that objects that are placed close to each other will seem to belong to each other. Work with repetition, rhythm and proportionality to create the desired optical effects.
    7. In Dragon1 we use a solid line to indicate currently an entity is there, a dotted line to indicate an entity was there, a dashed line to indicate an entity will be there in the future.
    8. A successful application diagram contains a lot of information the owner/client knows and likes to see and does not know and does not like to see (because of the situation), making him to take action immediately.
  6. Presenting
    1. Have post-its ready when presenting the application landscape. And have two versions printed: one with and one without indicators, alerts and issues.
    2. Take the Architecture View Layout of Dragon1 (see figure 1).

  7. Administration, Usage and Management
    1. Write down policy for using, administration (updating) and management of the application landscape.
    2. Update the application landscape at least once every 3 months.

The benefits


Click to enlarge the Dutch Live Example

The benefits of creating an Application Landscape are:

  • A lot of roles in the organization (CIO, administrator, supplier, manager, architect) has much quicker access to information to take decisions on.
  • A visualization of an application is much more objective and easier to understand (harder to misunderstand) than a textual version.
  • The impact of change can be visualized on the drawing table before you do it in practice. Showstoppers can be eliminated.
  • You as architect show how well it works to visualize the whole of a complex system and then manage with it, instead of working with textual documents with partial inconsistent drawings.
  • You as architect give ideas to others what also could be visualized.
  • If you use a tool to create a landscape overview, you can try different scenarios to solve problems.

Usage

When you have your application landscape you can use color and lines for instance to indicate where and what applications are not compliant to the company standards and principles, or what interfacing goes wrong or what business objective cannot be realized because of a certain situation.

You can also gray-out the application landscape and only colorize the items in scope for a certain project or situation. Of course this is all much easier to do with an specialized EA tool like Dragon1 as EA Tool than with a generic tool or basic EA Tool like PowerPoint or Archi (Open Source).

Extra

Every application landscape implicitly has a meta model. That meta model at least contains the following entity classes:

  • software application
  • information system
  • application domain
  • application suite
  • application services
  • application modules
  • application components
  • application objects
  • application functionality
  • interfacing standards
  • application selection criteria
  • application architecture diagram
  • application architecture principles
  • life cycles
  • location
  • environments

Everything in the application landscape needs to be uniquely identifiable. But it is important to work with a pure (meaningless) key, such as #PART0001 to #PART9999.

Also Read

If you are interested in more examples of Landscape Diagrams you might also want to read:

  1. Examples > IT Landscape Diagram
  2. Examples > Process Landscape Diagram
  3. Tutorials > How To Create a Process Landscape Diagram
  4. Blogs > How to compile a list of applications?
  5. Images > Application Architecture Requirements Diagram
  6. Software > Dragon1 as EA Tool
  7. A Wikipage about Application lifecycle management

Getting Started

Do you want to start immediately? You can purchase your Dragon1 PRO user license here online via Paypal.

If you do not have the time and you need an Application Landscape on short notice, we can create a Landscape for you.