You can build application mapping by a series of smaller tasks. Begin by determining the breadth of scope. Next, identify the applications. Then, gather the facts. And last, follow-up on the loose ends.
This blog does not cover why one would do Application Mapping or, as DCMWORKS calls it, Application Finger Printing (AFP). That was covered in a previous blog by a colleague: click here.
Scope for Application Mapping
If you are the CIO, or own all data center operations, or are the person championing the effort, you can go enterprise wide. Otherwise, determine scope limits based on what is within your of authority. You will need authority to bring in various disciplines with some contribution from application support, business units, database administration, networking, physical and virtual equipment management, storage, and some other specialties. If staff members in those areas are not available, you can still create an application map but it may have some “black boxes.”
Get Application Mapping Organized
You need to know where to begin. This means making or getting a list of applications and who can see that the information is provided about each one. Now consider who (the position) can provide information about applications. Depending on governance in your organization, it may be someone in the business unit that uses the application, or it may be someone in IT who manages the relationship with the business unit or the application itself. That person is the application “owner.” If varying positions manage various applications or relationships, there is a risk of orphaned equipment or applications. It is important that you identify a single owner for each application. Share your list(s) with owners and get their corrections.
Make a list of the people from each discipline who will serve as liaison from the application mapping effort to the discipline. This is your Oversight Committee.
Gather Facts for Application Mapping
Diagrams are useful, but application owners may need assistance creating them. Usually a half dozen templates will be a sufficient start, but about 10% will need custom work. A diagram should show how equipment used by the application is connected and how data is received or delivered by the application.
Remember to include the hosting clusters for virtual equipment, and to include development in DR environments. For example, a sales application may receive new customer information from one application and it may deliver charges to another application and inventory changes to another application. Our application may have a front end server that passes transactions to a database server which connects to a storage array. For another example, an application may be externally hosted so that only internal connectivity is relevant.
In addition to a diagram, there are other data important to understanding each application. In addition to the owner, business unit, and diagram, some other data DCMWORKS routinely collects are:
- A short sentence describing the general purpose.
- A copy of the application test plan.
- Application criticality, RTO, and RPO classification.
- Whether DR exists and has been tested.
- Database and storage types and quantities.
- Network rules and LAN/WAN connections.
- Services required (such as FTP, VPN, Citrix, etc.)
- Application version and support information.
- Such other facts as may be relevant to your enterprise.
As this information is gathered, there should be a coordinator who is keeping track of how complete each application’s information is. As each application is nearing completion, the relevant team (owner, administrator, end user, network, storage, DBA, etc…) should share the information gathered and sign off on it.
Follow-Up On Loose Ends
You should also get physical and virtual equipment inventories and identify the application that each item supports. (In some cases, the equipment will support a service. Some enterprises keep a separate list of services, while others include them as applications.)
As information is gathered on applications, cross reference other applications that receive/deliver data with them.
It is not unusual to discover that different teams refer to the same application or equipment by different names. It is allowable have such aliases, as long as there is a single unique official name and that the aliases are known to other teams.
If you cannot keep your application mapping current by including it in your Change Management process, then schedule regular reviews to keep it current.
It is common in the application mapping process to discover “new” applications. It is not unusual to discover orphaned equipment in the application mapping process, but those savings are not sufficient to justify the effort of the process.
The benefit of application mapping is identifying risks to the enterprise.
Often complex interdependencies can be discovered in Application Mapping and simplified before they cause problems. For example, an enterprise may have database or storage resources that are shared by applications in differing disaster recovery tiers that would complicate recoveries.
Your Application Mapping is not only important to day-to-day decisions; it is vital to emergency recoveries or migrations when regular staff may not be involved. Keep a copy of your Application Mapping information where it would be available in the event your main data center is not.
DCMWORKS has several tools that assist in the Application Mapping or, as we call it, the Application Finger Printing (AFP) process.