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 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 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 itself 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:

• A lot of 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.
• You as an architect give ideas to others that also 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 two web applications that are used to create this application landscape.

Architecture Repository

Visual Designer

An application landscape shows the logical and physical grouping, modularity, functionality, and technology of software applications and middleware applications. And sometimes also together with the databases they use, where which 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 the names of suppliers or products. Instead, you should 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 having an application landscape visualized, such as having 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 really is used, managed, and updated.
   6. Communicate you have been given the assignment 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 the ontology (the practical structure) of your application landscape. 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 also create an enterprise meta-model to relate your applications to products, processes, and hardware devices. But focusing on applications is most important 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 up a background collection process for the inventory of all current business rules and application architecture principles.
   7. Be sure to 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 in an ea tool repository. Sometimes you can export data from a CMDB tool to start with.
   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 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 providers 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 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. 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 tells 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 same shape!
   5. Always use a color scheme and font scheme and be sure to check out the company policy on logos, presentations, 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, 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.