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. NEW DEMO: You can create the (Process) Application Landscape via a JSON:API.
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.
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.
Dragon1 Web Applications To Create a Landscape
The Architecture Repository and the Visual Designer are the two web application on Dragon1 that are used to create this application landscape.
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 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.
“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:
- Think twice before creating an application landscape without an assignment (of the proper owner/client).
- 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.
- Show an example Application Landscape Diagram(see figure 3) to the owner/client (the CIO) you want to get an assignment from.
- State the benefits of having an application landscape visualized, such as having an overview, do effective application rationalization, moving to the cloud, deduplication, managing complexity or less misunderstandings with suppliers.
- Get an assignment from the owner/client (CIO) to create an AS-IS Application Landscape that afterwards really is used, managed and updated.
- Communicate you have been given the assignment to get sponsors and hands to help you.
- 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 front- mid and back office? Are there information systems groups of applications? Do information domains group applications across information systems? Do applications handle business objects? Etc..., Etc.. Yes or No?
- It is a best practice to write down and document on Dragon1 all the design decisions you make throughout the process.
- 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?
- 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.
- 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.
- 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. Startup a background collection process for the inventory of all current business rules and application architecture principles.
- Be sure to define every term you use on the application landscape. Create a glossary chapter or document for it.
- Data Collection - Filling up your user model
- Make interview rounds with business stakeholders, business and IT users and administrators of applications.
- 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.
- 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 contact, 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.
- Collect status information about the applications: do the comply to standard, criteria, business rules and application architecture principles?
- Creating a view - Setting a filter on the data in the model
- 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?
- 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.
- 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.
- 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:
- Management Overview (next to a detailed view)
- Application Modules Functions View
- Replaceable Application Modules View
- Loosely coupling view
- Dependency View (of Applications, Objects, Interfaces and Databases)
- Applications Reuse View
- Deduplication options of Applications, Modules and Functions View
- Obsolete & Outdated applications view (I often call this the dead tree view)
- Single Software Suppliers/Products Dependency view (where are we dependent of one supplier for solutions)
- Too Expensive Applications view
- Single Point of Failure (SPOF) view
- TCO View
- Ownership & Status view
- Software Update Maintenance view
- Users vs Licenses view
- Roles Access View
- Security Leaks view
- Architecture Principles View
- Open Standards vs Proprietary View
- Industry Standards Compliancy View
- Reference Architecture Compliancy View
- Applications Lifecycle View
- Project Impact View (With processes, applications and technical systems)
- Business functions View per domain
- Applications functions view per domain
- Technical details view vs Functional details view
- Impact of change view (insert or remove information systems, application groups/suites, applications, modules or application functions)
- Date time filter
- Organization specific AS-IS, Plateaus & TO-BE Views
- Single source of truth view of data & applications (overview of sources for certain business/information objects)
- Vendors / Supplier view
- Data dictionary view
- Application Service Management View *** - cases available on how to save costs
- Visualizing - Giving a graphical representation of the data in the view
- 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.
- 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?
- 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.
- 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!
- Always use a color scheme and font scheme and be sure to check out the company policy on logos, presentations and fonts and colors.
- 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.
- 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.
- 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.
- Have post-its ready when presenting the application landscape. And have two versions printed: one with and one without indicators, alerts and issues.
- Take the Architecture View Layout of Dragon1 (see figure 1).
- Administration, Usage and Management
- Write down policy for using, administration (updating) and management of the application landscape.
- Update the application landscape at least once every 3 months.
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 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, as an application manager, use application software to create a landscape overview, you can try different scenarios to solve problems.
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 a specialized EA tool like Dragon1 as EA Tool than with a generic tool or basic EA Tool like PowerPoint or Archi (Open Source).
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
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.
If you are interested in more examples of Landscape Diagrams you might also want to read:
- Visualizations > IT Landscape Diagram
- Visualizations > Process Landscape Diagram
- Tutorials > How To Create a Process Landscape Diagram
- Blogs > How to compile a list of applications?
- Images > Application Architecture Requirements Diagram
- Software > Dragon1 as EA Tool
- A Wikipage about Application lifecycle management
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.