By Dan Woods – 10/20/2003
Packaged Composite Applications refers to a new kind of application that uses existing enterprise applications and technology as a foundation. Instead of starting from scratch, developers can build applications by grabbing the customer objects and related functionality from the Customer Relationship Management system, the financial information and calculations from the Enterprise Resources Planning system, product related information from the Product Management system, and then add whatever new functionality that might be needed from systems like Content Management or Portal or Business Warehouse to get the job done. SAP®'s version of PCAs are called xApps.
What makes all of this "grabbing" and reassembling of applications possible is Enterprise Services Architecture. Everyone has heard about Web Services and XML and how they allow applications to talk to one another in standardized way, similar to the way that HTTP and HTML allow browsers to access and display information from web sites. With web services any application can create a description in Web Services Description Language (WSDL) that tells other applications how to use its services. Enterprise Services Architecture is the set of principles that allow enterprise applications and technology systems like Content Management to present their services for use in composing PCAs. An Enterprise Services Architecture platform is layer of software that coordinates all of the services from the underlying systems, allows them to be collected into components so new user interfaces to be built on top of them. SAP's version of an Enterprise Services Architecture platform is called SAP NetWeaver.
This explains the Composite part of PCAs. The Packaged part simply means that these applications are products supported the exact same way that the enterprise applications like CRM are supported. Packaging is more significant for customers than UI designers.
This article is going to examine in a condensed form the implications of PCAs and ESA for the user interface designer. Our analysis is that PCAs are a liberating force for designers that allow them to cast off previous constraints and challenge them to solve new problems. Specifically, in the world of PCAs User Interface designers are:
The world of PCAs and Enterprise Services Architecture (xApps and SAP Netweaver) will produce a rise in prominence of UI as a foundation of an application's success. The flexibility of PCAs and Enterprise Services Architecture will free the designer from the database oriented interfaces that have dominated SAP technology until now and replace it with a task- and process-oriented approach that is centered around a user's role in a process not a related set of transactions that transform a database.
UI has always been important but not always primary. Frequently, the suggestion of UI designers as to how to better serve the users needs have been appreciated, but dismissed because the power and flexibility of the underlying application systems could not implement what was suggested. Will everything be possible and effortless in the PCA and Enterprise Services Architecture paradigm? Of course not, but the range what can be done and the cost of doing it is now low enough that the bounding factor in the short term may be the retraining the imagination of UI designers to understand the new freedom and related responsibilities.
In this article we sit in the designers chair and examine the way that these developments will change what is being asked of designers and how they may do their jobs.
Packaged Composite Applications are a new paradigm for developing applications. Instead of starting from scratch, PCAs start with existing data and functionality and then coordinate that functionality in different ways to solve new problems. PCAs also add new functions for specialized purposes that sit on top of existing platform. The ESA platform is what makes the reuse of existing applications possible. All of this adds up to the following general structure:

Figure 1: PCA/ESA structure
PCAs in general solve problems that are smaller in scope than the previous generations of enterprise applications like CRM and ERP. The processes that are automated are more collaborative and fluid. In addition to data stored in databases, unstructured information generally must be managed by the application. The structure of SAP xRPM, an xApp focused on managing large portfolios of projects, crosses boundaries between large applications like mySAP Financials and information stored in Microsoft Project.

Figure 2: Structure of xRPM
While in the previous generation of applications, most user interfaces felt like a paper-based form in which the main task was entering data, PCAs are much more like a dashboard, showing the relevant information for each different part of a process that a user is monitoring or participating in.
PCAs are different than traditional enterprise applications because they are
oriented toward services as the underlying implementation primitive, rather
than a table in a database. In fact, the Enterprise Services Architecture platform
provides many different types of services for the PCA developer to start with
and the PCA developer generally adds some as well. These services can come from
a variety of sources as show in the following diagram:

Figure 3: Sources for Web services
So, in general, PCAs are oriented much more toward the process being addressed and the services that enable that process to move forward. This means that the UI designers and application developers usually talk much more about the role that each user plays in the process and how to help people playing that role meet their goals using an interface tailored to their needs.
Because excellent User Interfaces are so important to the success of applications and because so much of the cost of maintaining an application goes into modifying and maintaining the user interface, SAP has poured massive resources into creating new ways of creating user interfaces.
The current methods of SAPGUI, Dynpro, HTMLB, BSP, ITS as moving parts are going to be supplemented with new technologies such as Web Dynpro, Composite Application Framework (CAF), and GUI Machine (a code name) that will change the way user interfaces are constructed.
The theme of this change is that coding of a user interface of the sort that happens in HTMLB or BSP will be replaced by modeling of a user interface that is much more like moving blocks around in a Visio diagram than working with a text editor. Web Dynpro is the first system that will introduce this paradigm as the UI for SAP applications. CAF and GUI machine will work in a similar manner and may even use Web Dynpro to help do their work.
In Web Dynpro the complexity of a user interface is separated into three categories, Model, View, and Controller. The MVC paradigm was invented in the 70's at Xerox Parc and has been implemented in many different languages. The model represents the thing that the user interface is interacting with, the controller offers facilities to interact with the model and react to events that come from the view, which is the visualization that is presented to the user.
One designer, Don Dwiggins, suggests thinking of the MVC paradigm as follows:
In Web Dynpro all sorts of standard objects like buttons, tables, text boxes are defined that have standard behavior. These objects are grouped into patterns that can be reused, like the pattern of a list of records and then the display of the detail of one record. Standard services are defined at all levels, and the UI designers jobs is to assemble the right user interface from these patterns and to build new specialized pages or new reusable patterns as needed. The following diagram shows the sorts of services that might be part of the interaction of one sort of UI pattern.

Figure 4: Assembling services for the creation of an UI pattern
The beauty of using an abstract model to define a UI is that one can then render that UI into many different forms, HTML or Java Objects, or interfaces for mobile devices. Programming is still required in this paradigm but to a far lesser extent than is the cast today. One of the key principles of the next generation of SAP technology and applications will be the use of such executable models at all levels.
Enterprise Services Architecture is the theory of exposing the functionality of applications as services. An Enterprise Services Architecture platform like SAP NetWeaver brings this theory to life and allows existing enterprise applications to expose their services for use by PCAs (xApps) or for other sorts of development. The Enterprise Services Architecture platform also allows the functionality of platform component systems like content management or business warehouses to be used by developers.
What happens in an Enterprise Services Architecture platform like SAP NetWeaver is that application designer create components out of services offered by enterprise applications and by platform component systems. These components can then be reassembled in different formations to create new applications. Composite applications like xApps and other programs are built from these components as shown in the following diagram.

Figure 5: The user interface interacts with components that combine functionality from a variety of source systems
As the diagram shows, the user interface no longer interacts with the application that controls the database, but rather with components that combine functionality from a variety of source systems.
The sum total of all of the plumbing surrounding PCAs is that the designer now will have a much more power. Spiderman teaches us that with great power comes great responsibility.
The power will come in the form of the answer "Yes" which will be given much more frequently when designers ask programmers if this or that function is possible. Because so much will be possible, the designer's responsibility is to get the user interface right, which may be more difficult in an environment that is less constrained than in one in which only a small amount of choice is possible.
More responsibility will come in the form of being required to search for patterns that can be reused within an application. The most generic patterns were discovered by 30 years of experience with enterprise applications. Each new application will likely produce more patterns that will either be local to that application or perhaps will become common throughout other non-related applications. At some point, no doubt, designers will become famous for discovering useful patterns.
Designers will be challenged to construct seamless user interfaces that reflect the power of the PCAs to merge the boundaries between documents, collaboration, and business objects and to enable generic services such as discuss, vote, attach, share, publish in a way that does not overwhelm the user with complexity.
Perhaps the most difficult responsibility will be for designers to understand more deeply the processes and related services that enable their automation. Each role for which a user interface is being designed will no longer be just the master a set of database fields, but with rather be a participant in a more complicated interaction. Understanding these processes and how to represent them will be much more challenging that laying out fields on a page, and again, it is designer's responsibility to make sure that the process orientation is faithfully represented to the user.
Dan Woods (2003). Packaged Composite Applications. O'Reilly & Associates. ISBN 0-596-00552-0