BPM in the Real World
Advancing System Design & Data Management Through Process Modeling
By Michael Deskis, GoGogh
In this article, I will attempt to steer you through the pitfalls of designing
service-oriented architecture (SOA) applications using Business Process Execution
Language or BPEL models.
The problems with designing application systems are many when drawing comparisons
to the work of an architect designing a building. The rules, standards, principles
and techniques utilized in architecture have been clearly defined and well understood
for centuries. The guiding viewpoint for their designs have centered on equal
parts of functionality and aesthetics.
Additionally, the cost of design failure can be catastrophic, thereby leading
to considerable governmental regulation. Unfortunately, we have few of these
benefits when modeling applications for our SOA integration systems.
This is not to say that we don't have some pretty good methodologies and design
principles for guiding our work efforts -- we certainly do. We just don't execute
them effectively or apply them in a timely fashion. Many times we feel rushed
and compelled to meet an urgent emerging need with a quick solution with no
thought to the overall strategy.
Enter process modeling
So what exactly is this concept known as process or BPEL modeling? These models
are the technical progression of SOA modeling from multiple historical predecessors:
flowcharts, data flow diagrams, program structure charts, UML models, Gantt
and PERT charts to name a few.
When fully developed it is simply the process of linking together multiple
deployed web services, which return standardized corporate data into an automated
and sequential workflow. Through the process model, we utilize the deployed
web services to provide the predominant business logic that will generate universal
Then, wrapped around this logic we integrate conditional logic, branching,
fault handling, iterative processing, parallel logic and sequential flow to
complete the process model. Through the use of graphical tools, a designer can
rapidly create a new model, search for services, integrate internal or external
web services, visually represent the flow of activities, add and upgrade new
tasks and deploy to an integration server.
We must remember that process modeling requires some significant infrastructure
components to be in place to assure efficient utilization. First and foremost,
it requires an integration server with a BPEL container environment for converting
the BPEL XML into executable code. Second, it requires the use of an enterprise
service bus to serve as the centralization point of standard services (security,
logging, auditing, etc.) and to manage the routing, transformation and mediation
of the SOAP message.
Third, it requires a rules engine as a repository of business rules for elevating
business logic to the enterprise level. Finally, it requires a fully searchable
UDDI repository for storing the Web Services Descriptive Language (WSDL) files
generated for our deployed web services.
When we are developing our process models, we should keep in mind the concept
of service component architecture (SCA) to clarify in our own minds what is
deemed a callable enterprise service. Generally, we think that only deployed
web services can be called in a process model.
However, the SCA concept reminds us that we can access anything that meets
these simple rules: it can be described with a WSDL document, it has an interface,
contains one or more operations and has a proper implementation. Thus, not only
web services can be called, but also business rules, human tasks, state machines
and other process models.
Applying process models
Now that we know more about the concept of process modeling, we should illustrate
these concepts with an example. If we were going to develop a process model
for processing orders from a website that was selling widgets, what would the
scenario appear like?
Step 1: Our model accepts a standard order from a client that contains
all order information (product info, credit card data, shipping preference,
etc.). Our model assigns all of these values to internal variables.
Step 2: Upon receipt of the order, we need to check on available inventory.
So we call an internal deployed service for the inventory system and pass it
the product ID and requested quantity. We incorporate a basic conditional to
insure appropriate quantity is available.
Step 3: If quantity is unavailable, we initiate parallel calls to each
of our widget manufacturers and their corresponding external services to get
their price quotes. We utilize a conditional to determine which price quote
is the lowest. Finally, we initiate a call to the external service of the widget
manufacturer to place an order.
Step 4: Next, we need to process the client's payment. We have enlisted
a credit card processing outfit to manage all of our online payments. Thus,
we simply execute this external service and pass all of the appropriate credit
card information and await the authorization code. We incorporate a basic conditional
to verify the authorization code to allow the sequence to continue.
Step 5: With the proper authorization in hand, we can continue to processing
the shipment. If the quantity was available and on hand, we would call the external
service for our shipping entity and pass all appropriate information and receive
a confirmation number.
Step 6: Finally, we like to generate an email confirmation to the client.
Therefore, we gather all of the confirmation information and client data and
call an internal service that will generate the email. We'd return a completion
message to the client and our model is complete.
Step 7: At appropriate points in our model, we'd need to perform basic
exception handling and generate fault messages for the client.
Thus, we've completed a complete workflow model for handling order requests
by sequentially processing a series of external/internal deployed services and
controlling the flow by performing conditional tests. Once completed, we can
deploy this process model to the integration server and it is ready to start
Deploying successful models
Process modeling can't be viewed in a vacuum and there are many interrelated
components required for developing and deploying successful models. During the
design process, there are a series of basic principles I've adhered to that
have proven to be very beneficial.
First and foremost, we must have a long-term plan effect. There is that old
adage "Fail to plan, plan to fail." It could not be more fitting than
when applied to the world of IT architecture design. Having been in the IT business
for 30 years I have seen my fair share of wasted design efforts. The first step
must be the visualization and dissemination of the long term goals of our corporate
SOA integration efforts.
One of the underlying aspects of SOA implementations is their collaborative
nature. Integration in the SOA world requires a high degree of interaction and
support from both the IT and client community to be effective and successful.
The creation of an advisory panel, composed of representative individuals from
all communities, is recommended to define the goals and mitigate the direction
and is a key ingredient of success.
Another supporting principle is the recognition of the delineation of roles.
Upon entering the realm of SOA integration development, we must recognize that
certain prerequisite skills are required and successful SOA projects will require
individuals in multiple roles.
These roles include: developers developing our granular web services, enterprise
architects controlling overall architectural control, business analysts interfacing
with clients and developing system prototypes and integration developers that
will be creating and fine tuning process models and communicating with all other
An interwoven principle is the integration of basic governance strategies.
Developing process models will incorporate service components from many different
applications within our corporate architecture. Thus, creation of standard governance
policies regarding service development, data management, deployment and adherence
to these policies is crucial.
For our applications to be successful, we must recognize the basic infrastructure
prerequisites necessary for our implementation. The development of process models
is a fairly sophisticated technique within the realm of SOA application development.
Thus, it requires the implementation of specific infrastructure components:
discoverable services, a rules engine, a fully developed UDDI Registry, an Integration
Server with a BPEL container and an enterprise service bus with deployed routing
The most common mistake enterprises make in their hurried pace to implement
services is the incorporation of a complete workflow as a web service. They
end up exposing a service that is both a data and time intensive process that
when combined in a process model will tend to set new records for performance
inefficiency. I tend to call this the Iceberg principle, because in process
modeling we don't foresee the full impact of enacting a service. Services need
to be driven to the lowest possible level, thus allowing us to avoid the Iceberg
principle where the service performs far more activity than required.
The last, and one of the more crucial principles, is the deployment of a UDDI
Registry. Having a common repository to publicize the existence of available
and deployed services should not be underrated. Not only does it provide a common
library of available components for our process models, it also serves as a
vehicle for enforcing the rules, standards and policies implemented under the
corporate governance umbrella.
Planning makes perfect
If your goal is to create and deploy an efficient and effective SOA architecture,
then you'll need to realize that this process is not as simplistic as a vendor's
toolset or presentation will imply. It is long and arduous process full of complex
decisions that requires stringent goal setting, careful planning, proper infrastructure
implementation, efficient dissemination of data, adherence to governance and
resistance to the quick solution. Process models are an integral ingredient
in any SOA implementation, and understanding the components upon which they
are dependent will greatly increase your probability of success.
About the Author
Michael Deskis is actively involved in consulting, mentoring and training in the Service-Oriented Architecture environment for GoGogh.com. and is a primary principal with OnsiteSeminar LLC. His passion is to guide organizations through their design, modeling and development processes for their enterprise integration efforts to insure their success.More by Michael Deskis