AMR Research Report May 2007 by Bill Swanton and Ian FinleyTe value oservice-oriented architecture (SOA), hardly a oregone conclusion, will be ound in business process management, which promises to create unique and dierentiating business processes on top othe same sotware that competitors use. Given this dierentiation, companies can and should pilot these tools now to gain experience. SOA and BPM or Enterprise Applications: A Dose oReality
Transcript
8/9/2019 Soa and Bpm for Enterprise Applications a Dose of Reality Tcm16-35176
AMR Research® is a registered trademark o AMR Research, Inc.
No portion o this report may be reproduced in whole or in part without the prior written permission o AMR Research. Any written
materials are protected by United States copyright laws and international treaty provisions.
AMR Research oers no speciic guarantee regarding the accuracy or completeness o the inormation presented, but the proessional sta o AMR Research makes every reasonable eort to present the most reliable inormation available to it and to meet or exceed any applicable industry standards.
AMR Research is not a registered investment advisor, and it is not the intent o this document to recommend speciic companies orinvestment, acquisition, or other inancial considerations.
Tis is printed on 100% post-consumer recycled ber. It is manuactured entirely with wind-generated electricity and in accordance with aForest Stewardship Council (FSC) pilot program that certies products made with high percentages o post-consumer reclaimed materials.
8/9/2019 Soa and Bpm for Enterprise Applications a Dose of Reality Tcm16-35176
SOA and BPM or Enterprise Applications:A Dose o Realityby Bill Swanton and Ian Finley
Although SOA/BPM tools are maturing rapidly, companies ocused on adding
unique business processes to their enterprise applications will nd major
dierences in complexity and development eort between the vendors and
must plan accordingly.
Te major platorm and applications vendors have been hyping the
benets o service-oriented architecture (SOA) or several years, but
most o our manuacturing and retail clients say, “SOA what?” Unlike
most o the SOA pioneers cited as reerences by vendors, these com-panies, interested in exploiting that investment and not developing custom sotware, have
built an I landscape around a major ERP suite, such as Oracle E-Business Suite (EBS)
or SAP. For these companies, the value o SOA will be ound in business process man-
agement (BPM), which promises to allow companies to create unique and dierentiating
business processes on top o the same sotware many o their competitors use.
o 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 eectively 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 we ound:
• Many roles, skills, and tools are needed throughout the SOA/BPM development liecycle.
• hree distinct models or linking SOA and BPM will aect collaboration and
continuous improvement.
• Ease o development varies as vendors continue to integrate and rationalize their suites.
• he depth and breadth o tools needed depends on your company’s SOA strategy.
• Catalogs o standard services, now in their inancy, will be critical or widespread adoption.
• ERP vs. non-ERP: choosing an SOA ramework depends on maturity as well as your
strategy or applications and development outside ERP.
Companies can and should pilot SOA/BPM tools now to gain experience. Depending on
your chosen vendor, you might want to wait until the tools and services catalogs mature
over the next 18 to 24 months beore committing to intensive development on mission-
critical processes. You may nd it takes more eort than expected, and you may need to
rework the application to work with the next version o the platorm. In any case, we rec-
ommend companies begin their eort with small pilot projects in order to better under-
stand the potential o the technology and its process and organizational impacts.
Vendors eatured
in this Report:
BEA Systems
IBM
Oracle
SAP
TIBCO
webMethods
Executive
Summary
8/9/2019 Soa and Bpm for Enterprise Applications a Dose of Reality Tcm16-35176
1 Order Entry Gets customer request or rush order. I it’s rom a
“good customer,” request special order rom actory.
CRM, ERP
2 Factory
Scheduler
Inormation automatically ed to planning system,
which tries to nd a easible schedule. I not,
scheduler intervenes to propose alternate date.
ERP, plant
scheduling
3 Transport
Manager
Automatically tries to schedule transport in line with
new schedule. I not, scheduler interacts with logis-
tics provider’s system to try alternatives or propose
alternate date.
TMS,
3PL Web
Service
4 Order Entry Conrms new order to customer. CRM
5 Operations
Manager
Dashboard o order volume, percentage special
orders, and histogram o cycle times to conrm
orders (activity monitoring).
BAM, BI
AMR Research SOA/BPM scenario
Unlike companies in other industries that ocus on managing the cost and lexibility
o custom sotware and legacy applications, the goal or most manuacturers and
retailers is to enhance the value o their packaged applications. Table 1 shows thescenario we speciied or the vendors who took part in our study. It is a amiliar one in
the manuacturing and retailing world: deciding whether to accept a rush order rom
a customer based on capacity, transportation availability, and the value or strategic
importance o the customer.
Though some sotware vendors can accomplish this within their applications, most
companies use manual processes and multiple, heterogeneous applications to handle
rush orders. So, we created a scenario that required:
• The integration o sotware packages rom several vendors
• Access to data about the customer in a data warehouse
• Access to an external web service
• The combination o human worklow and automated processing and integration
While ew large-scale deployments combining BPM, SOA, and ERP exist today, we
anticipate manuacturing and retail companies will oten apply SOA and BPM technology
in this type o scenario in the uture.
8/9/2019 Soa and Bpm for Enterprise Applications a Dose of Reality Tcm16-35176
Many roles, skills, and tools are needed throughoutthe SOA/BPM development liecycle
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 o skills is needed or dierent partso the problem, as shown in able 2. Tese dierent skills need dierent tools and
representations o the process and underlying services. A key issue is minimizing the
number o people and length o time needed to develop and change applications to
implement a business process. Achieving this helps realize the core promise o SOA and
BPM: greater business process agility.
Source: AMR Research, 2007
Table : BPM roles and liecycle
Role Liecycle Stage Description
Notation/
Standards
Business Owner Business
Modeling
High-level description o
business goals and strategy.
ARIS
Business Analyst Business Process
Modeling
Describe specic business
process, roles, and inormation
at a user level.
BPMN, XPDL, ARIS
Process/Service
Architect
Technical Process
Modeling
Convert conceptual process
diagram into a more specic
executable construct; separate
human and machine tasks and
determine how to implement.
BPEL, XPDL
Service Modeling Describe/select services
needed to implement
business process on top o
existing systems.
BPEL, various
Service
Developer
Service
Development
Create necessary services rom
existing services, interaces,
data sources, and link to busi-
ness process model.
Various
Operations Service
Deployment
Deploy services or use. Various
Operation Execute the business process
and ensure service
perormance.
Various
All Business Activity
Monitoring
Monitor perormance o
business process and
systems.
Note: This is a composite o the various vendors’ models.
8/9/2019 Soa and Bpm for Enterprise Applications a Dose of Reality Tcm16-35176
SOA by denition needs services. Most BPM schemes try to approach the elusive
goal o codeless development by moving complexity rom within the application
into the services inrastructure—the SOA part o the solution. I the services are
available, stitching them together to orm a new or changed business process was a
relatively quick and straightorward aair in all the tools we evaluated. However,
the right services are oten not available. Te biggest variables in development timeand complexity were in making new services available that implemented the business
analyst’s intent.
Tere are several related issues to be evaluated:
• Is the service you need available from your applications vendor? SAP and Oracle
are starting to build out catalogs o standard services as part o their ERP suites, but
it will be several years beore this cuts across all unctionality. SAP and Oracle are
also making it easy to access their catalogs rom within their SOA/BPM toolsets, but
it is not clear how easy these catalogs will be to access rom the toolsets o other ven-
dors. (Note: we are using the word catalog here so it is not conused with the services
repository that holds both vendor-deined and user-developed services.)
• If a service is not available, a process/service architect must interpret the
business analyst’s intent and specify the service. o create a new service, a services
developer must then write code, use service composition tools to combine existing
services, wrap existing application programming interaces (APIs), and/or use data
access routines. Each vendor provided a range o tools here, including programming
aids, visual composition tools, and specialized tools or service-enabling data sources
and messaging middleware.
• Regardless of the source of the services, it is better to find them rather thanrewrite them. In a large enterprise with many projects and applications, a strong
services repository will be important because it enables services reuse in a controlled
manner. An SOA repository holds the development, deployment, and management
speciications or all the services available, enabling services to be created, used,
reused, modiied, and retired in a governed way. A key part o its job is to keep track
o what processes and applications are using a service, control access to the service,
and describe which applications will be aected by proposed changes to the service.
A good toolset provides the right level o interaces or business analysts, service archi-
tects, service developers, and systems managers, among others, while allowing them tocollaborate closely to iteratively create and improve the automated business process.
One note on architecture: there are several levels o architecture at play here. Te
process/service architect diers rom an overall enterprise architect, who worries about
the overall plan or systems, applications, and SOA. We expect to see organizational
design change as SOA takes hold and the process/service architect may be an
individual contributor within the larger enterprise architecture group.
8/9/2019 Soa and Bpm for Enterprise Applications a Dose of Reality Tcm16-35176
Three distinct models or linking SOA and BPM willaect collaboration and continuous improvement
Given that BPM will be the center o the SOA eort or the use cases we expect to
be deployed, the collaboration o the business analyst and process/service architect is
critical. Te business analyst’s scope is oten larger than the technical implementationo the process. It may include documenting the business strategy and linking high-level
business processes to it. Te business process may include manual steps not covered
by the I-based systems. ools, most notably IDS Scheer’s ARIS suite, are commonly
used here to dene and document the process, but not to execute it.
Te vendors we reviewed used three major approaches to taking a high-level process
denition and getting into an SOA development environment (see Figure 1):
• Waterfall model—his approach exports the business process model rom the
business analyst’s tools and imports it into the development environment. his one-
way process resembles the traditional waterall sotware development model. hedownside o this approach is that urther changes or improvements to the model
need to be managed manually on both sides to avoid divergence over time.
• Synchronized models—Both sets o tools share a common portion o the model,
while each side’s model can carry additional inormation not needed by the other.
Enough context is maintained so that a change made on either side synchronizes
with the other, albeit lagged to be evaluated. his 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 or continuous improvement.
• Single model—In terms o simplicity, this is the most attractive approach. here isa single model, but dierent specialized tools can be used by each role to work on it,
which provides both the business analyst and process/service architect a dierent level
o detail on the same process. he only downside to this approach is that the business
modeling environment is not as rich as that ound in a tool like ARIS, though most
o the single-model BPM products could import rom ARIS, Visio, BPMN, or other
models as a starting point or developing the technical business process.
Since relatively ew companies do rich modeling o their business processes, high-level
modeling tools may not be an important consideration or you. For extensive business
modeling to ensure that business processes implemented in SOA/BPM match themodel, understand what will be necessary to accomplish this with the vendor under
evaluation.
8/9/2019 Soa and Bpm for Enterprise Applications a Dose of Reality Tcm16-35176
Ease o development varies as vendors continue tointegrate and rationalize their suites
SOA and BPM vendors did not start out delivering ull-edged suites. Tese products
evolved rom earlier integration tools and grew by acquisition or new development
o suite components, especially BPM. At the same time, the vendors everishly keeptheir products up to date with existing and proposed web services and business process
standards, all tallying the number o standards committees they participate in and
chair. Finally, they are integrating all o the various tools into a common development
ramework, usually based on the open Eclipse standard, to more easily keep various
parts o a project consistent and reduce development eort.
Te development necessary to implement AMR Research’s SOA/BPM scenario showed
a marked dierence between the vendors. Te more integrated tools took two people
a day or two to build the demo. Vendors with the less integrated toolsets had to invest
signicantly more time and use more individuals with distinct skillsets.
able 3 shows the multitude o products each vendor uses to cover various aspects o
their SOA ramework (or more, see “A Framework Approach to SOA”). While the
vendors integrate the products technically, the marketing message oten moves ahead
o reality. Components may be rebranded under a common name, such as NetWeaver
or AquaLogic, but they remain separate products rom disparate organizations that
are working toward a common architecture. Several parts o a composite application
may need to be built separately and assembled outside the core tools and development
environment.
I we look at this rom the point o view o the tool used to develop business processmodels, able 3 shows in bold those components tightly integrated into a BPM
ramework. Te other products work with these models, but may be distinct tools
or rameworks. Tese disconnects will disappear over the next ew years. In the
meantime, evaluate whether the complexity these disconnects add can be managed in
your development organization.
8/9/2019 Soa and Bpm for Enterprise Applications a Dose of Reality Tcm16-35176
Note 1: Bold denotes components well integrated into the same development ramework as theBPM tools (more than common branding o component names).
Note 2 : Vendors use various terms, such as repository, registry, and composite application ramework quite dierently. Terms in lead column are defned in Table 3a or the purposes o this Report. The data under each vendor name is its component name that contains theequivalent unctionality.
8/9/2019 Soa and Bpm for Enterprise Applications a Dose of Reality Tcm16-35176
6.0.2 10g Release3 NetWeaver 7.0 (2004S) • iProcess Suite
10.5
• Business Studio
2.0
Fabric 7
Table : Summary o vendor SOA ramework components (continued)
Source: AMR Research,Note 1: Bold denotes components well integrated into the same development ramework as theBPM tools (more than common branding o component names).
Note 2 : Vendors use various terms, such as repository, registry, and composite application ramework quite dierently. Terms in lead column are defned in Table 3a or the purposes o this Report. The data under each vendor name is its component name that contains thequivalent unctionality.
8/9/2019 Soa and Bpm for Enterprise Applications a Dose of Reality Tcm16-35176
Table a: Summary o vendor SOA ramework components—notes
Topic Capability Notes
BPM
Development
Liecycle Model
See Figure 1, which describes how new business process and changes to
existing ones are communicated between business analysts, architects, and
developers.
User Interace General General tool or creating user interaces that can interact with the business
processes. Some vendors oer a tool closely integrated with their BPM tool,
while or some it is a separate capability linked through the SOA.
Workow Workow tool or creating sequential processes that are passed to people to
work on. Usually includes a simple orm builder, workow rules, and a stan-
dardized user interace or the worker’s inbox and interacting with the work-
ow items. This may be customizable or corporate branding, perormance
measures, etc.
Business Process Business Modelling High-level description o business goals and strategy.
BPM or Business
Analyst
Describe specic business process, roles, and inormation at a user level.
Simulation Simulate execution o the proposed business process to determine i there
are sufcient resources (people, etc.) and responsiveness to work in the real
world.
BPM or Architect/
Developer
Determine how to realize the business process, deciding which parts are
handled outside the BPM/SOA/IT and what tools will be used to implement
the rest. Select and/or model (or later development) the services needed by
the business process.
Rules Engine Allows common business decisions to be specied outside o the low-level
code and changed, especially parametrically, without changing the code.
Gives exibility to automated decision making by making it easy to change
as business needs change.
Business ActivityMonitoring (BAM)
Analyze event-based inormation to determine business process peror-mance. This can be tied to the process developed by the BPM tool or work
o general events to analyze the existing system beore dening the new
process.
Service
Development
Service Aggregation/
Composition
Developing services modeled by architect. Oten combining more granular
services or APIs into a higher level service that maps more cleanly to the BPM
level tasks. This level oten involves enterprise application integration (EAI)
tools, Java development, and other more technical tasks.
Data Services Specialized tool or creating services to access data. May be used to hide
complexities o multiple sources o data rom the higher level business pro-
cess. Useul when trying to build a single business process that may need to
access data rom multiple back-end systems depending on conditions.
Service Repository Development repository o all artiacts (services, user interaces, businessprocesses, data structures, etc.) used in the development ramework and
SOA environment. More advanced tools provide governance capabilities to
manage approval o new services, changes, dependencies, and access to ser-
vices by specic projects.
8/9/2019 Soa and Bpm for Enterprise Applications a Dose of Reality Tcm16-35176
The depth and breadth o tools needed depends onyour company’s SOA strategy
You may not need a toolset with high scores in all categories. In act, the highest
scoring vendors may introduce more complexity than you need, especially in categories
like services development and registry and repository. Critical in highly complex, very heterogeneous, high-volume, or extensive custom sotware environments, like banks,
insurance, or very large complex companies, many o these capabilities may not be
necessary or the use cases o a manuacturing or retail company. Look at the balance
o scores that best ts your environment and needs.
I you will be ocused on a ew rie shot processes and do not intend to deploy the
ramework broadly, a lighter weight toolset may be more appropriate. In act, two
o the vendors, webMethods and IBCO, stated that they could have accomplished
our scenario with only their BPM tools, oregoing the complexity o the services
composition and repository capabilities.
Catalogs o standard services, now in their inancy,will be critical or widespread adoption
While most o the evaluation criteria ocused on the unctionality o the rameworks,
content will be equally important in the long run. We don’t expect SOA and BPM
to be widely deployed i each company is orced to develop its own business services
rom scratch. In act, based on the work we see happening at Oracle, SAP, and IBM,
designing these services correctly is no easy task, requiring many people to work
together to design a single service that will work with many dierent use cases.
Te three companies urthest along take a very dierent approach to building their
services:
• SAP works with partners and customers as part o its Enterprise Services Community
to deine its services. It acilitates groups, especially industry-speciic ones, to write
speciications or new services. SAP’s architectural committee reviews the speciica-
tions and then schedules the development and delivery as part o its semiannual
enhancement packages. his approach ensures that demand exists or the speciic
services, which will likely be used when available (or speciics, see “SAPPHIRE ‘06:It akes a Community o Raise Web Services”).
8/9/2019 Soa and Bpm for Enterprise Applications a Dose of Reality Tcm16-35176
ake the ollowing into account when deciding on where to make your SOA investment:
• The maturity of your ERP vendor’s product in the time frame you intend to
start development—Has the platorm stabilized, or are major new capabilities and
integration o the tools promised in the next release or two?
• Where the BPM effort will be—Will it be within the ERP environment or a morecomplex set o enterprise and legacy applications and custom sotware?
• Your strategy for staffing BPM projects, including the difficulty of recruiting or
retraining staff —What is the potential o your current sta to learn the new tech-
nologies or the market availability o people with these skillsets?
Companies may see SOA and BPM in their uture, but the ramp-up time to apply
these technologies is long. Laggards will nd that one morning their competitors who
use the exact same ERP sotware are suddenly zooming ahead, shortening lead times,
introducing new products aster, and reacting aster to changing market conditions. I
groups that hope to respond to the business aster need to start making decisions, set-ting a strategy, and building the skills to apply SOA and BPM as a competitive weapon.
See Appendix A or the scores or each criterion by vendor and a short summary o the
vendor’s strengths and maturity o their tools.
8/9/2019 Soa and Bpm for Enterprise Applications a Dose of Reality Tcm16-35176
tools are excellent. IBM wasthe only vendor with its own
business modeling tool that
competes with the ever-present
IDS Scheer ARIS product.
Its WebSphere Integration
Developer combined all
BPM, workow, and other
user interace alternatives in
a single tool with enormous
depth o development capability. Like BEA Systems, it showed a solid capability to operate in the most complex SOA environments. Tough not necessary or our
scenario, the suite can also move seamlessly into the entire Rational development suite
or companies with extensive sotware development requirements.
Oracle
Oracle has a solid SOA
and BPM capability that is
becoming even stronger as
it has to use its own tools to
provide integration between
the E-Business Suite and
the wide range o enterprise
applications it has bought,
including Siebel, PeopleSot,
Retek , Demantra , and
G-Log . Its Application
Integration Architecture
strategy solves this problem
and also provides some
extended business process templates or common-use cases.
Te synchronization with the business process modeling tools (OEMed rom
IDS Scheer) is the only round-tripping capability we saw rom any vendor. Tis
gives business analysts a way to collaborate with their architect and development
colleagues without dropping into the very programmer centric world o JDeveloper.
Customers whose system landscape is dominated by E-Business Suite and other Oracle
applications have little reason to evaluate other tools.
Source: AMR Research, 2007
Table b: IBM—capability level
Factor Score
Business Process Management 3
Integration o Development 5
Registry and Repository 5
Services Development 5
Enterprise Application Services Catalog 5
User Interace Development 5
Business Activity Monitoring 3
Source: AMR Research, 2007
Factor Score
Business Process Management 4
Integration o Development 4
Registry and Repository 4
Services Development 5
Enterprise Application Services Catalog 4
User Interace Development 3
Business Activity Monitoring 3
Table c: Oracle—capability level
8/9/2019 Soa and Bpm for Enterprise Applications a Dose of Reality Tcm16-35176
This is printed on 100% post-consumer recycled fber.It is manuactured entirely with wind-generated electricityand in accordance with a Forest Stewardship Council (FSC)pilot program that certifes products made with highpercentages o post-consumer reclaimed materials.
