Almost every business executive I talk to has a strategy that combines the best of packaged software with the best emerging application development software. These experienced executives are well aware that there are no magic bullets. They understand that they must be able to customize software (as well as some combination of enhancements, extensions, and modifications) to monolithic packaged applications that attempt to capture the uniqueness of their business practices. There are complexities involved in managing the delicate balance of having it both ways. It is hard to bring together standard parts of a package with custom coding and third-party best of breed applications without causing problems. The resulting combination is especially costly in the areas of maintenance and upgrading.
The problem comes at the interfaces of the various pieces. Each piece of software in this multifaceted environment has its own interface and communications requirements. To assemble such an environment, you must master each of these interfaces. If your environment consists of three, four, six, or more different pieces of code, youıve got a major job on your hands just trying to maintain all these interfaces. Every time one application changes, you have to go back and make all the other pieces work together again. In previous columns, Iıve discussed application integration solutions that try to address this problem. (See "Dismantling Stovepipes," DBMS, March 1998.)
Another solution is to purchase a comprehensive packaged application. However, even the most comprehensive packaged applications canıt meet all the needs of the organization, especially if you are looking for best-of-breed functionality in each area. You will invariably have to extend, modify, supplement, or somehow customize packaged applications. This process, indeed, will involve yet more packaged applications or custom-built applications.
Still, the movement of the industry toward packaged applications is clearly apparent. Leading vendors of comprehensive, monolithic packaged application are experiencing banner years as growing numbers of businesses opt for packaged applications over custom-built solutions. SAPıs sales, for instance, hit $3.36 billion last year, a 62 percent increase over the previous year. Baan experienced a 65 percent revenue increase to $684 million. Today, a significant majority of companies run packaged applications, and that number is projected to continue increasing.
The acceptance of packaged software by even the largest corporations and recognized industry leaders, however, leads many managers to wonder how they can differentiate their businesses if everybody is running the same systems. How can they achieve differentiation from their huge financial investments in software?
The answer lies in the shortcomings of the packaged software. If packaged software gets you 80 to 90 percent of the functionality you need, there is a 10 to 20 percent gap that still needs to be filled. This, most likely, is the area where your organization gains advantage over competitors. For some, it may be an unusual approach to pricing and configuring orders to give customers a measure of flexibility and savings that competitors canıt provide. Or it may be the level of personal service you achieve from the tight integration of purchase and shipment information with the customer-interaction system. This is where managers need to focus their best-of-breed impulses. Seemingly small differences ı the way an order is priced or a shipment routed ı may translate directly into market share points.
You close the gap between the strengths of the packaged application and the complete functionality you need by extending the application through integration with other best-of-breed applications, both packaged and custom built, or by modifying the source code. Letıs dismiss the latter approach as unacceptable, except as a last resort. The problem comes when your code modification prevents you from taking advantage of future upgrades of the packaged application. You are faced with either skipping valuable new functionality or reimplementing the entire package again. This latter option is a costly proposition.
Weıre left with extending the application by integrating additional functionality from other packaged applications or from custom-built functionality. Traditionally, this has been done via vendor-provided user exits. These exits let you attach functionality without touching the source code of the packaged application. When the next upgrade comes along, you can take advantage of it with only some tweaking related to the user exit. Increasingly, the vendors are providing published APIs, which are, in effect, a higher-level user exit. Because the vendors support them, APIs will remain relatively stable in the face of upgrades. Your extended functionality should continue to work with the upgraded application as long as the API hasnıt changed.
In the past year, however, packaged-application vendors have begun breaking their monolithic applications into components. This componentization will have a profound impact on packaged applications and the integration of best-of-breed functionality. We see three broad technological effects:
These three effects of componentization, particularly the last two, will help organizations trying to expand and enhance the functionality of packaged applications by integrating best-of-breed functionality. Specifically, componentization brings with it the ability to mix and match applications more easily within a single IT infrastructure. Through a well-defined set of component interfaces and messaging infrastructure, a customer can choose to add the functionality of best-of-breed applications to an integrated application architecture. You can add this functionality while still maintaining a similar, if not identical, level of integration as exists in the packaged software suite. Assuming that a robust interface exists between best-of-breed applications and core packaged applications, organizations will be able to expand the functionality of their application environments without building expensive, custom connectivity or sacrificing the integration they have come to expect from their packaged software systems.
The creation of separate components out of previously monolithic applications can also have a positive effect on the upgrade process. To upgrade the functionality of a specific element in a noncomponentized packaged application, organizations currently have to upgrade the entire package, an all-or-nothing process that is often both costly and complicated. In a component architecture, changes to a specific component can take place as part of an upgrade to that component only; the remainder of the application can function without an upgrade (provided the interfaces have not changed).
As a result, componentization offers an attractive option to organizations that do not want to upgrade entire application suites in order to gain the particular set of new functionality provided by the upgraded components. Managers can evaluate each upgrade in terms of the functionality it delivers and decide whether it is worth the cost and effort. This ability has been dubbed "selective upgrade."
While the benefits of componentization are promising, the separation of monolithic applications into components and the concomitant expansion of best-of-breed applications integrated with packaged software suites come at a substantial price, at least at this stage in the maturity of the technology. Companies will incur major costs from the acquisition of more hardware, systems software, and connectivity software in order to build a distributed, component architecture. Corporate IT staffs will have to develop new skills, including knowledge of distributed systems deployment and maintenance, data replication, new application APIs, and the specifics of component design and deployment.
Componentization also comes at the cost of increased complexity. Any time you start distributing functionality among different components and tie it back together using an underlying message-based approach (as the packaged application vendors are doing) you increase the complexity of the environment. This, in turn, can lead to increased maintenance, as pieces invariably fail.
Depending on the application environment, companies will also likely need to make a significant investment in knowledge about the middleware environment that underlies the component architecture. While most packaged-application vendors will attempt to hide as much of the complexity of the middleware layer as possible, users will still need to understand the intricacies of the middleware layer, particularly when it comes to deploying best-of-breed applications and third-party tools as components within the application environment.
Despite these caveats, components represent the application development future, both for custom application development and for packaged applications. Starting this year, the major packaged application vendors will be releasing upgrades that either support componentization or will serve as the major platform to support future componentization. Hurwitz Group recommends that companies with an interest in componentization plan to upgrade to a component-ready version of their favorite packaged application when it becomes available. Fortunately, most of these new packaged software versions can be upgraded without actually implementing all, or even a majority, of the component technology available. (An exception in most packaged software will be Internet and e-business functionality, much of which is being implemented in a component architecture. Internet functionality has been added on top so that the entire communications infrastructure does not have to be redesigned. Internet and e-business functionality is being provided by integration with third-party providers.)
The most important thing at this time is to be ready to implement components. Once you have a component base in place, you can have your best-of-breed application strategy and packaged applications, too.