The architect's role in package application integration What to think about before you roll out that new Enterprise Resource Planning (ERP) application By Steve Gunnell

August  1998

Picking up a packaged application rather than developing it yourself in-house certainly has its appeal. This month, Steve Gunnell tells you what to consider when choosing a package application -- and what you can do, as an IT architect, to make your company's adoption of package applications smoother for all concerned. (2,500 words)

Mail this article to a friend

Foreword

It is rare nowadays to find a technology environment without a single purchased business application. Application packages have very much become a part of the average technology architecture. Architects must understand how these packages are selected and deployed, and be ready to help integrate this software into the existing environment. (Note that the actual techniques for accomplishing technical integration are discussed in the June column.) This month, Steve Gunnell, who specializes in application package implementation, helps us understand these types of projects, and suggests ways the IT architect can get involved to help ensure their success.

--Kara Kapczynski

few months ago, my colleague, Sam Wong, wrote about alternative architectures for application integration. This month, I'd like to pick up where he left off and talk about package application implementation issues. Although it seems that every company is implementing some sort of ERP or front office packaged application these days, architects aren't always involved in package application decisions or implementations. They should be; IT architects can play a key role in making an application implementation work.

Why choose package software?
A number of factors drive organizations to purchase package software rather than develop custom systems:

• They can be quicker and easier to implement.

• Best-practice business rules and workflow tend to be already implemented in the package application.

• Packages come with regular upgrades and support, so maintenance becomes a stable cost. This makes budgeting easier. Maintenance of any customizations must still be done in-house, so there are still budgeting challenges.

• Because support and maintenance are outsourced, you can make fewer changes your organizational structure to accommodate a new packaged application.

• Companies may simply not have the expertise to develop applications.

At the same time, of course, package software isn't without its downsides, including:

• The temptation to engage in "silver bullet" thinking (that is, thinking of the application as the complete solution to all of your organization's problems).

• A loss of in-house control over features and functionality.

• The inability to meet unique business requirements (that is, your package may require massive customization).

• A strategy to use information systems as a competitive advantage may dictate controlling software development in-house.

• Poorly defined software requirements or a rapidly changing business environment may suggest an iterative development model that can only be accommodated by building custom software.

• Although the package vendor will handle upgrades and some level of support, you'll still need internal resources to support the application, including DBAs, system administrators, and trainers. The greater the scope and complexity of your package, the more internal resources you'll need.

Package undone: A case study
This is a hypothetical account that illustrates some of the issues and common errors made in selecting, designing, and implementing a package application.

DoITNow Corp. is a mid-sized electronics manufacturer. Over the past few years it has seen its market share decline. Company management has decided that "world-class customer service" will now become the rallying cry to increase growth and improve customer retention. Unfortunately, the customer service department has traditionally been thought of as a necessary evil rather than a strategic asset to the company, and management has under-invested in both training and customer service systems for this department.

After months of indecision, management decides that a computer system to better track and respond to customer trouble calls is required to meet the new corporate objectives.

Following initial consultations with the CIO, DoITNow decides to go with a customer service package application, since it shouldn't take much time to implement. Encouraged by top management, IT managers immediately identify potential packages for review. They also begin a hasty effort to assemble a list of requirements for the new system.

Management has decided on April 1, four months hence and the start of DoITNow's fiscal year, as the date the new system will go live. Vendor presentations are arranged for the following week and management is feeling upbeat about moving quickly to implement its new customer service strategy.

The vendor presentations go well. The out-of-box functionality seems robust and, although the requirements for the system aren't fully fleshed out, the general consensus seems to be that the packages will be able to meet the needs of the organization.

Two weeks later, after some additional review of the application functionality and checking of references, a letter of intent is signed with ServU Software. A contract is signed and the project to implement the package is set to begin immediately. Since management has specified that the system must go live on April 1, IT management agrees to do everything possible to meet that date, although the actual work of designing and configuring the system cannot begin until the first week of January.

After two weeks of design work with customer service personnel, a potentially serious disconnect between the architecture of the package and DoITNow's business requirements is discovered. Furthermore, DoITNow's users feel that, because there are more screens and more data to capture, it will take much longer to do their jobs with the new system than with the previous system. Additional difficulties are discovered in interfacing the new system to existing service contract and product data management systems.

After several more weeks of design work, project analysts are able to design workarounds for most of the problems. But doing this makes future upgrades much more difficult. Furthermore, to avoid constructing a very complex and costly interface, some of the customer data will have to be maintained on both the corporate legacy and on the customer service in parallel. Customer data between the two systems will therefore likely become out of sync and will periodically have to be reconciled.

As the project team nears completion of the design phase in mid March, management pressure to complete the project has risen to a fever pitch. The team launches into development before design specs for critical parts of the system can be reviewed.

Development of the system is finally complete in late May. In order to accelerate the schedule, management decides to reduce the system test phase from four weeks to two weeks. User training is also reduced from the two days originally planned to half a day.

Epilogue: Due to issues with the design and difficulties in usability of the system, portions of the system must be redesigned, developed, and tested. The system is finally rolled out in August -- four months past the target date set by management and 200 percent over the original budget.

DoITNow has done it late. Why?

Lack of overall systems planning
One of the first things you'll notice in my example is that DoITNow's decision to purchase a customer service application was not made in the context of an overall systems strategy. There was no overall architectural framework in place with which to evaluate the proposed system, nor was there a process in place to make sure that such an evaluation occurred. As an IT architect, when you evaluate how a new package will integrate into your existing systems infrastructure, you need to look at a number of things, including requirements for moving data back and forth between the package and other systems (possibly driving the purchase of an additional tool for data movement and transformation), integration with a management framework that might already be in place (such as performance measurement and incentives), and disaster recovery planning.

To ensure that application plans from all parts of your company fit into a cohesive plan, an IT governance board can be established to review systems proposals and help guide technology decisions among various operating units. A senior IT architect should be included in this type of review board, providing the analysis necessary to develop a roadmap for fitting the application into the overall enterprise architecture. While this type of high-level review can slow the approval process and might be seen as anti-entrepreneurial, the benefits far outweigh the potential drawbacks.

IT directorates of this sort have been implemented within a number of organizations in recent years, under a variety of names. Gartner Group refers to such an organization as an "Office of Enterprise IT" (Strategic Analysis Report, July 23, 1996). META Group promotes the concepts of an "Enterprise-Wide Technical Architecture" or an "Architecture Review Board" (Enterprise Architecture Strategies, trend teleconference, December 15, 1997).

Overly optimistic schedules
Another stumbling block for DoITNow was its overly aggressive schedule. This is very common in package implementations. Unfortunately, an unrealistic project schedule can be a significant step toward project failure because it can drive all kinds of other poor practices during a project.

Project scheduling issues are, when it comes down to it, really planning and management issues. So they may seem irrelevant to the IT architect. However, these issues become all too relevant when underestimated projects become troubled projects. Troubled projects tend to divert resources away from planning and architecture development, as well as reducing the credibility of any organization's IT efforts. Unrealistic schedules may also fail to allow for time up-front to understand the application-specific architecture and how it would fit into the enterprise.

DoITNow made several classic errors in setting a schedule for its project. It delayed the decision to move forward with a system and then, once the decision was made, externally mandated the schedule based on no real information on how long the project would take. This error was then propagated by IT management, who failed to push back and force the development of a workable schedule. Additionally, management engaged in "silver-bullet" thinking -- the notion that a new computer system is, in and of itself, the solution to business problems. In doing this, management forgot that technology is just one component in an overall business system, which includes process and organizational components as well.

Some of the key planning issues ignored by DoITNow are common to most any client/server ERP or front-office application package, including the following:

• Process definition. You need a definition of how the functionality of the package will be used within a specific business and organizational context.

• Definition of approach for functional gaps. Gaps between what the package does and what you want it to do will become evident during the design process. You'll need to decide in advance what approach you'll take to filling them: customization, change requests to the vendor, or business-process workarounds. The tradeoffs and negotiations involved here can consume a lot of time -- particularly in consensus-driven organizations -- so time must be scheduled for this part of the process.

• Integration with existing systems. Sam Wong discussed this in the June column. Integration with existing systems is often a critical path task for package implementations. In the case of DoITNow, issues with integration were not considered in the up-front planning and ended up being problem areas for the project.

• Training. Training is required, not only on the new concepts and user interface of the package, but also on new business processes and procedures.

• Testing. Many business managers overlook the fact that package applications come with bugs. Additionally, any customization that you do will introduce new bugs. Therefore, complete system test cycles are necessary prior to a system rollout.

The cure for overly optimistic schedules and underestimated projects is to develop a realistic, bottoms-up plan. Only adjust the schedule from a baseline by changing one or more of the three key software project management variables: features/functionality, timeline, or resources. The IT architect may be the most qualified person to provide insight into the issues at hand and provide the crucial analysis required to generate the schedule.

In a recent project, a member of the customer service management team -- like the DoITNow management team -- specified an implementation date in May based on internal business scheduling needs. In this case, however, the project team did not simply accept management's wish date. Instead, there was a review of the functional requirements for the package, a gap analysis of the selected package vis-à-vis the functional requirements, and analysis of the system integration, legacy data conversion, and training requirements. Architects from the IT organization were included in the analysis of the integration issues. The team then assembled a bottoms-up plan for the project, including all project tasks, resource assignments, and task dependencies. This showed that the system would not be able to be implemented until September -- several months later than management's initial date.

Negotiations ensued to identify lower priority functional requirements and exclude them from scope. A final project plan was then put together, showing a system rollout starting in July -- only two months later than the targeted date. Both management and the implementation team felt satisfied with the resulting schedule, and the project was ultimately completed according to this schedule.

Mismatch between functional requirements and package application
Package implementations share many of the risks common to custom application development efforts. However, because of the nature of a package -- which often involves the purchase of an entire application architecture, data model, and development tools -- the initial purchase establishes an architectural framework that can be difficult to change. As a result, certain types of risks, such as inadequate design, are front-loaded onto the project. As illustrated by DoITNow, a mismatch between business requirements and package design becomes a project liability, which may require significant effort to overcome (if this is even possible). When you're investing in a package application, the less you know about user requirements or about the package itself, the greater your risk.

The opportunity for an architect -- particularly a data architect -- to make an important contribution to the selection process in the DoITNow example is clear. To avoid some of the difficulties I discussed, an architectural review of the application should be included as part of the application selection process. Of course, this type of review takes time, but it is highly leveraged time. A week or two of architectural review up front may save months of wasted design and development time later in the project. Although the IT architect is probably not the only person who would need to be involved in such a review, the enterprisewide system perspective is key here. Ideally, the review would include a mapping or analysis of the package's data architecture against the organization's enterprise data model to identify issues with relationships between entities, missing entities, and such.

Lack of project reviews
This is yet another poor practice illustrated in the case of DoITNow. Due to schedule pressures, reviews of designs were ignored in favor of moving quickly into development. This is a very risky practice, since it is inevitable that during a design process the project team will acquire new information, and the approach for integrating a package application may change as a result. It is very important that design reviews be conducted and that the IT architect be included in these reviews in order to evaluate design changes and implications for the larger system architecture.

The IT architect's crucial role
We've discussed how a package implementation project can be derailed from the very start by lack of enterprise system planning, unrealistic project schedules, inadequate knowledge of the package architecture, poor understanding of business requirements, and lack of review of project designs. Mistakes made at the beginning of the process can have a snowballing effect later in the project.

Because the IT architect likely has a broader view of the enterprise architecture and the architecture of other systems, he may be in a better position than almost anyone else in the organization to help the package implementation team avoid pitfalls that not only jeopardize the implementation of the package, but also could compromise the enterprise architecture. The architect's involvement in an architecture board and in the package selection process ensures that package features are not considered to the exclusion of architectural issues. The architect's involvement in initial analysis required for project estimation increases the chances of a reasonable project plan and project assumptions. And finally, involvement of the architect at key review points in the design and implementation process may help the team avoid poor designs that will be costly to correct further on in the project.

Resources

• Last month's IT Architect column, "The logical data architecture" http://www.sunworld.com/swol-07-1998/swol-07-itarchitect.html
• Previous IT Architect columns, http://www.sunworld.com/common/swol-backissues-columns.html#itarchitect

About the author
Steve Gunnell is an associate director and project manager at Cambridge Technology Partners. Reach Steve at steve.gunnell@sunworld.com.

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-08-1998/swol-08-itarchitect.html
Last modified: