In a new survey by AMR Research, it has been revealed that although SOA/BPM tools are maturing rapidly, companies focused on adding unique business processes to their enterprise applications will find major differences in complexity and development effort between the vendors and must plan accordingly.
AMR said in its report that the major platform and applications vendors have been hyping the benefits of service-oriented architecture (SOA) for several years, but most of manufacturing and retail firms did not know what was SOA. It goes on to add that unlike most of the SOA pioneers cited as references by vendors, manufacturing and retail companies, interested in exploiting that investment and not developing custom software, have built an IT landscape around a major ERP suite, such as Oracle E-Business Suite (EBS) or SAP. For these companies, the value of SOA will be found in business process management (BPM), which promises to allow companies to create unique and differentiating business processes on top of the same software many of their competitors use.
To meet this promise, these tools must allow business analysts and developers to collaborate closely on developing and iteratively improving the new business process. In order to effectively assess SOA/BPM toolsets, AMR Research presented the major vendors with a supply chain business process and asked them to show us how their tools would be used to implement it.
Here’s what the report said:
Many roles, skills, and tools are needed throughout the SOA/BPM development lifecycle.
Three distinct models for linking SOA and BPM will affect collaboration and continuous improvement.
Ease of development varies as vendors continue to integrate and rationalise their suites.
The depth and breadth of tools needed depends on your company’s SOA strategy.
Catalogs of standard services, now in their infancy, will be critical for widespread adoption.
ERP vs. non-ERP: choosing an SOA framework depends on maturity as well as your strategy for applications and development outside ERP.
AMR Research further states that many roles, skills, and tools are needed throughout the SOA/BPM development lifecycle. Few who have studied SOA and BPM to any degree believe that business analysts will be able to sit down and imagine a new business process, sketch it out, and push a button to put it into production. A whole range of skills is needed for different parts of the problem. These different skills need different tools and representations of the process and underlying services. A key issue is minimising the number of people and length of time needed to develop and change applications to implement a business process. Achieving this helps realise the core promise of SOA and BPM: greater business process agility.
It said that to make SOA and BPM successful, three distinct models for linking SOA and BPM would affect collaboration and continuous improvement. Given that BPM will be the centre of the SOA effort, the collaboration of the business analyst and process/service architect is critical. The business analyst’s scope is often larger than the technical implementation of the process. It may include documenting the business strategy and linking high-level business processes to it. The business process may include manual steps not covered by the IT-based systems.
• Waterfall model—This approach exports the business process model from the business analyst’s tools and imports it into the development environment. This oneway process resembles the traditional waterfall software development model. The downside of this approach is that further changes or improvements to the model need to be managed manually on both sides to avoid divergence over time.
• Synchronised models—Both sets of tools share a common portion of the model, while each side’s model can carry additional information not needed by the other. Enough context is maintained so that a change made on either side synchronises with the other, albeit flagged to be evaluated. This approach allows very rich tools on each side to provide more scope up into the business and down into the programming world, all while allowing for continuous improvement.
• Single model—In terms of simplicity, this is the most attractive approach. There is a single model, but different specialized tools can be used by each role to work on it, which provides both the business analyst and process/service architect a different level of detail on the same process. The only downside to this approach is that the business modeling environment is not as rich as that found in a tool like ARIS, though most of the single-model BPM products could import from ARIS, Visio, BPMN, or other models as a starting point for developing the technical business process.
Ease of development varies as vendors continue to integrate and rationalise their suites SOA and BPM vendors did not start out delivering full-fledged suites. These products evolved from earlier integration tools and grew by acquisition or new development of suite components, especially BPM.
At the same time, the vendors feverishly keep their products up to date with existing and proposed web services and business process standards, all tallying the number of standards committees they participate in and chair. Finally, they are integrating all of the various tools into a common development framework, usually based on the open Eclipse standard, to more easily keep various parts of a project consistent and reduce development effort.
ERP vs. non-ERP: choosing an SOA framework depends on maturity as well as your strategy for applications and development outside ERP
Whether or not it is their primary choice, Oracle and SAP customers will need to use some of their ERP vendor’s SOA framework for customization and integration of their applications. The question will be whether they introduce one of the other vendor’s frameworks into their environment as the primary foundation of their SOA and BPM strategy.
The most likely candidates to use something besides their ERP vendor’s framework are companies that already have a significant deployment of another vendor’s technology.
For example, SAP customers that have been using webMethods for integration and B2B e-business may not select SAP as the primary platform. Moving up to webMethods’ BPM tools would have a lower learning curve and is currently a more integrated development environment. Companies that use ERP purely for back-office functions and have other vendors or custom applications for customer-facing functions also may not choose that ERP vendor’s platform. If IBM, TIBCO, or BEA Systems is already widely deployed for website development, integration, or software development, it may be easier to extend that investment for BPM. |
