|
Commercial off-the-shelf installations are more common than you'd think
January 09, 2009
URL:http://www.drdobbs.com/tools/agile-package-implementations/212701603
Scott is Practice Leader Agile Development for IBM Rational.
Whenever you read about agility, 99 times out of 100 it is about new software development. Among those rare writings that look beyond software development, perhaps 1 out of 100 describe how to take an agile approach to package implementations. This is truly unfortunate because package implementations, often referred to as 'commercial off-the-shelf' (COTS) installations, are common in practice. Capers Jones, in Applied Software Measurement, Third Edition estimates that in Fortune 500 organizations, COTS packages account for 35 percent of their total software, for close to 50 percent in medium-sized organizations, and upwards to 100 percent in organizations of less than 100 people. The question then becomes, how can you apply agile strategies to package implementations?
Figure 1 depicts a lifecycle for package implementation, using the terminology of the Unified Process to help you to break out of the serial waterfall thinking that is predominant amongst package implementation methodologists. On the surface the process appears to be serial, but that doesn't mean that your approach can't be agile.
Package implementation projects have the potential for significant bureaucracy -- the desire to make a perfect decision, instead of accepting the fact that what you really need is a good enough decision, motivates management to require onerous levels of bureaucracy that do little more than increase overall project risk. The agile strategy is to focus on high-value activities, to do just enough work to address the goals and to avoid needless documentation and reviews. The most important thing that you can do is to put together a team of competent people who can be trusted to get the job done, and if that's not a viable option for you, then my best advice is to stop the effort right now until you're able to do that.
At the start of any project, you must choose the right process for the situation you find yourself in. First, make a buy-versus-build decision, and if you want to buy then recognize that you must change your business processes to reflect those of the package you select. Capers Jones reports that if you need to modify more than 25 percent of the system, then it would be cheaper to build a specific system in the long run. He also recommends that you should really avoid modifying more than 15 percent of a package, and that if the vendor is hostile to supporting you if you do modify the package, then his recommendation drops to 5 percent. Second, choose an initial version of your process and the tailor it accordingly. For example, you're likely to follow a different process for a $500 package than for a $500,000 package -- one process size does not fit all.
Assuming that you've decided to buy, the next question you need to ask yourself is whether the package has already been selected. Ideally, all package purchases should be based on technical, financial, and operational merits, but in reality such decisions are often political in nature. When this is the case, there is little value in evaluating candidate packages. This is true even if your goal is to produce the documentation to make it look as if you've followed the process to reach the decision that you've already made -- this is not only blatantly wasteful, it is ethically questionable.
If you really are in a position to select from several options, then you need to base that selection on requirements. This doesn't mean that you need a detailed requirements specification, but it does mean that you'll need more than a collection of user stories written on index cards. It's the need to make an informed decision based on requirements that lead many organizations to believe that you can't do agile package implementations, but nothing could be further from the truth. The agile approach is to recognize that you need a requirements specification and you should therefore do just enough work to fulfill this need. So, you don't need a 50-page specification but you likely do need a five to 10 page spec.
In addition to understanding your business requirements, here are some additional considerations for your requirements specification:
Once your requirements are in place, you need to identify potential packages. The first step is to do some research online to identify candidates. For larger packages you'll send out a request for information (RFI) to vendors and ask them to rate their packages against your defined requirements, a step that potentially adds calendar time but could reduce your overall cost. Many organizations want to have at least three packages to choose from but sometimes that's not realistic. In many situations, there are only one or two viable contenders (if you're lucky). Adding packages to your list that really aren't viable not only wastes your time, it also wastes the vendor's time.
Once you've gathered information about the candidate packages, the next step is to analyze and then rank your options. This is where many organizations get into trouble because they desperately want to make a perfect decision. The reality is that your choice doesn't need to be perfect, it just needs to be good enough--perfect decisions can be time consuming and expensive to make, whereas good enough decisions are quicker and much less expensive. Say for example you spend three months comparing five potential packages and decide on package C. You purchase C and then two months later a new version of package A is released that is now slightly better than C. Disaster has struck because your decision is no longer perfect! This sort of one-upmanship between competitors happens continuously, so don't get caught in a decision-making spiral.
An important observation is that by the time you've analyzed your viable options, you pretty much know which package is the most likely to meet your needs the best. So, instead of investing time and money in doing a 'bake off' between all of the packages, you should instead choose the best option available to you and focus on proving that it meets your needs. This strategy works because if one package is by far ahead of the pack, then assuming that your initial analysis was done competently, chances are very good that's the package that you'll go with. If several packages are pretty much equal, according to your analysis, then it really doesn't matter which one you start with. If you have the people and funding available to you, then you might want to experiment with several packages in parallel, but this runs the risk of increasing the overall project time due to the additional reviews that you'll need to choose the 'perfect' package.
In the Unified Process, the primary goal of the Elaboration phase is to prove that the architecture works by having a small team, typically the people who form the core of the development team, build an end-to-end skeleton of the system. You do this by implementing just enough functionality described by the technically most difficult requirements. When it comes to package implementations, the goal is to install the package and do just enough of the technically difficult integration work so as to determine if the package will work within your environment as promised. The skeleton that you build during Elaboration will be fleshed out during Construction.
To keep this as agile as possible, remember to do just enough work -- Elaboration should take a couple of weeks, not a couple of months or years. If integrating with your existing accounting system is critical, then do just enough work to connect with that system and share important data. Although you may eventually need to share 2000 data elements with that system, you can likely prove that the package integrates well with the system by sharing only 50 elements for now. Don't worry, you'll do the work to handle the other 1200 during the Construction phase (with an iterative approach you'll also discover that you didn't need as much as you originally thought). Remember that you only need a good gut feel as to whether the package will work, not a detailed comprehensively documented assessment, so strive to only do just enough work during Elaboration.
The 50 data elements that you choose will often be driven by their semantics--pick the elements that are crucial to your success as an organization. If the package doesn't support your data semantics, if you can't translate between the semantics supported by the package and what you desire, or if you're unwilling to change the way that you work to support the package then you've discovered that the package doesn't really meet your needs. When this is the case, you'll need to work with the package that is the next best option on your list, if one is still available. If not then that's an indication that you either need to give up on the idea or build the system yourself.
An important architectural issue that you need to address during Elaboration is to validate the effectiveness of the modification strategies for the package. Do you modify the package's behavior through configuration files or tables? Do you update specific portions of the source code? Can you update the database schema to add your own data elements? How are vendor updates handled? You'll have hopefully identified these strategies through your initial analysis during the Inception phase, but now is the time to prove how well the strategies actually work.
Once you've made it into the Construction phase you're very clearly in agile territory. You will prioritize the work that needs to occur to modify the package, each iteration producing working software that implements the highest priority functionality. Because it's a package the 'new working functionality' produced, each iteration is actually existing package functionality that's been modified to meet your organization's needs. This may imply actual changes to the package or increased integration with your existing legacy systems -- accessing the remaining data elements from your accounting system may occur several hundred times each iteration until the work is complete.
Recognize that you're on a very slippery slope when it comes to package modification because with an iterative approach it's easy to do 'just one more iteration' to get it right. The point is that your product owner must heed Capers Jones' good advice -- if you need to modify more than 15 percent of the package then you're probably in trouble -- and rein in their desire to modify the package until it perfectly meets their needs. My advice is that if you need a perfect implementation then a package implementation isnÕt for you and instead you'll need to build from scratch.
An important consideration will be to stick to the modification strategies supported by the vendor -- if you stray from them you will in effect end up owning the code and it will be difficult to take advantage of new releases of the package. A lot of the work will likely be around data semantics, either putting transformation code in place or refactoring your existing data sources and systems to conform with the semantics supported by the package.
Minimally, agilists do developer regression testing throughout the project, and better yet take a test-driven approach to development. This can be problematic if the package that you've chosen doesn't come with a regression test suite, although I'd have to question why you'd consider buying a package that wasn't easy to test. Be that as it may, if the vendor doesn't provide an adequate test suite, then you'll at least need to wrap the package with black-box test cases. You might want to consider partnering with the vendor on this or even selling the test suite back to the vendor to recoup your development costs.
The Transition phase is the same as for new development. You'll need to finalize your testing efforts, fix any last defects that you find, announce the system, train people in it, potentially pilot it or run it in parallel with existing systems, and release it into production. I described an agile approach to this work in The Agile End Game.
Package implementations are risky. They initially look great from a business point of view but can easily run into trouble if the bureaucracy gets out of hand. By applying disciplined agile strategies to package implementation, you can improve your chances of success. These strategies are based on putting together a team that you can trust to do the job, allowing them to actually do the job, doing just enough work to make the decisions that you need to, and doing just enough modification to the package to meet your needs.
Many people are worried about an agile approach to package implementation because it differs so drastically from the traditional strategy. The bottom line is that if your organization isn't capable of putting together a small team to give you a good gut feel about a package in a period of a week or two, then there is little chance that you're capable of actually pulling off the full-blown package implementation. We know that the traditional strategy doesn't work very well, so why not 'go at risk' and try an agile approach?
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.