Gartner
Technology, T-19-6157 B. Wood, J. Comport
Research Note
9 April 2003
Packaged Applications Meet Service-Oriented Architectures Evaluating a packaged application must start with an assessment of how well it can work within a service-oriented architecture. Examining the underlying architecture is the best starting point.
Service-oriented architecture (SOA) in packaged applications has emerged by accident (see Note 1). It is driven by the need for modularity and integration, and to limit the disruption to a package's internal architecture. No packaged application more than three years old has been designed as an SOA from the ground up. The design has focused on business process automation within the functional boundaries of the application. Integration has been an afterthought in response to a persistent — and mostly annoying — market requirement.
Whether deliberate or not, SOA benefits application users and vendors. It increases application flexibility, configurability and the ability to compose composite, process-based applications from the components of SOA-based applications, while decreasing the cost of customization and maintenance. To take advantage of this agility, enterprises should be sure to include this aspect of applications architecture in their selection criteria.
Packaged application architectures and SOAs are beginning to converge, but vendor and user objectives are still distinct. Vendors seek to be good "architecture citizens" while still trying to assert architectural control; users would rather keep the control for themselves and want applications to be stable services that minimize the drag on non-service-related vendor infrastructures. Meeting business functionality requirements is still the main focus, but users should begin to focus on the ability of packaged applications to be part of a flexible and robust SOA. In evaluating packaged applications, enterprises should consider:
• Service granularity. Granular service sets often lack context and require too much composition to create a useful business process. Services that are too coarse are like a Core Topic
Application Integration and Middleware: Architectures and Patterns for Software Infrastructure
Key Issues
Which technologies will enterprises strategically adopt to implement their software infrastructure?
How will changes in software infrastructure architectures and emerging patterns influence vendor strategy and the evolution of the software market?
Note 1
A Brief History of Service-Oriented Architecture
By the late 1990s, two-tier client/server architecture had given way to designs based around application servers. Modularity, reusability and the ability to upgrade gave rise to object-like designs and looser coupling between application elements. The design objective was to increase application configurability. This would allow for the recombination of modules for alternative packaging and industry applications. Little thought was given to externalizing these messages and bindings. As integration requirements have intensified, data-oriented approaches have been supplemented, first with callable interfaces and, more recently, with fully wrapped service structures. Only now are broader requirements being absorbed for service and composite applications, based on a fusion of business processes (see "New Applications Emerge — Business Process Fusion," T-19-4028).
black box, in that the inner workings are hidden and unalterable.
• Service representation. Service standards maximize service comprehension and interoperability. Examples are Web Services Description Language (WSDL), Business Process Execution Language for Web Services (BPEL4WS), Simple Object Access Protocol (SOAP) and Web Services Flow Language (WSFL).
• Service definition stability. Although service interfaces may be "self-describing," definition stability across releases and upgrades increases the ability to rely on services, and limits the aftereffects that occur when definitions change.
• Service production. Common general application configuration tools and service creation tools avoid rework that would occur through duplicate definitions. Tools should compare with service-oriented development of application (SODA) toolsets or, ideally, enterprises should use a commercial SODA environment.
• Service consumption. This is the degree to which a packaged application uses services as peers with package-specific functions. Do external services participate equally in workflow, user interfaces and business calculations? Are data and process flows bi-directional?
The way vendors approach the market prior to SOA participation is the best indication of how they will approach services and is the best starting point for evaluating application vendor SOA. Three categories of market and architecture approaches have prevailed: Enterprise suites, application frameworks and best-of-breed solutions (see "Which Style of CRM Application Is for You?" DF-18-9639). The characteristics for evaluating each category differ.
Vendors should have a clear understanding of their own enterprise nervous systems and the "city plan" (conceptual blueprint) that they will be using to ensure compliance with the rules for an SOA environment (see "See Enterprise Architecture and IT 'City Planning,'" COM-17-2304).
Enterprise Applications Suites
Enterprise applications suites, such as those from Oracle and SAP, are seeking to own more and more of an enterprise's business processes. As a group, suite vendors are most challenged by granularity decisions and service production environments. Often, granularity choices have not been designed from a business requirement perspective, but from one of technical convenience that is either biased toward exposing
everything or revealing almost nothing. This approach makes enterprises' applications suites better consumers of services than producers of services.
More serious work on service production is now being carried out. Major suite vendors have invested in development tools that predate any requirements for service representation of function and data. Service production is from multiple development environments. This is the area where enterprises can expect the most convergence and upheaval.
Suite vendors are starting to include knowledge management, content management and business intelligence functionality as part of the underlying infrastructure. This is in addition to providing portal applications as Web service consumer platforms within the SOA, and integration brokers and application servers as provider platforms.
Also, most suite vendors are providing extensive business process management capabilities that include services and components from within the suite, as well as from external applications. For the most part, these business process management functions are also provided using proprietary technology and protocols, but all major enterprise suite vendors have indicated that future releases will support emerging Web services process standards, including BPEL4WS and WSCI. Enterprises should choose whether enterprise suites will merely participate in the SOA — like any other application — or if the suite's extended infrastructure elements will be adopted as corporate standards. This includes, but is not limited to, the suite's portals, integration brokers, and process and workflow-enabling technologies.
Application Frameworks
Unlike suites, framework applications such as those provided by Chordiant, Graham Technologies and PegaSystems focus on components that can be included in process-oriented composite applications. Framework applications also include an application infrastructure that facilitates the development of adaptive solutions.
The framework itself is, in most cases, proprietary and has been extended by adapters and connectors. These allow the developer to integrate additional components and services using standards-based protocols such as Web services. This infrastructure layer often provides capabilities such as audit and transaction file logging, store and forward, and security features
that are not necessarily supported by open standards-based approaches.
Many framework vendors have the advantage of largely pre-integrated components that external applications can access through the framework infrastructure. While the services provided by the framework will be based on common data structures, semantic reconciliation will still need to be addressed when integrating external applications and services.
Application framework vendors also provide business process management capabilities with various levels of sophistication, but these are often wrapped in the proprietary infrastructure already described. This business-process approach generally means that services granularity in framework applications is better than that of suites. Like suite providers, framework providers are acquisitive. Accordingly, they have focused more on service consumption than production. Often, the proprietary nature of framework tools is very different to SODA environments. This results in either a separate development environment for services or a multistep evolution of the framework development environment toward SODA.
Best-of-Breed Solutions
Best-of-breed vendors, such as i2 and SalesLogix, have always recognized that their products were components of a broader portfolio. Accordingly, their priority has always been to help lower costs through integration. But, their approaches to integration have mirrored market evolution, moving from data-oriented integration, through application programming interfaces toward services.
Best-of-breed vendors do not have the capital resources of the mega-suite vendors. The rapid succession of multiple generations of integration and component technology sap resources and have kept best-of-breed vendors from emerging early as clear component winners. Instead, they remain contenders, disadvantaged by the larger resources and platform controls that their bigger competitors possess. Even so, enterprises should consider best-of-breed solutions as a source of components or services that will participate in the business process supported by SOA. It's key to evaluating the methods and protocols that best-of-breed solutions require for integration into process-oriented, composite applications.
Enterprises should pay special attention to viability and the ability of the best-of-breed vendor to remain independent. Acquisition by a mega-vendor that is not aligned with your enterprise
strategy usually leads to deterioration of the application's fit and, ultimately, to its replacement.
Packaged application vendors are not alone in rapidly adapting their products to comply with SOA principles. The traditional, message-oriented middleware vendors, integration broker-suite vendors and business process management vendors are all vying for their share of enterprise SOAs as well. Enterprise architects and planners should determine which of these technologies are appropriate and acceptable, and under what circumstances.
What Will Happen Next?
At the heart of SOA applications' use is the desire to make business processes more broadly accessible by wrapping them as services. By 2008, more than 75 percent of business process definitions will be visible and configurable from outside the underlying applications (0.7 probability).
As well as adapting existing applications to SOA, new kinds of application may emerge as SOA takes hold. There will be applications that are packaged and sold as service libraries — as Microsoft's MyServices was going to be. SOA-based applications will have an advantage over older applications. They will be more easily and cost-effectively integrated into the composite, process-based applications that enterprises are considering. This may cause some market realignments as a result of increased ease of entry for best-of-breed vendors. For service library applications, new vendors may emerge and displace old ones because SOA is more maintainable and can be composed better than traditional monolithic application architectures.
Enterprises should evaluate these new vendors for the functionality required in their composite applications, while at the same time weighing long-term viability against any competitive advantage they might gain.
Bottom Line: Enterprises evaluating packaged applications should examine closely how well those applications can participate in a service-oriented architecture. If these applications are not capable of exposing business objects and processes as Web services, the enterprise should consider alternatives. Enterprises that have significant investment in a vendor's applications and associated development skills should also evaluate the vendor's infrastructure components in the context of the enterprise's overall architectural standards.
Acronym Key
BPEL4WS Business Process Execution Language for Web Services
SOAP Simple Object Access Protocol
SODA Service-oriented
development of application WSDL Web Services Description
Language WSFL Web Services Flow
