Stop looking for your application owners
Are you involved in a project where you are deciding the future of your Notes/Domino applications and looking for application owners? If so, you know it’s a daunting task where the decision you make will have repercussions for your entire organization.
It can seem impossible to find the information you need to make fact-based decisions. For most organizations, the number of applications in the Notes environment is huge, having grown over years or even decades. As business structures and processes change, apps that were important 10 years ago, might not be relevant anymore. The original application users have moved on. It’s often impossible to know who originally commissioned a given application and who, if anyone, is currently using it.
Many project managers in this situation try to find the application owners. The logic being these are the people or departments who know the application. They should be able to decide the future of their applications. As owners, they might also be allocated any project development costs associated with processing them. Unfortunately, application owners can be hard to find, and they’re often not much use when you do.
In part #4 of our series we want to explore a better way to help you make decisions.
Owners are hard to find and probably can’t help you
How do you find them your application owners? What if that department doesn’t exist anymore, or the original owner has left the organization?
Even if you can find the name of the person or department who originally commissioned the application in some ancient records, you don’t have a guarantee that will solve your problem. Business processes may have changed. That department might not use the application anymore, but a different one does.
Who are your application stakeholders?
Application stakeholders are the people who currently use and derive a benefit from an application. If you can answer the following questions, you’ll know who they are:
- Who are the main users?
- To which departments do they belong?
- Where are they located?
- Who creates content in the application these days?
- Who’s consuming that content?
The answers to these questions are far more powerful than knowing the name of a department head or developer from 10 years ago.
Once you know your stakeholders, you’ll also know:
- Who will be impacted by any changes you make to an application?
- How will they be affected?
- Who should you consult before you start making changes?
- Who is receiving the benefit of the work you are doing?
Strengths and weaknesses of traditional approaches
Here are four potential sources for finding your application stakeholders. Each has advantages and disadvantages.
- Database ACL
This is often the first place many companies look. It has the advantage of being consistently available for all applications without additional configuration or software installation. In addition, the data from ACLs is relatively easy to gather and process. Unfortunately, there are numerous disadvantages that can lead to faulty assumptions. There’s the risk the ACL contains outdated information. Just having access rights doesn’t imply actual usage. Knowing why someone is in an ACL is rarely available. The simplicity of use is outweighed by the superficiality of the information it provides. - Custom database inventory
Many companies have built their own applications to collect and maintain information on databases, owners, cost centers, etc. If well maintained, these can provide easy access to very useful information for you. However, if not well maintained, information may be outdated or incorrect. If you are fortunate enough to have access to such an inventory, how do you know if the information it contains is accurate? Again, you face the risk of using faulty data for critical decision making. - Content metadata
Document metadata records are another possible source of information. Fields like “last modified by” can be very revealing when deciding on who are stakeholders or content creators.
Although these fields are dependable sources of accurate information, they are hard to collect and combine across multiple replicas. They’re also limited to revealing only the editors. Notes doesn’t store the last reader. You won’t have an accurate picture of all the beneficiaries of the application. Without this information, you cannot understand the full potential impact of your decision making. - User activity
Finally, you can look at gathering usage from various sources like log.nsf or user activity logged by the database itself. If collected for an adequate time period, the quality of the data is high, and it is based off actual user activity. You can also distinguish between Read/Write activity and differentiate between Notes Client and web usage. This allows you to make the best possible decisions, because you will have a very good idea who are content creators and consumers and how they use the application. However, information is not trivial to collect and combine across multiple replicas. The barrier is substantially lower than the one for gathering content metadata, though. Thus, we see user activity as the most promising data source. It’s a good compromise between the quality of the information you receive and the effort you have to invest into gathering it.
A better way to find your stakeholders
When working with data from usage-based sources like user activity and content metadata, there are a number of KPIs that are available. Not all of them apply to every data source, but in general they are very helpful if you want to make decisions based off numbers. So, take what’s available from the source you pick.
When looking at document Reads/Writes, you easily get a quick activity overview. You can differentiate between content creators and consumers. These are the people who understand the value of the application to the business. They are the ones who will be affected by any decisions you make, and you would be wise to consult them before forming an opinion. Additionally, understanding who derives the benefit from an application allows you to assign project costs accordingly.
Also, take a look at the sessions/transactions to understand the impact your decisions will have on server load. This will have a direct impact on your consolidation potential, which we discussed in chapter #3 of this series.
In addition to knowing who is using an application, it is important to understand how many people are using an application. This is particularly true if you can track usage over a period of time. Is the application becoming more or less popular? Is it only used once a year but to do something that is business critical? Which departments are proportionally consuming the application the most?
Stakeholders give you better outcomes
Once the data has been gathered and the calculations are done, it’s time to put that information to work for you.
Knowing your stakeholders and their application usage patterns allows you to identify the business units you need to speak with about the future of each application. They can tell you the value an application brings to a business. They will know the impact a change to that application will have on their ability to carry out their duties.
You will also be able to apportion and discuss the project costs the business units will incur for the applications they are using. They will be able to make an informed decision whether an application generates enough value to justify the expense of maintaining it. You will have a logical, evidence-based method to explain why departments will be assigned costs and how those costs are allocated according to the benefit received from them.
Involving application users in the decision-making process will ensure the needs of the business are being fully considered and incorporated into your project. The project will be more efficient. Outcomes will be better and relevant business units will be have bought into the necessity and logic used for determining the future of their applications.
Next in our series
Most of your applications will have dependencies on one part of your environment or the other. Many of those will be rooted in the code itself: hard-coded server or usernames, IP addresses, external libraries, fax systems, etc. We need to know where these dependencies are, what impact they have and how they can be fixed in the most efficient manner, without having to re-engineer hundreds or thousands of designs.
Progress reports. They’re a part of every project and they’re not fun to produce. It’s not just your progress you have to share. You must also supply the project teams with the data they need to do their job. It’s tough to coordinate and it never ends. But progress reports can be your friend when you’re reporting success!
From here on out it will be a continuous widening of the circle of applications we are working on. Each step will be more cost intensive, and prudent planning will yield ever greater benefits.
Many companies around the world have been committed to HCL Notes/Domino* for years. They know the many benefits that come from that relationship. Additionally, Notes/Domino lies at the center of their processes and how they work. Despite all this, IT decisions makers around the world are starting to envision a future where Notes/Domino may play a reduced role or no role at all.
*formerly IBM Notes/Domino
