Software Reuse: Why You Need a Well Managed Repository
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Impact analysis — the reasoned prediction of the impact of change — is a key function and critical success factor of your corporate reuse efforts. Without the ability to perform impact analysis, long-term reuse efforts could cause more problems than they solve. Effective impact analysis will allow you to steer clear of troubled waters, increasing both the viability and ROI potential of your reuse initiative. If you have a managed reuse process and a well-maintained corporate repository, gathering the information required to do impact analysis will be a simple but critical function of that effort. If you find yourself short on either count, impact analysis must still be done, though it will be noticeably more difficult.
Impact analysis is nothing new to the world of technology. Ask any seasoned network administrator what happens when a server goes down, and at a minimum he or she will recite a fail-over plan. If changes must be made to the server, the administrator will know what software systems are running on that server, as well as what other systems rely on it. Because the interdependencies are known, a risk analysis can be performed on the potentially effected systems. Once the risk is quantified, appropriate measures can be put in place to manage and mitigate the risks inherent in a server crash.
As with the server in the above example, impact analysis is required in order to manage the potential risks associated with the widespread use of reusable software assets. In order to do this, the software interdependencies must be mapped.
A reusable asset, much like a server, can be used by many other applications and processes. In addition, a reusable asset may also rely on other libraries to perform its function, or it may be indirectly tied to a backend database system. But while it's possible to trace server based interconnections by looking at cables, IP addresses and currently running processes, software related dependencies are not so obvious.
Some dependencies with hard bindings (like Java "import" statements) can be easy to spot, but dependencies with soft bindings — like the use of a web service though SOAP, or communicating with a mainframe though a messaging system — are far less obvious. Since it's conceivable that any given asset could be dependent on any another, creating a map of the possible nested dependencies is not necessarily an easy, nor a programmatic process.
For example, let's consider an application that retrieves account data from a mainframe. This application relies on a Java servlet component to perform the actual data retrieval. The servlet communicates with the mainframe through a CICS/Java gateway. Behind this gateway lies a COBOL transaction that actually pulls data from a secure database.
For the stated application to work, the servlet must perform. The servlet, in turn, relies on two things: the availability of the messaging system, and the stability of the copybook (which defines the structure of both the message to be sent and the message that will be returned). The copybook is derived from the COBOL procedure. For the COBOL procedure to run, the database must be up and accessible. If any one of these pieces changes, the entire process could cease to work!
An impact analysis of this application requires the mapping of its entire "ecology." By identifying the application's various interconnected, interdependent components, we'll learn that changes to the database table would ripple outward to affect the COBOL procedure, the copybook, the messaging system, the servlet, and the application.
It's important to note that within the scope of a single project, changes to dependencies happen all the time. In organizations with a mature change process, these dependency changes are usually smooth and successful. But when dealing with reused assets and multiple projects, things can get bit tricky.
Since a reusable asset is by definition used in multiple projects, "single project" change management processes can quickly break down. The first break revolves around the assumption that the change management process implicitly knows which project the change is affecting. The second break revolves around the idea that most change management processes assume that team members of the affected project are available to assist with the change. Since reused assets typically sit outside of a given project or application, these assumptions are faulty. This points out how critical it is to identify not only what might be affected, but whom.
While all this may seem a bit daunting, the good news is that a well-managed reuse repository makes quick work of identifying the dependencies necessary for effective impact analysis. Your reuse repository manager should be keeping track not only of all assets in the repository, but also their cross-language and cross-artifact dependencies, as well as tracking which applications are using which assets.
This is not as difficult as it sounds. Most reuse-focused repositories limit their content to only those assets that are designed for corporate-wide reuse. Specifications for all new assets to be added to the repository should require a list of all dependencies. It's important also to insure that your dependency registration is not limited to only code level assets. It should include anything that, when changed, could effect the asset.
It's useful as well to take a proactive approach when tracking which assets are used in which applications. For instance, it pays to be aware of assets that are under consideration for inclusion in an application. This kind of early warning can go a long way toward keeping your dependency data up to date.
With theses measures in place, learning the impact of changes to a particular asset then requires little more than running a query to reveal all direct and indirect dependencies, and then contacting the appropriate parties.
By managing asset and application dependencies through a well-managed repository, you're working smarter, and you're further improving the long-term benefits of reuse for your organization. But if your reuse department doesn't have a repository, or if there is no organized, managed reuse department, then any change to a shared resource is like a shot in the dark. If that's the case, be afraid. Be very afraid.