Creating Composite Applications to Capture
Adapting to and Leveraging Technology Innovations
The pace of innovation across industries is rapidly accelerating — particularly in supply chain processes, and systems or architectures. For almost 20 years, supply chain architectures were stable and monolithic — untouched by radical change. The adoption of containerized shipping in the late 1960s, bar codes in the 1970s, and MRPII in the late 1980s were the major disruptive innovations, basically one per decade. In contrast, the advent in the 1990s of the Internet and outsourcing increased the pace exponentially. Recent technology innovations like radio frequency identification (RFID) will fuel more radical business process transformation in areas such as self check-out and scan-based trading. And now a look forward reveals the potential for an even greater acceleration in the pace of innovations — both revolutionary and evolutionary.
When confronted with innovations, organizations choose to differentiate or emulate, that is, lead or follow. To differentiate, a business must move extremely fast. Wal-Mart differentiated itself in the early 1980s with bar codes and computers, while other retailers were still using optical character recognition (OCR), typewriters, and forms in triplicate. Today Gillette is moving quickly to adopt RFID, as evidenced by the company's recent purchase of a half-billion RFID tags.
The decision of whether to lead or follow should be made based on customer needs. If the innovation in question will positively impact the customer experience, companies should then think seriously about leading. While there is some perceived risk in leading, the benefits of "first winner" economies are compelling. If the innovation does not significantly improve your ability to meet customer priorities, than you should choose to follow so you can free up management attention on what does matter. If you choose to follow, you should do it efficiently and as quickly as possible within the context of your resource priorities.
Either way — differentiate or emulate — the business needs to adapt (see Figure 1). While many businesses have focused solely on adaptable IT infrastructures, the real focus should be on both adaptable infrastructures and business processes. Why? Your business is your business processes — not your products or services. In fact, the most successful and progressive companies adapt customer-facing business processes for each and every customer, thus providing custom pallet configurations, custom packaging, and customer-specific shipment windows, for example.
Figure 1: Rapid incorporation of innovation requires business process adaptation.
Source: BEA Analysis
The challenge is that business processes are not flexible, because they have been inexorably tied to inflexible enterprise applications that do not adapt easily. Many companies compete and differentiate solely on the basis of customer intimacy, adapting each process to fit unique customer needs. These companies have made large investments in IT to achieve this intimacy. Ironically, this area has been strongly impeded by these IT investments, especially the monolithic enterprise resource planning (ERP) infrastructure laid down in the late 1990s. Unfortunately, in continuing to use this infrastructure and application functionality in the same way, companies are losing the ability to differentiate with business process innovation.
Fortunately, not all process innovations require costly radical architecture and system overhauls. In fact, companies experience both revolutionary innovations such as bar codes and Internet and evolutionary innovations such as client server and J2EE. Many companies get caught in the trap of exclusively focusing on revolutionary, or disruptive, innovations. In doing so, they often go through periodic and dramatic system re-architectures to realign their systems to customer requirements. While they are able to achieve some semblance of alignment for a brief period of time, these brittle architectures are far from being malleable enough to capitalize on these evolutionary opportunities. Most companies are late to market with process innovations because, with the time, effort, and cost required to change a business process, the window of opportunity has closed (see Figure 2).
Figure 2: Companies are challenged to incorporate revolutionary and evolutionary
innovations.
Source: BEA Analysis
The challenge then is clear: Working within a tight timeframe and with existing IT assets, business must quickly differentiate with end-to-end enterprise business processes built on an adaptable foundation, enabling processing efficiencies, responsiveness based on information access and real-time visibility, and rapid adaptation to technology innovations and changes in the marketplace.
In moving from an environment where IT infrastructures are monolithic and inflexible to IT that is efficient, responsive, and adaptable, companies need to consider the following questions.
- What in the enterprise IT architecture makes it so difficult to rapidly change business processes?
- How can companies establish the flexibility needed to continually adapt their business processes to maintain competitive differentiation?
- How can companies rapidly assemble a new kind of application, leveraging — not disrupting — existing processes and applications for better collaboration with trading partners and customers?
Existing Applications: Making Process Change Difficult
What then in the enterprise IT architecture makes it so difficult to rapidly change and reuse business processes? Three key challenges — the ERP backbone with its inflexible architecture and embedded business logic, a single architecture style when the functionality of many is needed, and the lack of business-to-business coordination across disparate, heterogeneous enterprises — make transforming business processes difficult.
Enterprise Resource Planning Applications
In the late 1990s, the threat of mass system failure due to Y2K technology gaps created a mad dash to replace legacy systems. Given the tight deadline, most companies did not have the time to create a flexible foundation. Executives viewed the prospect of a single, unified closed system as a safe haven, compared to the alternative of outright system chaos. While ERP was a significant improvement over the tangle of existing legacy applications, it still did not solve the central challenge — providing companies with the ability to adapt.
Enterprise applications, especially ERP systems, were built in a way that limits flexibility. ERP infrastructures resemble concrete, semi-flexible systems before implementation and become completely brittle once implemented. As most implementation consultants have experienced, there are definite bounds to the configurability of prepackaged business logic. The small amount of logic that is configurable through business rules is often buried so deep that it can only be accessed by system surgery. Why? The initial designers of ERP accounted for process change as a one-time event, completed at the time of implementation. They never intended to facilitate dynamic business user access to business logic and business rules, so users could reconfigure their processes to match the real-time market.
In response to this rigid process-definition limitation, applications vendors intended, in good faith, to define processes that matched the best practice in industry. There are two problems with this approach.
First, best practices continuously evolve. What may have been leading-edge when the application engineer designed the application will now, most likely, be out of date. For example, supplier splits have been adopted recently in the high-tech industry as a strategic sourcing best practice to foster supplier competition and mitigate supply base risk. The sourcing modules of many enterprise applications may not support this best practice. A company with a single ERP philosophy will not be able to adopt this practice until it upgrades to the next release, if indeed that release happens to include this support.
Second, best practices most definitely differ by industry. For example, trade funds management processes at leading consumer goods companies differ considerably from the channel interactions at a high-tech manufacturer. If they both adopt the same single ERP core philosophy, they will essentially be confined to the same business process that does not necessarily accommodate their different channel-management processes. It is no secret why supply chain visionaries such as Dell or Wal-Mart have not standardized all their processes on commercially available ERP cores.
Architecture Styles
While the deep embedding of business logic hinders business process changes, the IT system architecture can constrain business adaptability as well. Actually, different business processes require different combinations of architectural styles and related computing performance levels. According to the Gartner Group, business processes are supported by five key architecture styles — high- volume transaction processing, real-time operations, analytical and business intelligence, collaborative, and utility.
A manufacturer or retailer, for example, might need to support components of several styles in the following way:
- High-volume transaction processing for order management interface.
- Collaboration for interaction with small suppliers who will interface
with supplier portals to receive drop-ship orders.
- Real-time operations for filling those order lines being built at the factory floor.
Yet supporting architectures are often embedded in enterprise applications, as is the case with today's closed, proprietary ERP applications, thus further complicating process adaptation. Then, not only do businesses have to deal with business logic changes but also underlying architecture changes.
In addition, to their detriment, many companies build competencies only in the architectural style of the most dominant enterprise application provider. This focus leads to poor performance for business processes that leverage other architecture styles, often inhibiting growth in areas of the business dependent on these overlooked processes. Or sometimes the most dominant business processes is supplanted, and the new business process is based on the old architecture.
This second scenario often occurred when manufacturers decided to leverage the Internet and bypass distribution channels to engage end users directly, resulting in dramatic increases in the number of transactions that the old architecture could not handle well. This scenario is playing itself out again as vertically integrated apparel retailers face stiff competition from Zara, which is currently bringing to market more than 10,000 items a year with a blazingly fast lead-time of less than a month (Source: AMR May 2002). Most vertically integrated apparel retailers have staked their supply chain competitiveness on detailed forecasting and planning processes, which leverages an analytical and business intelligence architecture style. They may face some substantive issues with their existing IT architecture strategy, if competing with companies like Zara means establishing real-time response to consumer buying behavior with immediate replenishment, leveraging a much more real-time operation architecture style.
Obviously, what is required is the ability to first separate business process from architecture, which is currently embedded in most conventional enterprise applications, and then to establish a flexible application infrastructure platform that can support all necessary architectures.
B2B Collaboration
With the advent of the Internet, more and more companies are recognizing the need to collaborate with their customers and suppliers. This need intensifies when companies outsource business processes. In outsourcing business functions, mission-critical business process can easily span two or more enterprises, requiring exceedingly tight communication and coordination. For example, a high tech manufacturer may not own the complete bill of materials (BOM) when it outsources manufacturing. Yet, the manufacturer may still own excess and obsolete inventory liability. Given the example of $2.2 billion in collective inventory write-offs announced in 2001 by Cisco, one of the world's most successful outsourcers and supply chain practitioners, most CFOs would want to monitor this liability closely. Without a complete BOM and the capability to run MRP, however, they need to establish tight collaboration with their outsourced partner to execute a single business process and have views into supply excesses and shortfalls. This level of process coordination is difficult to achieve, since the manufacturer will never have complete control over the partner's architecture supporting the unified process.
Multiply this scenario times 10 outsourced partners, all with different process steps and B2B grammars, for example, and you have the current state of B2B collaboration for a high-tech manufacturer. Yet since B2B processes do span multiple enterprises, companies will need to somehow mutually coordinate their activities by connecting their disparate, heterogeneous system environments to enact meaningful process change.
Transforming Business Processes for Competitive Advantage
How can companies establish the flexibility needed to continually adapt their business processes to maintain competitive differentiation and collaborate with trading partners?
Companies must realize that the processes that they need to amend span internal functions and external enterprises and will rarely be contained within a single application. Instead, companies should focus on separating processes from applications. Making embedded business processes explicit tends to make an accessible and flexible system. Similar improvements in system flexibility and resiliency were established when operating systems and data management (DBMS) were separated from applications. Once business logic is abstracted from monolithic architectures, companies can assemble and recombine business processes into composite applications that fit specific customer needs. Building composite applications requires a platform approach that supports cross-functionality, application-component reuse, business-logic independence, and sophisticated business-process management (BPM) (see Figure 3).
Figure 3: End-to-End Business Process in Composite Applications
Source: BEA Analysis
Cross-Functional
Business applications were initially established in the early 1970s, when businesses were much more vertically integrated and function-centric. Although in the mid-1980s, the advent of MRP II and ERP added some process-centric enhancements, this incremental functionality was still anchored to organizational domains. Most applications installed today are constrained by this legacy approach. Best-in-class companies, however, are increasingly creating differentiation by establishing cross-functional processes such as order-to-cash, procure-to-pay, and concept-to-creation.
Application Component Reuse
Past monolithic infrastructures have been, for the most part, characterized by proprietary approaches. Since most companies have myriad custom, packaged, and legacy applications, whose total cost is enormous and whose familiarity is an advantage, they need to leverage and add value to existing applications and other IT investments rather than justifying more costly expenditures. New composite applications — built on top of existing application assets — can leverage a BPM framework. BPM coupled with application integration technology then can access the existing business logic within existing systems, freeing and reusing the logic to rapidly create new business processes and new applications.
Business Logic Independence
To maintain flexibility and support process innovation, businesses need to cope with a high velocity of business logic changes. In the current state, business logic is embedded in applications and requires extensive excavation to access and change it. While ERP systems do provide configuration tables that allow some configuration of processes, rule changes really are constrained within existing table parameters or require extensive enhancement to add new configuration tables. As companies evolve and applications portfolios age, the cost of rule changes goes up. In contrast, in composite applications, business logic is open and accessible to frequent changes. This independence is the main vehicle for separating processes from software logic, thus opening entirely new doors in business innovation.
Collaborative
The most intuitive component of a composite application is its interface. Composite applications need to aggregate information from many disparate data sources and assemble them in a single integrated view that is relevant for any process participant. This single integrated view is a requirement for executives who want to monitor the performance of the process, as well as managers who are called to action through events and alerts and need an easy-to-use, flexible interface for their input.
Rapidly Assembling Composite Applications on a Unified, Standards-Based Infrastructure
How can companies rapidly assemble composite applications, leveraging — not disrupting — existing processes and applications for better collaboration with trading partners and customers?
Without a unified approach and depending on the degree of change, rapidly assembling composite applications could be a complex transition with considerable effort and cost. One of the positive aspects of BPM platforms is that they natively support migration. You can establish a gradual and orderly transition, replacing one component at a time as needed.
The key is to adopt a standards-based but fully integrated platform combining both the functionality and the components needed to assemble composite applications. Thus, business process management, enterprise resource access, dynamic integration services, and an integrated design environment combined and unified on a single, open, standards-based platform can best enable the rapid assembly of composite, customer-centric applications.
Business Process Management
In today's world, process integration requires short-lived, "straight-through-processing" transactions, as well as long-running strategic business processes that span enterprises and take months. For example, in some complex manufacturing environments, an end-to-end, order-to-cash cycle can take six months with sub-processes created to communicate with suppliers and partners.
The intent of the BPM component is to provide a flexible architecture to allow companies to quickly adapt their business processes — whether short-lived or long-running. To achieve this process change, processes will need to be made explicit through language initiatives such as BPEL4WS. Process repositories must be built and stored for easy retrieval and modification, thus requiring rich support of business logic. In their evolution, application servers have supported this level of business logic for years. In fact, a process server can be thought of as an application server that supports more capabilities to deploy and manage business processes. To manage these process states, composite applications will require a sophisticated BPM engine as well as process modeling, process automation, and process analysis on one platform.
Enterprise Resource Access
With the new business imperative to reduce costs and improve effectiveness, executives must focus on continually aligning existing resources to customer requirements. The challenge not only lies in the reconfiguration of resources but in simply accessing them. New business processes cannot benefit businesses if there is limited or no access to enterprise resources. Companies whose objective is to lead or even keep up with the pace of innovation need to establish an infrastructure facilitating access to business users through portals, systems through enterprise application integration, or external trading partners through B2B integration.
While process automation is a key objective of BPM, business-user intervention into those processes also must be provided, especially in cases such as approvals and exception handling. Composite applications will need the capability to support users, groups, and roles separately, intelligently routing process tasks to the right person with the right skills at the right time — thus enhancing organization responsiveness. Composite applications will also need to access existing systems, from packaged applications to legacy applications to databases. Composite applications will certainly need to access external resources outside the organization, thus leveraging trading partner integration technology that supplies full document handling, protocol support, and secure messaging for leading standards — RosettaNet, ebXML, EDI, and Web Services.
Dynamic Integration Services
Web Services are a key enabler of composite applications and BPM technologies. Many of the steps in an end-to-end business process will be service consumers, which call a service producer through a Web Service interface. This loosely coupled connection between processes and services provides the ultimate flexibility in rapidly assembling new business processes from existing application assets. For example, if a manufacturer were to outsource fulfillment to a supplier, the existing order-management workflow could be amended to call the external supplier's available-to-promise engine.
While Web Services will provide much flexibility going forward, much of the existing business logic will remain embedded in legacy applications for some time. The embedded business logic will make it necessary to use a layer of integration services to access some enterprise resources. The integration services will be packaged as an integrated suite of several component parts. Adapters will deliver rapid access to packaged applications, legacy systems, mainframes, databases, and Web technologies. Message brokers will deliver high-reliability, asynchronous messaging for event-driven data flow inside and outside the enterprise. Data transformation will allow companies to map between different XML and non-XML message formats. And enterprise-class Web Services will facilitate loosely coupled integration between steps of an end-to-end process flow (see Figure 4).
Figure 4: Single Platform for Composite Applications
Source: BEA Analysis
Integrated Design Environment
In real-life integration problems, composite applications will require tight coordination of business process management, enterprise resource access, and dynamic integration services. Companies leading or swept up in the current pace of business innovation will need a single platform to orchestrate the development, maintenance, and frequent updates of all these components. The environment will need to support multiple contributors, with different skill sets and capabilities. An integrated design environment (IDE) provides this platform as a single point of interface for all the tools (BPM, portals, message broker, adapters, data transformation, B2Bi, and Web Services) necessary to rapidly enable industrial strength processes.
While the pace of innovations across industries will continue to accelerate, solutions to enable businesses to quickly adapt to innovation and unleash the power of their applications and best practices will be proven and rapidly adopted. Freeing business logic, separating businesses processes from applications, and reusing those processes to create customer-centric composite applications require an open approach — unifying business process management, enterprise resource access, dynamic integration services, and an integrated design environment on a single, standards-based platform. New composite applications will be instrumental in capturing the benefits of "first winner" economies. How? Clearly, composite applications built on these open, flexible, and adaptable infrastructures will extend the longevity of existing IT assets, while fostering and extending new kinds of collaboration and quality service at the right time, at the right place, and at the right priority between the people who need it — global workforces, partners, and customers.
