| 2.1 Re-Use Versus New The case for integrating applications with XML applies equally to legacy
re-use and to building new applications. If we were defining a new application today, we
would specify XML as the data exchange mechanism for all interfaces other than SQL, for
all the benefit reasons discussed previously.
Arguably, a new application offers the greatest value to your
organization. A new design can best accommodate strategic as well as tactical business
plans. You can focus exclusively on strategic new technologies, with minimal constraints
from the limitations of legacy applications. You can utilize Java, advanced databases, and
new object-oriented / component architecture development paradigms. This is a great
opportunity to "future-proof" your application, constructing it so that further
evolutions in technology or business operations will not require significant re-work to
keep it fully productive in the future. (You can also significantly improve the
marketability of your own resume and those of your fellow staff at the same time.)
However, there are drawbacks to this rosy picture. The ugly
truth is that 2/3 of new IT application initiatives fail outright or are seriously overdue
on delivery time, and this percentage increases with larger scale projects. We won't
mention those, which are over budget. The best benefits from this "build new"
approach --new environments, languages, databases, and application architectures -- bring
new and unknown risks that are difficult to evaluate in advance and to adequately control.
A business-critical application that must be delivered on time to avoid serious damage to
or gain significant advantage for the business is not the time to pursue these
investigations. Better to do so with a non-critical project.
Large organizations with an imperative to get on the web now
can afford neither the time nor the substantial risk of late or incorrect delivery that
comes with building a new application. One viable alternative to building new is buying
new, although we would add an XML requirement. This approach has many of the advantages of
building new -- new environments, languages, databases, data architectures and application
architectures -- without the risks. This is because you can visit sites, which are already
using the application, and you can write a contract that says the vendor won't get paid
until it is running satisfactorily and reliably.
Purchasing an off-the-shelf application can overcome these
risks provided that there are no significant modifications or integration issues required
in the installation, and provided that the business process can be readily modified to
accommodate the new software. These can be big "ifs", but if they are valid,
then this is almost assuredly the way to go. Indeed, many of the changes enabled in the
business process may be desirable in themselves, and may not have been within the budget
of a plan to build new.
However, there is one reason to avoid a package and to stick
either with building new or with re-use strategies -- the competitive advantage conferred
by proprietary software assets. If you buy a package and your competitors buy the same
package, where is the competitive differentiation? The standard advice for this question
involves core competency. If the function supported by the application is a back office
function, such as payroll or inventory control, then buying a commercial off-the-shelf
product can make a lot of sense, because these are rarely business strategic. On the other
hand, applications that involve unique services and that are highly valued by your
customers may cause the business to lose a key competitive edge if replaced by a generic
application. In this case the legacy asset is business strategic, and one must be very
careful in choosing to buy a replacement for an application, which embodies one of your
organization's core competencies. |
