Question: How do we avoid application duplication?
I read your column about the value of time reporting. I thought you would be interested in a situation at my company. I am working on a team to develop a Web-based time reporting package. It does not have a lot of bells and whistles, but it allows for all of the time reporting cases we have in our organization. We just found out a couple days ago that another department in our company already had a time reporting application. In the ensuing discussions, it turns out that one of our field locations is also doing time reporting using a third-party package.
What a waste! What are other companies doing to keep from developing applications that they have already built somewhere else? - Armando
Answer: Document existing solutions
Armando, you might be surprised how many times this situation comes up. On the surface, it would appear that building duplicate applications just boils down to a lack of communication. In fact, that may well be the case. However, there is at least one good reason why a company ends up in the position you describe.
Good and bad reasons for redundancy
The most obvious, and legitimate, reason for application duplication comes through mergers and acquisitions. When the new company realizes that it has duplicate applications, it sometimes leaves them in place since they work fine and the cost of merging the systems can be astronomical. For example, as mergers have occurred in the telecommunications field, many of these companies have struggled to merge complex and highly customized billing systems.
A second reason, but much less forgivable, is the decision making process that takes place in decentralized organizations. Since these types of companies make most of their business decisions on their own and, in many cases, are held to their own profit/loss numbers, they may see themselves as unique companies that need to have their own application solutions. In the past, this was a very common way of thinking. Large corporations, with many autonomous companies, might literally have dozens of similar business applications.
The third reason is just a plain lack of communication. Some companies and managers simply do not have a sense for the value of reuse. When an application solution is needed, they don’t think to ask whether the solution has already been developed by another sector of the company. If there are no companywide processes in place, they can easily reinvent the wheel.
Think application architecture
So, what can your organization do to remedy the situation? Your company needs to start thinking of business processes and business applications in terms of application architecture. Many people don’t like the term architecture because it conjures up images of specialists and overhead and wasted time. However, that outcome just isn't the case.
At the most basic level, you can think of application architecture as an inventory and a process for managing and leveraging the inventory to make good business decisions. In fact, if you had a complete inventory of each application in your company, along with what it did, who the customer was, the technologies involved, etc., you would have the basis for an application architecture. For a small- to medium-size organization, this strategy doesn't sound too bad. For large corporations, this process of simply identifying all applications can be a major project in itself. However, no matter what you do, you must take the inventory, and have some ongoing process to keep it up-to-date.
There are a few additional things you need in order to put an architecture structure into place. You need to go through an exercise of determining the major business processes and subprocesses throughout your company. Again, you might be surprised how much time and effort are required to put this together in a manner in which people can agree. Once the business process structure is put together, you need to map all of the applications that currently exist against those business processes.
The third process you need is a way to map requests for new projects against the current business processes and business applications. You can do this as part of the project approval process at your company. When business clients are looking to new solutions, they can refer to the application architecture to see if something similar exists. The people making funding decisions can also see the new projects, what business processes they relate to, and what applications already exist. They can catch obvious duplications and ensure that redundant applications are not funded.
I am not sure what the origin of the application redundancy is for the time reporting application at Armando's company. I would venture to say that the enterprise probably doesn’t have an application architecture process in place so people can see what business applications already exist. In fact, the company may still have a culture of “not invented here,” and the people involved in proposing and approving the time reporting application probably did not even think to see what other solutions were in place.
Take an architecture approach
As companies get larger, it becomes more and more critical to take an architecture approach to business applications. To get there, you need to: understand the major business processes of your company, take an inventory of all current applications, and map the business processes each application engages. Then, you need to raise visibility of this information and make it a part of the decision making process. There may still be a number of reasons why similar features and functions are duplicated; however, those decisions should be made consciously, with a full understanding of the costs and consequences. Without the application architecture, these decisions are made blindly, and there is no telling how much money is wasted as a result.