In this specific area is where many manufacturers face the dilemma of being entirely project-based in their manufacturing and business strategy approach or move more towards functional manufacturing with the exception being mass customization and a more fluid, agile, quote-to-order process. Figure 1 shows this dilemma graphically. Source: LWC Research

Figure 1: Manufacturer's dilemma regarding mass customization and channel implications of integration

Underscoring the synchronization of ESB hubs and accompanying use of state engines to unify channels and ensure complex processes including order-to-cash, inquiry-to-order, inquiry-to-cash, and many others. The span of integration that manufacturers are achieving with ESB platform integration in support of these core business processes is also illustrated in Figure 2, an example of a Brokered ESB Pattern Model, from Redbooks (2005).

Figure 2: An example of a Brokered ESB Pattern Model

Source: IBM Corporation 2005

What is significant about the Brokered ESB Pattern Model is the applicability it has specifically to distributed order management and distributed process functions throughout the many indirect and direct channel relationships manufacturers rely on for staying aligned with demand and selling. The focus of the Brokered ESB pattern is ideally suited for many manufacturers in that its architecture aligns perfectly with the approach manufacturers use for managing their many channel relationships in that this model separates integration logic and business roles from the ESBs themselves, according to Redbooks (2005). This architectural delineation of the Brokered ESB Pattern Model is congruent with the structure of the constraint engines discussed elsewhere in this thesis, specifically in the differentiation of rules, constraints and logic on one layer of the model and data on another. Constraint-based configuration engines and optimization engines including those from Fair-Isaac with their Blaze technology further support the concept of relying on a distributed approach to separating logic and data into a more agile architecture than one where logic is directly tied to data.

Implications of Visualization Grids on ESB in Manufacturing

Workload, platform, and information visualization strategies as they relate to the integration of ESB hubs across global manufacturing operations are critical for the growth of real-time integration with channel partners and the growth of exchanges. Figure 3 provides an illustration from IBM in their Redbook (2006) that shows a Grid Access Composite Runtime Pattern.

Figure 3: Grid Access Composite Runtime pattern

Source: IBM Corporation 2006

Notice from the Grid Access Composite Runtime pattern that the use of multiple approaches to workload, platform, and information visualization separates logic structures from data stores, and in the process also accomplishes integration across multiple ESB synchronization points and also allows architecturally for the development of a series of state engines that serve each specific strategy area. An example of this type of usage within visualization for the synchronization of order state engines would be the deployment of global order management systems across a series of manufacturing centers located in geographically diverse and distributed locations. The focus within Redbook (2006) specifically on the coordination of workload, platform, and information visualization is closely tied to the coordination of ESB architectural interlinking and the ability of manufacturers to significantly increase their performance on key performance criteria over time.

IBM's extensive work specifically on WebSphere but more globally on the issues of providing analytics as part of a strategic SOA strategy are well defined in many books published by IBM including IBM Workplace for Business Strategy Execution (2006) which details the structure of the framework of IBM's approach to integrating analytics into BPEL-based in addition to BPEL4WS, and area that IBM continues to provide thought leadership in as is evidenced with several major developments in the definition of standards of the integration of Web Services and BPEL-based process workflows. IBM has also published a roadmap specifically in this area that is found on their website, IBM Developer Roadmap (2006).

The major focus of much research in BPEL4WS specifically and BPEL in general is in the quantifying of business value over time of modifying processes permanently and with key performance indicators attached to the change in performance. Elsewhere in this thesis there are many examples of key performance indicators that quantify the impact of re-engineering, more precisely aligning, and making more efficient critical customer-facing processes including quote-to-order, inquiry-to-order, and inquiry-to-cash. The quantification of the gains found in these processes have been quantified and in Figure 4, which shows the approaches IBM is using in the context of their WebSphere Series of applications to provide business process modeling tools that also deliver...

Figure 4 provides this specific workflows area, showing how the integration of financial reporting and business process redefinition and its quantified result. The quick read-outs on the percentage completed against each task in an objective is also shown. IBM has specifically designed this approach to align with the needs of business analysts vs. programmers. This type of programming environment and its pervasive use by business analysts is a primary reason for IBM acquiring FileNet in 2006, a company that has continued to expand out its expertise in the areas of Business Process Management and its associated modeling and design applications.
Figure 4: Combining BPEL4WP and Key Performance Indicator Financial Performance

Source: IBM Corporation 2006

The need for analytics and the quantification of performance relative goals is at its essence one of the major if not the most major driver there is for manufacturers to embrace SOA strategies, and with them, ESB architectures and the growth of BPEL4WS workflows. The collaborative effects of all these technologies must be measured in many manufacturing companies, as they have specifically been planned for, deployed, and monitored to have a major impact on the ability of the company to compete and grow globally. Accountability over SOA strategies is core to the development of any lasting strategy, and both ESB and BPEL4WS, in addition to XML integration, are all critical components. All must be focused on measurable and quantifiable objectives however to earn a strong Return on Investment (ROI). This new era of accountability was exacerbated during the last recession, when many manufacturers failed to accurately measure the performance of their internal strategies on external performance. As a result of these factors and the meteoric growth of XML as an integration standard that connected previously isolated and often legacy systems with each other, dashboards have become commonplace throughout many manufacturing companies. it's important to keep in mind that despite the fact that many manufacturers still operate using Microsoft Excel as their primary means of communicating results. Using the structure of ESB in conjunction with SOA architectures including WebSphere, dashboards are starting to increasingly be used throughout manufacturers' divisions. Figure 5 shows an example of one manufacturer's dashboard. The programming and XML integration necessary along with the BPEL4WP-support process workflows are all governed by and aligned with the key business objectives the manufacturer is looking to accomplish. The need for real-time integration is clear from the read-outs within the dashboard as well, given the need to quickly correct direction in the context of demand sensing and overall market feedback.

Figure 5: An Example of a Manufacturing Dashboard

Source: IBM Corporation 2006

The underlying analytical framework that IBM's SOA approach relies on for delivering analytics is defined in the document IBM Workplace for Business Strategy Execution (2006), specifically including a hierarchical model that shows the strategic role of analytics, collaboration and enterprise application integration in the context of Portlet Factories delivering apps for use in WebSphere Portal Server, culminating in the Dashboard Framework and its presentation layer, the IBM Workplace dashboard. Figure 6 shows an example of this specific hierarchical model.

Figure 6: IBM WebSphere's Hierarchical Model

Source: IBM Corporation 2006

ESB as the Catalyst for attaining the Perfect Order

There are more than enough measures of performance to include in any scorecard, as can be seen in the previous section of this thesis. Manufacturers relying on SOA often over-measure every aspect of their performance, especially when it relates to measuring the accuracy and efficiency of their order management and fulfillment requirements. This is especially true in the context of the Perfect Order, which is a supply chain key performance indicator (KPI) that specifically measures the synchronization of and use of the many supply chain systems in addition to order management, fulfillment, pricing, and production. The Perfect Order as a metric is also being actively used by those manufacturers who have been early adopters of SOA-based strategies in conjunction with product customization and build-to-order approaches of managing and responding to demand.

Table 2 lists the most common measures of performance that LWC Research (2005) has seen manufacturers use to attain their objectives of increased business process performance in the context of their mass customization selling and production strategies.

These are the most common problem areas that serve as obstacles for manufacturers looking to attain the Perfect Order.

The adoption of ESB infrastructures and their propagation throughout an enterprise specifically to provide for loosely coupled ESB framework is what's working for manufacturers including General Electric, Proctor & Gamble, and others…