HOW TO Create an Application Landscape Diagram

Why do you start creating Application Landscape Diagrams?

An Application Landscape (as printed A0-sized visualization or interactive overview) is an architecture product that should always be present in your EA baseline, even if outdated. 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 a static or interactive overview of the applications, you can do some effective deduplication.

Application Layer from the EA blueprint.

What is an Application Landscape?

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

Application Landscape Diagram.

The benefits of creating an Application Landscape are:

• Many roles in the organization (CIO, administrator, supplier, manager, architect) have much quicker access to information to make decisions.
• 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 an architect, show how well it works to visualize the whole of a complex system and then manage it instead of working with textual documents with partially inconsistent drawings.
• As an architect, you give ideas to others that could be visualized.
• If you, as an application manager, use application software to create a landscape overview, you can try different scenarios to solve problems.

Dragon1 Web Applications To Create a Landscape

The Architecture Repository and the Visual Designer are the web applications used to create this application landscape.

Architecture Repository

Visual Designer

An application landscape shows software and middleware applications' logical and physical grouping, modularity, functionality, and technology. Sometimes, they also work with the databases they use, where objects are handled and stored, the interfaces they communicate with, the locations and hardware/operating systems they are deployed on, and 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) wants 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. It would be best not to focus on the names of suppliers or products. Instead, it would be best to focus on 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 how well it is done. This step-by-step guide helps you.

How to Create an Application Landscape Diagram

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

1. Assignment
   1. Think twice before creating an application landscape without an assignment (of the proper owner/client).
   2. Make an inventory of current top priorities and top issues (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 visualizing an application landscape, such as an overview, effective application rationalization, moving to the cloud, deduplication, managing complexity, or fewer misunderstandings with suppliers.
   5. Get an assignment from the owner/client (CIO) to create an AS-IS Application Landscape that afterward is used, managed, and updated.
   6. Communicate that you have been assigned to get sponsors and hands to help you.

   

   Architecture View Layout.

2. Modeling
   1. In what application domains, application groups, and information systems do you want to structure your application landscape, or are these already there? Decide on a taxonomy (the theoretical structure) or re-engineer your application landscape's ontology (the practical structure). How are or can the applications be decomposed into components and modules, in your opinion, or according to industry reference architectures? Are applications groups of modules, services, or functionality? Do you recognize the front, mid, and back offices? Are there information systems groups of applications? Do information domains group applications across information systems? Do applications handle business objects? Yes or No?
   2. It is a best practice to write down and document on Dragon1 all the design decisions you make throughout the process.
   3. Define the sorts and types of entities that make up your application landscape: Do you work with core business applications vs non-core business applications vs supporting business and office applications? And are there data-source databases and replicated-data databases?
   4. 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.
   5. You could create an enterprise meta-model to relate your applications to products, processes, and hardware devices. However, focusing on applications is the most important thing now.
   6. Write down the business rules that should apply, such as: Every business process is supported by one core information system. Or: All financial functionality should come from ERP systems. Start a background collection process to inventory all current business rules and application architecture principles.
   7. Define every term you use on the application landscape. Create a glossary chapter or document for it.

   

   Application Landscape Meta Model.

3. Data Collection - Filling up your user model
   1. Make interview rounds with business stakeholders, business and IT users, and administrators of applications.
   2. Collect information about your applications in an Excel sheet or an ea tool repository. Sometimes, you can export data from a CMDB tool.
   3. Decide on the attributes or properties you want to administer per application. If you have many attributes, create attribute groups and decide which (groups of) attributes only certain people have access to. A common list of attributes of applications is: Unique identifier, Product name, Functional name, Technical name, Description, TCO, End of life, End of contract, Supplier contacts, Supplier contract, Service level contract, Number of user licenses, Age, Platform, Operating system, Version, Maintenance costs, Replacement costs, Owner, Main purpose/usage, List of features, Main users, Supported business processes, Application status, Inventory status, Application architecture, Administrator, Location, Interfaces, Main modules, Justification, Application family, Application data.
   4. Collect status information about the applications: do they comply with standards, criteria, business rules, and application architecture principles?

   

   Data Collection Excel Sheet.

4. Creating a View - Setting a filter on the data in the model
   1. Make the visualization's context and scope clear via the data set 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. 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 providers for groups of functionality, you should model and draw these. If you want to use the application diagram to standardize the types of interfaces or to improve working with a single source of truth, you will have to model and draw types of 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 include technical data, if you are making the application landscape for the COO 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 (we often call this the dead tree view)
   9. Single Software Suppliers/Products Dependency view (where are we dependent on 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

   

   Application Domains View example.

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 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 and 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 on each other?
   3. Choose an optical overall pattern layout for your application landscape and a pattern layout per domain or system. Examples of patterns are layers, bars, u-shapes, circles, random groups, and chaotic distribution. With a pattern, you immediately tell something. Just compare it with a landscape map of a city. That tells you if things are organized and what solutions are workable when solving specific 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 you have different symbol/color combinations for different technical and functional software applications. If you draw a garden, you do not draw all plants and trees in the same shape!
   5. Always use a color scheme and font scheme, and check out the company policy on logos, presentations, fonts, and colors.
   6. Know that objects 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 that an entity is there, a dotted line to indicate an entity was there, and 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 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.

   Usage

   When you have your application landscape, you can use color and lines, for instance, to indicate where and what applications are not compliant with the company standards and principles, 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 a specialized data visualization tool like Dragon1 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. Tutorials > How To Create a Process Landscape Diagram
   2. Solutions > Enterprise Architecture Solutions
   3. Resources > Application Architecture
   4. Software > Dragon1 as EA Tool
   5. A Wiki page about Application lifecycle management

   Get Started

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