Packaged applications provide immediate value to the Fortune 500. No longer must we wait through long development cycles to realize the benefits of an enterprise application such as an inventory control system, sales order system, customer care application, or general ledger application. There are many in the business, but SAP America Inc., PeopleSoft Inc., Oracle, and Baan Co. lead the industry.
In days past, packaged applications meant older systems and green-screened terminals. Today most packaged applications are based on state-of-the-art client/server or Internet/intranet application architectures. Modern packaged applications run alongside standard office automation applications, and they have become almost as familiar and easy to use. This revolution in using prebuilt applications has given rise to a multibillion dollar consulting opportunity, driven largely by the bigger accounting firms. The demand has also created a shortage of qualified applicants who are skilled in the ways of SAP, Baan, and PeopleSoft. This boom industry, only a few years old, has led to a new to look at application design. Once upon a time, we built everything from scratch. Now organizations are finding that the best value is to purchase and integrate. This may seem like a simple process, but the number of failed package installation projects outnumbers the successes.
Most packaged application integration projects fail because of one or two of the following reasons:
Lack of preparation is a common problem because of the incorrect notion that SAP and Baan will install as easily as Word 97. The fact is, enterprise-class packaged software installations, as well as their integration with your existing infrastructure, are in many ways more complex than building the application yourself.
Preparing for a package installation and integration project means first understanding the user requirements and business issues in great detail. For instance, how many end users will use the system on a daily basis? What are the hardware and software requirements for the package? What about sharing information and processes with other external systems? How long will it take for users to learn the new software? You get the idea. Itıs also a good plan to document these requirements, feeding them back to the user to assure there is no miscommunication.
Itıs a fact of life that it will take a good deal of time to get a set of larger Unix servers up and running, as well as to define the points of integration with other systems. A great deal of coordination needs to take place, and if it isnıt begun early in the installation and integration process, the project is at risk before it even gets off the ground.
Another project killer is the lack of a clear vision of the business drivers. The package has to solve some problem that will make money for the company somehow. If it doesnıt, the company should not install it.
For example, if the sales department is not able to keep up with customer demand, you have a business problem. The business driver in this situation is the value of having a faster system in place to keep up with customer demand and thus make more money. Using this as the "value proposition," itıs easy to put the metrics in place to assure that the system lives up to expectations after going live. If there is no clear set of business drivers, nor a value proposition, the organization may want to consider other solutions or doing without a system altogether.
Neglecting the application architecture is a common problem because people think that a packaged application installation effort does not require any formal application architecture. While itıs true there are different architectural problems to solve when installing and integrating a packaged rather than a customized application, there are also technical problems to solve.
A common issue is that most organizations donıt accept the package as itıs bundled. Instead, they make modifications to the business service and interface layers of the packaged application, which is not unlike a reengineering and application development activity. Requirements must be gathered, interfaces designed, and business processes redefined. A plan must also be formulated for using the proprietary technology of these functions. Most packaged application vendors understand the requirements of application architects and bundle design and development tools to help. SAP, for instance, sells the ABAP Workbench, a repository-driven development platform for client/server applications not unlike (at least in concept) other client/server development packages on the market today (more on ABAP later).
Packaged application vendors are also providing CASE-like tools to help their customersı reengineering and redesign efforts. SAPıs R/3 Business Engineer (now in release 4.0) is an example of such a tool. Business Engineer provides business process configuration services for R/3 installations. R/3 Business Engineer provides a mechanism for business process improvement, and it is the core enabling tool for SAPıs SAP R/3 installation and configuration methods called Accelerated SAP (described later). The idea is to make all configuration decisions using the modeling tool with the model tied to the corresponding customizing tasks. The tool lets R/3 application architects see how changes in the business process will affect the system before actually making the changes.
PeopleSoft provides a similar tool for application architects called the Business Process Designer. Using this tool, you can define business processes by creating visual models that reveal activities, steps, and workflow routings. Application architects use the models to obtain an overview of the process and navigate to the application components they need to work with during a PeopleSoft installation and integration project.
Lack of understanding of the human elements is a critical mistake because, ultimately, they are the people responsible for accepting the system into production. The ultimate users should be included in the design of the interface, definition of business services, and the common definition of what denotes "good performance."
Moreover, there needs to be a training plan in place to get all potential users up to speed with the new application as well as a change-management plan in place to bring the system into everyoneıs workplace in an orderly manner. As technicians, we tend to focus on the technology and not the biology. Do so, and the project may not meet the requirements of the end user, and thatıs the ultimate measure of success.
Itıs a mistake to neglect the rigorous testing process that assures that the newly installed system is meeting performance, interface, and business expectations. There really are no tricks of the trade here other than creating a test bed for the package and putting it through its paces. There are three levels of package testing: performance, process, and interface.
Performance testing is a direct examination of the throughput of the packaged application. For example, how long does it take an order to appear on the warehouse PC after it has been entered in sales? How long does it take the package to locate a customer in the database? Performance problems are critical to discover as early as possible because the only real fixes are redesigning the application and ordering new hardware and software. Discovering performance problems after installation could delay a project for months and could cost you the faith of your clients or users.
Most packaged application vendors understand the need for testing and provide either their own testing tools, or interfaces to external tools. SAP, for example, provides the Basis: Automated Testing Tool interface (BC-ATT). The BC-ATT interface is a combination of SAP Graphical User Interface Presentation Server software and the Desktop Developer Kit interface, providing third-party testing tool vendors with the ability to execute under Windows 95 or Windows NT on SAPıs Presentation Server PC, which communicates with the R/3 application server.
An example of a testing tool thatıs able to leverage the BC-ATT to test SAP installations is AutoTester Client/Server for SAP R/3 from AutoTester Inc. AutoTester is able to simulate a user load on an SAP installation by running test scenarios over and over again or randomly.
Process testing is a quick look at the systemıs accuracy and its ability to live up to the business requirements. For instance, does 2+2=5? Does the inventory report reflect the data fed into the system? This is most important when testing systems that have undergone substantial customization and therefore have new processes that have not been tested by the package vendor.
Typically, test scenarios come from a test plan. Simply put, the test plan will include the tests to be run on the new system, the input, and the expected results. You can stress the importance of this sort of testing by considering that bugs in processes (for example, processing all sales at a discount) could cost as much as a million dollars in lost revenue.
Interface testing is a quick look at how well the interface works with the human beings who have to use it. It involves working directly with the end users during the entire installation process, gathering requirements, and assuring the user that the requirements are met in the final product. This is especially important for those users, such as telephone sales operators, where a bad interface can translate into slow sales order response on the phone and thus lost sales as other customers wait.
Truth be told, each application suite has its own architecture, customization features, installation procedures, and level of complexity. You can never approach the installation of all packages in the same manner. This has led to specialization in the consulting world. For example, the SAP practice will handle all SAP installations.
SAP R/3 is the most popular package among the enterprise resource planning (ERP) applications, and thus it receives the most coverage here. SAP uses a thin-client, three-tier architecture thatıs pretty much proprietary. The real processing occurs at the middle tier, or the application server. R/3 leverages a transaction model, using a proprietary transaction processor. The R/3 clients are basically data collectors for the middle-tier transaction processor. The client defines its behavior by invoking transaction services on the middle tier. SAP R/3 uses off-the-shelf databases such as Oracle and Sybase for the database layer. SAPıs ABAP Development Workbench, as I already mentioned, includes a repository, editor, and dictionary, as well as tools for tuning, testing, and debugging R/3 applications. This is where ABAP developers will customize the SAP software to meet the exact requirements of the enterprise. SAP layered this tool deep into the R/3 middleware layer, so itıs able to communicate with the application server as well as the R/3 clients. Most traditional client/server developers will find ABAP lacking many traditional features, such as object-oriented development capabilities.
In addition to providing tools and technology for an SAP installation, SAP offers an implementation methodology called AcceleratedSAP. AcceleratedSAP is divided into several phases including Project Preparation, Business Blueprint, Simulation, Validation, Final Preparation, Go Live, and Support. Although we are looking at AcceleratedSAP in some detail here, other packaged applications have their own installation and integration methodologies and approaches as well.
The Project Preparation phase organizes the project kickoff and makes all the arrangements for the project team. The Project Preparation phase also includes the estimation of project resources, costs, and duration of each activity.
During the Business Blueprint phase the consultants document the requirements of the enterprise, including interviews with potential users, user workshops, and business process design using the R/3 Business Engineer. The R/3 Business Engineer allows the project team to visualize the current business processes and make changes to the processes before committing them to the final system. Moving on, Blueprint lets you create a business analysis thatıs made up of written and pictorial representations of the companyıs structure and business processes.
The Simulation phase allows the integrators to configure the R/3 software to match the structure of the company and the desired business processes. The system is configured and documented using the R/3 Business Engineer tools, and the technical team members establish the system administration activities as well as plan the interfaces and data integration infrastructure of the new system.
The Validation phase directs the use of the Business Engineer to configure all your business and process requirements. This includes such things as data conversion and the development and testing of interface programs. For configuration purposes, the business processes are separated into cycles of related business flows and configured with the construction of reports, end-user documentation, testing scenarios, and security models.
The Final Preparation phase is where all the work from the previous phases is consolidated, with the goal of preparing the system for final acceptance. This phase covers the final system test, user training, and final migration of the data to the new system. Moreover, all the conversion and interface programs are verified, as is the scalability of the system. Finally, the user acceptance tests are run. SAP defines a process known as an EarlyWatch session, designed to tune the R/3 system before acceptance and during production.
The Go Live and Support phase reviews the system to ensure that all business requirements are met. This includes checking the business processes and technical architecture, as well as checking with the end users, assuring that their expectations are met. Finally, the business benefits of the new system are measured, allowing the company to determine the ultimate return on investment (ROI).
If you donıt like this approach to integrating an SAP system, donıt worry. Each consulting organization has its own approach or methodology. These are basically checklists to assure the client organization that all bases are covered with the installation phases. They also assure the consulting organizations a rather hefty fee when the integration and installation project is complete. These canned method-ologies reduce most of the project risk.
PeopleSoft, like SAP, provides a set of methodologies and tools, called PeopleTools, for installing and customizing its ERP application. PeopleTools is a rapid application development environment providing both application architects and developers with the ability to tailor PeopleSoft applications to the enterprisesı business requirements. Features of PeopleTools include a workflow designer, development subsystem, administration tools, reporting tools, and integration tools that link other products to PeopleSoft.
Another example of a packaged application is Scopus, a suite of customer care applications from Scopus Technology Inc. Scopus installations are customized using ScopusWorks, a complete set of integrated configuration, customization, and administration tools usable across all Scopus customer care applications. ScopusWorks provides a graphical interface to Scopusı metaobject architecture to design, lay out, and configure the windows and forms of the Scopus application. These tools support templates for frequently used fields and objects, as well as the ability to integrate ActiveX controls into traditional Windows applications. Finally, ScopusWorks streamlines business rule development and redevelopment and customizes workflow between forms and objects found in Scopus applications.
Where SAP has ABAP, PeopleSoft has PeopleTools, Scopus has ScopusWorks, and Baan has Dynamic Enterprise Modeling (DEM). DEM is a framework to adapt an organizationıs software to changing organizational structures, business practices, and operational procedures. The DEM framework is a layer on top of traditional ERP applications, allowing the developer or application architect to match specific business processes with the new layer.
There are a lot of tools you can use to install, deploy, and manage applications. You can divide them the categories of into service management, system administration, and production control. Letıs take a quick walk through some examples of service-management and production-control products for R/3.
Service-management tools support the highest levels of application management, building on the capabilities of the production-control and system-administration tools. Such tools add a tremendous amount of value to a packaged application installation, providing high availability and integrity.
You can divide service-management tools for packaged applications into a few subcategories: reporting, availability, and performance (although they all have a tendency to provide features outside of their core competencies). Reporting tools, such as those from Envive Corp., Luminate Software Inc., and Candle Corp., provide you with the ability to determine the status of an application during run time. They also allow you to track historical data, "trend" the data, and react to problems.
Enviveıs Inspector for R/3, for example, emulates the knowledge and analytic skills of a team of experts. Inspector can monitor events, diagnose situations, and even recommend corrective action to fix problems with the SAP system. Inspectorıs front end is pure Java and can collect diagnostic information using its own local database, yet it all fits on a single Windows NT server. Inspector is able to diagnose problems with the R/3 application, as well as the operating system, network, and database. This is important because you need to consider all subsystems when diagnosing and resolving problems in real time. Inspector provides service-level reporting that includes a graphical representation of overall system and subsystem performance and the ability to perform OLAP-like operations on the historical data to spot trends.
Luminate for R/3 is an example of a service-reporting tool for packaged applications. Luminate provides performance and availability analysis and stores historical data for statistical analysis. This tool can report R/3 up time, response time, and transaction volume. Using this information, the technical staff can make decisions as to the overall health of the system. This tool lets you report on statistics such as moving averages through a realtime set of graphs. You can automatically sort and filter the information, creating specific views for specific purposes.
If you need to perform capacity planning as well as performance monitoring for your R/3 system, consider BGS Best/1 for SAP R/3. This tool uses its own collection agents to gather performance data from R/3 subsystems. Using this data, Best/1 can determine trends and report them via tables and graphics. By using these multiple views, Best/1 users can model future capacity requirements and change the environment accordingly.
When considering production control tools you have a choice of tools from vendors such as BMC Software Inc., Computer Associates International Inc., Legato Systems Inc., and Tivoli Systems Inc. (a subsidiary of IBM). BMCıs product is really a set of extensions on the BMC Patrol product for database, network, and operating system monitoring. BMCıs R/3 solution includes Patrol Knowledge Modules (KMs) for SAP R/3. These modules provide a common interface to monitoring and analysis of critical application resources. The KMs collect information on events, performance, and printers. The Events KM gathers information from the SAP R/3 MIB and CMS log and includes a specialized ABAP programs to extract data from R/3. The collection of Patrol KMs provides R/3 administrators with an in-depth view of performance statistics for all SAP subsystems, storing all the information in a central database. In order to circumvent some of the problems with SAPıs printing subsystem, you can rely on Patrol. SAPıs printing subsystem assumes that if a job is printed and output spooled to a file, the job is complete. This can lead to disaster if a job is not printed yet marked as complete. This KM monitors printer activity for problems and notifies the console of trouble.
Of course, each package must work with a database to store and retrieve the data for the application. Database support varies from package to package, but most vendors support the popular databases such as Oracle, Sybase, Informix, DB2, and Microsoft SQL Server.
Typically, each package will come with its own set of DDLs for each target database supported. Itıs just a matter of running the DDL against the database and creating the proper physical schema as well as all relevant stored procedures and triggers. Unless youıre only supporting a few users, the database should reside on its own server.
Scalability is an issue when considering the database as well. Most ERP packages ı SAP and PeopleSoft for example ı use a transaction or application server (three-tier client/server) thatıs able to multiplex the database connections and thus buy you increased scalability. Other packages leverage two-tier client/server, meaning that the clients go directly to the database and require one connection per client. As with traditional client/server systems, two-tier packages arenıt as scalable, and you should take that into consideration when designing the architecture.
All packaged applications have some sort of Web-enablement strategy to deploy an application either to the Internet or, more likely, on an intranet. They all differ somewhat, but the basic idea is to replace the client with a Web browser that can link to and invoke transacation services on the application server. Sometimes the application server needs to support these new features; sometimes that Web client aappears as a traditional client and thus does not require an upgrade to the infrastructure. Most of the advanced ERP applications are using Java at the client to provide dynamic behavior to the end user, but some still only provide primitive solutions such as generating static HTML. You need to ask a lot of questions if Web enablement is important to you.
PeopleSoft, with version 7, offers two new tools: the Web Client and the Universal Applications. The Universal Applications is the Java-enabled server-side portion of the architecture serving up the applets to any number of Web Clients. The Web Client is downloadable from the Web server and is able to run on multiple browsers on multiple operating systems. All the data transmitted between the Web Client and the application server is encrypted. In short, PeopleSoft is simply creating a new Java-based Web-enabled client to communicate with its standard application server.
SAPıs Web-enablement architecture is a bit more complex. R/3 provides a Java component that can communicate with components that reside on a remote application server. The application server invokes application services through BAPI ı beyond that itıs traditional SAP. SAP creates a whole new architecture at the application server layer to support Web enablement.
On the customer-care side of the packaged application world youıll find that Scopus Technology Inc. provides a product known as WebTeam. Using WebTeam you can generate Web applications directly from new or existing Scopus applications. Itıs just a matter of regenerating HTML from an existing application. However, the Scopus Web strategy is focused primarily on providing relevant data to customers via the Web, not on redeploying all their application modules.
Organizations are finding that there is more value in purchasing packaged applications and modifying them than in building them from scratch. We are finally learning to reuse code through the use of packages. As packages become feature rich and customizable, itıs clear that the trend of buying vs. building will continue for some time. As developers and application architects, we must adapt to survive.
There are problems to solve, however. We must understand how to leverage the lessons learned from prior installations and transfer that knowledge to current projects. As an industry we seem to be making the same mistakes over and over again. You should never fail the same way twice. Whatıs more, we need to understand the vision for the application and not simply the current technology. The packaged application needs to grow with the organization, letting us add value as time goes on. It should not become a point of contention as so many of the previous enterprisewide packaged applications have become.
The future is clear. We are going to concentrate more on extending existing packaged applications to the Web as well as streamlining the customization process through new tools and techniques. As our base of understanding grows, so does our ability to carry out installation and integration projects effectively. Packaged applications are here to stay. We must now learn how to harness their power.
What did you think of this article? Send a letter to the editor.