Have a Reuse Strategy for Business Process Integrations

January 29, 2012

When implementing process automation initiatives, it is important to have a reuse strategy – why? Because, the process flows are a rich minefield for reusing services and common interfaces across a variety of use cases. It can also act as a service provider for other teams to invoke/integrate a common set of processing flows.

Host business process definitions and instances

  • Provide a modeling and execution environment for designing and implementing business processes
  • Implement a generic data structure for manipulating & orchestrating workflow state
  • Provide the ability to reuse a workflow patterns across business processes. E.g. enable reuse via sub-processes, process extension points, etc.
  • Provide the ability to access and orchestrate activities requiring interaction with data services and business rules, and legacy services

Act as services consumer & provider

  • Host process orchestrations, while consuming persistence, validation, and security services
  • Abstract legacy capabilities and reduce tight coupling between internal systems
  • Publish and consume business events to reduce application to application coupling


Evolve a reusable asset catalog

  • Ensure technology components and APIs have domain relevance – data, events, and relationships are fundamental abstractions need to be brought together
  • Reduce learning curve for application developers to identify, evaluate, and integrate process definitions and services from a library of reusable assets

16 Candidate Reusable Capabilities for Business Processes

November 15, 2009

Here area set of ideas, candidate  assets if you will, of reusable software capabilities for your business processes. Please don’t take these as capabilities you have to build from scratch. Instead, view them as part of your overall BPM software infrastructure. Most of these capabilities could be provided by a single vendor or using an abstraction layer, you can realize these using multiple ones. You can also prioritize this list when evaluating vendor offerings.

  1. Rule driven Exception Handler: Integrate exception handling with business rules engine. The rules could  determine how to resolve, mitigate, and handle errors. It will also specify routing instructions for errors requiring human intervention.
  2. Internationalization Support: Status messages driven by a resource bundle as opposed to a single locale. Additional locale-specific resource bundles can be added as required for your business needs.
  3. Seamless Cross Channel Movement: Enable a business process to start in one sales channel and get completed in another. Idea is to support business processes that start, pause, and get reactivated via an alternate channel. For example, a user can start ordering a book online and request a customer service rep to finish the process. The idea is to have the user’s in-progress process instance data get placed in appropriate work queues in a new business process or in a new state on the original one .
  4. Business Process Completion API: Ability to determine % complete for any business process based on the state of the process instance . This API can provide the ability to get current status, estimate completion time (e.g. based on historical data), and what steps are remaining for the process instance to finish.
  5. Business Activity Hold & Retry API: Facilitate pause, resume, and delegation of any business activity based on business rules. This interface would put processing on hold as well for one or more process instances.
  6. Authentication: Enabling integration with a LDAP store, or providing digital certificate based security for interfaces that instantiate the business process are examples here.
  7. Entitlements  API: Enable fine grained authorizations for business activities and business processes. Role based entitlements for events – i.e. if a particular user role cannot initiate a business process or execute a particular activity, the software  infrastructure should prevent those actions.
  8. Content Management integration: Integrate with content management system to serve targeted content based on state of business process or to augment data in a process instance.
  9. Event Integration API: Capture or derive events and handle them using one or more business processes. This could also impact existing process instances that are in-flight.
  10. Indexed Search Integration API: Ability to execute full-text search as well as categorized search using an indexed search engine against completed and in-progress business process instances. E.g. search all process instances from a particular division or with a particular customer code, or category etc.
  11. Process Dashboarding: Provide key business process metrics – report real time status of availability, performance, usage statistics, escalations, etc. Also provide ability to override/adjust in-flight process instances based on business scenarios.
  12. Business Process Preferences API: Manage a set of process-level preferences. E.g. default logging level for all tasks could be set to high or all notifications get delivered to additional recipients, or data fixes will get audited a different way etc.
  13. Document Integration: Attach documents using information in a process instance and attach/route content as part of the business process orchestration.
  14. SLA Adherence API: Manage service level agreement specifications associated with end to end business process as well as key business activities. Ability to define/handle, and proactively prevent SLA violations.
  15. KPI Definition and Monitoring API: Monitor business processes to capture key process indicators based on business process. E.g. number of accounts opened today, number of accounts opened after multiple validation errors etc.

Like this post? Subscribe to RSS feed or get blog updates via email.

tweet this add to del.icio.us post to facebook

Building Business Processes Using Reusable Assets

November 12, 2009

You can build business process automation solutions using a set of pre-defined assets – assembling processes rapidly is one key benefit of systematic reuse. These assets will help you reduce effort, increase consistency, and most importantly save costs. The following are the different categories of reusable assets:

Event Handlers: Help you place processing logic for various business events in this category. The event handler itself can instantiate a brand new business process or hook into an existing one. Event handlers can be used as reusable entry points to various processes. E.g. a delinquent account event could instantiate a ReviewCustomer business process or a document expired event could trigger a DocumentTracking business process.

Building business processes with reusable assets

View Example

Sub-processes: These are micro-flows reusable across multiple business process. These assets encapsulate system steps, human steps such as escalation and routing. For instance, Purchase Equipment and Book Itinerary could leverage Finance Approval Process Flow (Note: obviously this has to be thought through carefully – the context for each business process would be different and appropriate data has to be sent to a sub-process for it to be truly useful).

Event Generators: These will typically have logic to assemble, transform, and publish an event. The event needs could be stored in a system and sent via nightly batch and over time become real-time. Event generators will shield business processes from such changes. These could be message generation components that publish messages at various stages in a business process. The event itself could be published from several business processes – so these generation components themselves are reusable. For instance, the AddressUpdated event could be published from the Account Maintenance or via the Purchase Widget business processes.

Business Services (or Task services): These often contain orchestrations that invoke external data services, perform business logic with the help of rules. They typically map directly to a business capability and tend to be less reusable than data services. But they can be reused as well across business processes. For example, a getCustomerCreditRating service could be leveraged by AccountOpening and AccountManagement business processes.

Data Services: These are service capabilities that encapsulate key enterprise data such as customer, product, account, document and provide create/read/update/delete operations as well as search, validate, enrich functions as well. They can be accessed from business processes directly or within a task service.

Decision Services: These assets facilitate decision making in the process, often by invoking business rules. Some rules might be reusable if they encapsulate logic that is applicable across multiple processes. This may not always be possible and will require rules to be at the right level of granularity. E.g. a validate customer decision service could be used by AccountOpening and DocumentManagement business processes.

System Adapters: These are connectivity components that provide access to legacy applications and other proprietary systems. They are used by your services layer to shield business processes from being directly coupled to external systems. These adapters could be leveraged by data services, business services, and event generators.

Like this post? Subscribe to RSS feed or get blog updates via email.

tweet this add to del.icio.us post to facebook

Envision a Data Services Product Line

November 7, 2009

I want to expand on the idea of a data services product line – specifically data that is critical to several business processes in your firm. Why use SOA to build these reusable services? It makes sense due to several reasons:

The data services product line can include data services across customer, account, product, and document data domains providing several capabilities for several internal and external applications and business processes. The vision for this product line? To create a suite of services that will:

  1. act as the single point of entry into interacting with core enterprise data
  2. significantly increase reuse of core data assets across business processes
  3. decrease time to market for new applications and services
  4. decrease development, maintenance, and support costs across the data service domains
  5. be scalable and extensible as business usage and needs varied over time

Customer services, account services, & document services can be considered products in a data services product line.

There are typically several sources of variation within the product line that needed to be effectively managed. Listed below is a subset of these variations:

  • Data Format
  • Data Structure
  • Data Source
  • Event Trigger
  • Data Visibility
  • Error Handling
  • Data Translations
  • Physical Transports
  • Workflow/Human approvals

Have you built data services at your organization?

Like this post? Subscribe to RSS feed or get blog updates via email.

tweet this add to del.icio.us post to facebook

Enterprise Data Services and Reuse – New Podcast Episode

September 7, 2009

Want to listen using iTunes?

Using iTunes?

podcast Just posted a new episode on the software reuse podcast series about the rationale for enterprise data services and how they help with reuse across multiple business processes and master data management (MDM) initiatives.

Like this post? Subscribe to RSS feed or get blog updates via email.

add to del.icio.us: Digg it : post to facebook: Stumble It! : :

Software Reuse Quick Tip #15

July 24, 2009

Tip #15 – Separate Business Process Context from Core Data

Service contracts that automate business processes should not mix contextual data with core entity data.  The following are examples of contextual business process data – initiator info (the user who started the business process, their role(s)), current user info (the user who is executing a particular activity in the business process, their role(s), the set of actions that are valid based on the state of the business process, as well as routing/delegation attributes. Authentication tokens, channel specific information (e.g. call center processes will have specific attributes).  This type of information should be decoupled (or not mixed with) data entities such as Product specific or Customer specific information. You want to keep them separate so they are candidates for future reuse. If they are coupled together, both the process contract and the data attributes become specific to the project or application.

Like this post? Subscribe to RSS feed or get blog updates via email.

add to del.icio.us: Digg it : post to facebook: Stumble It! : :

Getting Organized for SOA Success Part II

July 9, 2009

In the previous post on getting organized for succeeding with SOA I talked about the importance of implementation-free requirements and the overall role of business analysts. In this post, I would like to highlight specific areas where business analysts can help SOA initiatives.

  • Create business models – free of technical specifications or system level details – that capture the full end-to-end view of a business process. They should use a modeling tool that can work with a standard notation (e.g. BPMN) and create as accurate a view of a business process as possible. They need to capture human steps, system steps, pauses, business rules, external activities, etc. accurately and comprehensively
  • Identify candidate business capabilities – not necessarily technical services – but at a higher level of abstraction. For example, MakePayment or BookTicket are business capabilities that can be realized in a multitude of ways by technology folks. But the analysts could significantly help by pointing out capabilities that are candidates for reuse across multiple business processes, scenarios, or lines of businesses.
  • Identify areas for simplification/streamlining – analysts can identify redundant manual steps where users enter data multiple times or in similar fashion. They can also identify steps that can be eliminated or made simpler. For instance, validating credit worthiness of a customer could be done systematically and the system can present options for the user based on score. Or the credit worthiness score could be driven by business rules and only in exception cases the system might require manual intervention. All these behaviors have to be driven from the context of how to make the overall user experience better.
  • Provide context – analysts can help identify areas of business priority in order for technology to build services. What lines of businesses are meant to grow? which ones are going away? which business process needs maximum customization and if so, in what ways? A good analyst can provide the big picture view, the context for your SOA initiatives by helping you separate the essential from all the noise.

This list isn’t exhaustive but is meant to give a sense of the key role that an analyst plays!

Like this post? Subscribe to RSS feed or get blog updates via email.

add to del.icio.us: Digg it : post to facebook: Stumble It! : :

Getting Organized for SOA Success

June 27, 2009

There are many organizations – large and small – undertaking SOA initiatives. As much as the technical infrastructure, message processing, service governance, and web service monitoring are important for your SOA you cannot afford to ignore the organizational aspects. In this post, I want to not focus on your entire enterprise but your department or a group of development teams undertaking SOA initiatives. When aspiring for SOA success you have to have more than developers and technical leads on your side.

So who else needs to be involved? You need your requirements analysts, your data modelers, and production support staff all singing the SOA tune albeit in their unique voices. This post will talk about requirements analysts.wrongtarget

Many developers underestimate the impact of requirements analysts (also referred to as system analysts or business analysts). Some analysts mix requirements with design offering specific solutions to business needs. Requirement specifications end up becoming design documents. Why is this a limiting factor for SOA? Because, you want to identity candidate services, reuse existing service capabilities, refactor legacy and modern assets and govern these service capabilities as part of your SOA strategy. Imagine, sifting through a requirements document that specifies implementing functionality as stored procedures or batch jobs. Without care, this can influence your thinking – knowingly or unknowingly binding you into solutions that are not in line with your SOA goals.

You want your requirements analysts to specify the business processes the application needs to automate, enhance and the business capabilities required. You can then deduce the business services, the enterprise data services, and the BPM workflows that need to be developed. If your analysts are receptive you should persuade them to use a modeling tool that can specify an analysis model using a vendor neutral notation that can be imported into a BPM engine and converted into an execution flow. All said and done, the deeper point isn’t BPM or analysis model but about the what of the system. Using the what you can design the how. That is where SOA comes in addressing questions around what services you will build, which ones you can integrate with, which ones to decommision, and which ones to change. Requirements should clarify and not prematurely solve technical problems.

Ask your analysts to provide world class requirements including functional and non-functional ones. Persude them to stay away from providing technical solutions so you can figure out how to automate your firm’s processes within the context of your SOA efforts. This isn’t easy and won’t be possible with every project but that shouldn’t prevent you from trying!

Like this post? Subscribe to RSS feed or get blog updates via email.

add to del.icio.us: Digg it : post to facebook: Stumble It! : :

SOA and Reuse – New Podcast Episode

June 21, 2009

Want to listen using iTunes?

Using iTunes?

podcastJust posted the seventh episode of the software reuse podcast series covering how reusable services and Service Oriented Architecture (SOA) go hand in hand to generate new revenue and save costs.

Like this post? Subscribe to RSS feed or get blog updates via email.

add to del.icio.us: Digg it : post to facebook: Stumble It! : :

Reblog this post [with Zemanta]

Building Reusable Services Meetup Talk

June 19, 2009

I recently presented at the Silicon Alley NYC Meetup on service orientation and building reusable services for Service Oriented Architecture (SOA) initiatives.

Like this post? Subscribe to RSS feed or get blog updates via email.

add to del.icio.us: Digg it : post to facebook: Stumble It! : :

Reblog this post [with Zemanta]

%d bloggers like this: