The approach to designing IT architecture and implementation is changing from a technology-centered paradigm to a solution that is based on business process orchestration. When IT solutions are centered around business processes, an enterprise can adapt process changes more rapidly to support changing operational needs. Business process management (BPM) solutions provide insight about the enterprise that transcends organizational and operational boundaries. In this series, based on an actual scenario, you explore the advantages of implementing a BPM solution -- one that enables a real global IT manufacturer to improve pre- and post-sales operations and customer satisfaction. You are invited to follow along in this series as we develop a composite, collaborative workflow solution that uses people, processes, and information systems to help the manufacturer meet specific business goals.
This series is based on our experience of implementing a composite workflow solution for an actual global IT manufacturer that we'll refer to throughout this series (using a fictional name) as Worldwide IT, Inc. (WIT) . The client's business involves managing pre-sales processes and operations for selling solutions to its customers. The sellers work collaboratively with other people involved in the sales process and use services from sales-support teams. The interaction between sellers and the support teams is through a series of service requests (SRs). The SRs are entered in the customer relationship management (CRM) system, which is then used as a business event to launch a workflow process that guides the support team staff with workflow tasks. The support team performs the necessary business activities to provide services to the sellers.
To address WIT's need to execute a standard business process in a consistent way, a composite workflow solution based on BPM principles and the Service-Oriented Architecture (SOA) approach was implemented. In this first article you're introduced to the business scenario and given an overview of the solution. You'll learn the business objectives, current business and IT challenges faced by enterprises, and how a BPM solution can help overcome those challenges. You'll also discover the characteristics of a composite workflow, followed by process design and implementation considerations, as well as the solution components and architecture.
Business objectives, challenges, and expectations
One the company's major priorities was to increase sales by improving the ability to deliver cross-brand solutions to customers. Objectives included improving seller's customer face time and improving the efficiency and effectiveness of the pre- and post-sales support team. The solution must:
- Help improve the seller's ability to satisfy customers by being more responsive to their needs.
- Support the sellers and support teams to close sales deals for multi-brand solutions.
- Enable the support team to develop higher-quality proposals, contracts, and product delivery plans.
The quality of the proposal documents helps the sellers satisfy customers and helps make buying decisions in a timely fashion.
Business challenges and pain points
The sales and support team faces several business challenges in executing the pre-sales operation. The client, which we refer to as Worldwide IT, Inc. (WIT), is a global IT manufacturer and has its business organized around several brands. The country-specific business units follow unique processes, business rules, and IT tools, and these vary based on the brand.
The sales and support team use several manual processes and activities, resulting in a costly, slow effort. The team is forced to use multiple overlapping and disconnected IT tools that require users to re-key data, causing errors and inaccuracy. And the IT systems cannot handle rapid deployment or assimilation of best business practices.
The business management team lacks the ability to holistically view business volumes, cycle times, service-level agreements (SLAs), and commitment management. Business managers have no decision-support systems to simulate or predict impact of volume and process changes on resource models, costs, and inventory.
The first thing our team did was an assessment of existing applications that highlighted gaps in the application environment and the potential for not keeping pace with increasing business volumes. The existing environment had limited efficiency and effectiveness, and inhibited process innovations. The IT environment consisted of disparate applications and did not provide a seamless, integrated view of business processes, and data.
The support team staff is required to log into CRM Siebel to access the SR they are to work on and must access several different legacy applications to complete each requested task. The applications vary based on country and brand-specific business unit. Business rules are not embedded in these applications or programs, so users must know the business rules and controls to be followed for each activity or SR. The IT systems are designed independently, each from a different perspective, so no common look or feel exists. Data management and reuse is nonexistent, so data and evidence produced can not be reused by downstream applications. Figure 1 summarizes the major pain points of their IT environment.
Figure 1. Current IT pain points
The workflow solution is expected to provide a standardized and consistent process, called a contract management process. The solution is required to provide baseline processes for measuring continuous improvements of services provided by sales support functions. Important benefits are the ability to monitor execution of the process and generation of customer proposals and contracts. The solution will help the line-of-business (LOB) managers create reports about business metrics and key performance indicators (KPIs). Another key benefit is to enable managers to make timely business decisions based on operational inputs and business data.
The contract management process involves various business activities, resulting in the creation of proposals and contracts. The activities are grouped logically into process modules, which in turn make up the end-to-end process model. A business event in the CRM system triggers the process, and executes the modules and activities based on business rules. The process creates and assigns tasks to sales support team members who will complete the tasks. The process modules are mapped to the business scenarios, as listed below and shown in Figure 2.
- Scenario 1: Execute Service Request 1 - Customer Research
- Scenario 2: Execute Service Request 2 - Solution Configuration
- Scenario 3: Execute Service Request 3 - Solution Pricing
- Scenario 4: Execute Service Request 4 - Perform Customer Credit Check
- Scenario 5: Execute Service Request 5 - Prepare Proposal and Contract
Figure 2. Process scope and modules
Figure 3 lists the high-level capabilities that the solution is required to provide in order to meet the business objectives. (Subsequent articles in this series cover specific business requirements in more detail.)
Figure 3. Required high-level capabilities
The solution approach: BPM and collaborative workflow
Our approach to a solution for the client incorporated aspects of BPM and collaborative workflow to achieve the required capabilities.
In the past two decades, enterprises focused on automating processes and integrating applications within a value chain. Productivity improvements were gained, but the business processes got trapped inside the application code, making process change a costly effort. BPM can solve this dual business and IT problem.
BPM is centered around the notion that an enterprise can be defined and governed entirely as business processes. The business processes of an on demand business are dynamic and change almost constantly because of business and operational transformations, or mergers and acquisitions. The main benefits of building a solution using BPM, combined with SOA principles, are flexibility and responsiveness to change in business requirements and objectives. BPM is process-centric, and SOA provides interoperability, bringing together IT assets to create a virtual solution.
BPM brings processes, people, and systems (information and data) together, enterprise-wide and beyond, to include trading partners. The BPM approach helps separate business process logic from application data and information, resulting in process independence and ultimately business agility (ability to rapidly adapt to a changing environment).
At the technical level, BPM is the convergence of Enterprise Application Integration (EAI), workflow, content management, business intelligence, and other technologies to manage business process orchestration. BPM manages the business processes, according to business rules and conditions, by leveraging the enterprise assets (systems, people). A BPM solution streamlines and automates business processes by leveraging IT systems to add efficiency and flexibility.
Collaborative BPM is the convergence of workflow, EAI, and unstructured or ad hoc processes. Collaborative workflow executes business processes that involve knowledge workers who perform the business activities as tasks.
Collaborative workflow is an evolution of standard, task-oriented workflow and has certain unique characteristics. Collaborative workflow has no strong sequential order in task execution, but requires on the fly composing of the process flow. It encounters and deals with frequent exceptions and changes in the business operation, which means it requires flexible workflow concepts. It deals mainly with semi-structured work rules and routines.
Collaborative workflow requires dynamic rules capability (the ability to determine rules, not just values) -- a key capability for providing operational flexibility and efficiency. The emphasis is on leveraging and allowing a user's personal judgment and experience in operational decisions. Business rules must complement the user's operational knowledge and assist users rather than controlling them. Collaborative workflow is more of an art than science and often involves cyclic, improvised steps, but is implicitly controlled by business logic.
New approaches are required for building a collaborative workflow solution; it cannot be implemented using traditional workflow approaches. Some required new approaches are:
- Hands-off approach in the process orchestration to deal with change in business operation needs
- Divergence from a predefined process to address contingency and rejoin the normal flow
- Dynamic behavior (late binding) approach to choose alternate workflow paths at run time
- Adaptive workflow to meet operational changes (External business factors will influence alternative paths and iterations.)
These features aren't typically supported in many commercial off-the-shelf workflow solutions.
Figure 4 shows the evolution of the workflow concept. The structured processes approach on the right is a good fit for business scenarios where users are typically "heads down," clerical, or call center staff. The semi-structured and collaborative processes are an effective technique for scenarios that involve knowledge workers as workflow users.
Figure 4. Workflow continuum showing collaborative workflow evolution
Acknowledgement: Wolfgang Hilpert, former Director of Knowledge Management
Lotus Development Corporation
Design considerations and implementation
In any workflow-oriented solution, the business process design and models, based on a sound process analysis, form the foundation of the solution. No workflow solution can be effective in providing business value, regardless of its technical superiority, without a sound business process model to support the solution. This section discusses a few design and modeling considerations applicable to a composite workflow solution.
Process design, modeling, and analysis
During the analysis stage, it is important to identify business operation scenarios, or use cases, and determine what makes up an instance of a workflow process. The process design and modeling must allow for variations in process execution, driven by business rules or transaction characteristics, based on business conditions or constraints. A unique requirement for collaborative workflow is task iteration (rework). It is important to identify such scenarios within your business process, and model for handling iterations driven by business rules.
Often, workflow implementations focus mainly on automation, which is not always a bad approach. However, you need to use evaluation criteria to determine and prioritize which processes to automate first, and still allow for human ingenuity and creativity. Business value can be realized only when the business process approach is in alignment with corporate business strategy and goals.
In a long and complex process spread across multiple applications and users, it is impractical to manage each step of the process in accordance with an embedded business logic. Instead, define and use business rules that enable decisions to be made dynamically at critical steps of the process to ensure the process execution helps achieve the business goals. Be selective and exercise caution in which aspects of the process to monitor during the process execution. The approach must be sensitive to cultural, legal, and local government privacy constraints. Design a good combination of human-centric and application-centric workflow to support the business process automation.
Workflow solution implementation
Implementing a workflow solution incorporates three basic phases, or stages:
- Mapping the current business operation or process to create an as-is model.
This involves revealing and recording all of the manual and automatic business processes relevant to workflow implementation.
- Develop a to-be business process model and derive a workflow solution.
Using the results of the mapping phase, develop a process model that will help streamline business processes. It must support three interactions: person-to-person, person-to-application, and application-to-application.
- Develop a comprehensive solution architecture to provide the capability, based on the model, to integrate, connect, manage, and monitor the process execution.
Identify application systems that are relevant for integration with the workflow process. Exchange of information and data among the applications must be automated to avoid re-keying of data by the user. A collaborative workflow solution should be capable of managing documents and content. A collaborative workplace is the part of the architecture that provides interfaces for users to interact with the workflow solution. Finally, the solution must provide process monitoring, analytics, and reporting.
The BPM solution must use business rules, workflow, and EAI components to coordinate the flow of information among the different applications.
The solution: composite workflow
This section covers the key architectural principles on which our solution architecture and design are based for the global IT company, WIT. We used reference architecture, patterns, and best practices relevant to BPM and IBM middleware products. Services (composite and atomic), SOA principles, and the design considerations were guiding principles in the architecture and design of this solution.
A composite workflow system combines the capabilities of workflow, EAI, information and document management, and business intelligence to provide a comprehensive solution. The architecture for a composite workflow solution must support flexibility to meet changing business needs and help achieve business growth. It must enable the enterprise to leverage IT assets and skills (for development efforts) across its business units. From a deployment viewpoint, it must provide cost-effective IT deployment. And, it must be easily maintained, communicated, and enforced across the enterprise.
We tapped the SOA approach to:
- Enable interoperability in a distributed and heterogeneous IT environment.
- Provide enhanced connectivity among systems and between both internal and external organizations.
- Be independent of underlying implementation technologies.
The three guiding principles followed in our design and development are:
- Asset reuse
- Ability to support new business processes by composing (combining together) existing transactions and functions in current IT systems
- Flexibility
- Ease of developing process-driven applications with less coding and more reuse of existing IT assets, to react quicker to the business need for new or enhanced functions; use of configuration, customization, and business rules to realize flexibility
- Process improvement
- Simplify access to all application functions and information required to execute a business process. Use model-driven composition tools to simplify building and modification of core business processes and achieve composition and orchestration.
The approach for human task implementation involved using both "push" and "pull" options for task assignment. Pull clients are most often used for assigning tasks to knowledge workers, where users select which work item, or task, to work on from a list they can sort and filter. Push clients are mainly used in heads-down clerical and call center roles, where the system automatically pushes the next work item to each user as soon as they finish the previous item.
When architecting and designing a solution, you can use techniques that leverage SOA principles, such as Service-Oriented Modeling and Architecture (SOMA) from IBM Global Services. We looked at SOMA methodology, but couldn't fully apply it in our project due to a tight delivery schedule. However, as a guiding principle, we leveraged SOMA methodology to the extent it was relevant and possible.
For the design, development, and deployment of services in the implemented solution, we used the three-step technique described below:
- Identify business services related to activities that make up the end-to-end business process.
- Decompose high-level business services as needed, and map them to both existing and new IT services that are required.
- Categorize business and IT services using factors such as service provider and consumer, business functions, service source system, and so on.
- Identify potential business services (functions) based on tasks within the end-to-end (e2e) process model and categorize them around functional areas.
- Decompose, as needed, the identified business services into atomic services.
- Identify the IT services to support the business services, and map the business and IT services. Use service hierarchy and categorization for rationalizing IT services.
Figure 5. Identification, decomposition, and mapping of services
Composite services will abstract and use the different atomic services from the relevant applications. It is important to distinguish composite IT services from atomic IT services. A composite service uses more than one atomic service to provide the required functions. For example, the user needs to view additional information when working on a workflow task. The data and information related to the task might come from more than one application system. In such cases, a composite service that abstracts a set of atomic services is a good way to design and implement. This approach reduces the complexity of service interactions, and also lets you introduce new atomic services in a more manageable way. Other examples relevant to composite compared with atomic services are:
- Business controls related to completing the task may vary based on country, brand, and customer situation.
- Pricing or credit may be performed in different applications based on brand, country, business unit, and so on.
- Data for KPI metrics may come from more than one application.
- Create service specification, design, and plan development.
(Because it is beyond the scope of this article, the details about services specifications and related information are not provided here.) At a high level, with this approach you need to:
- Develop service specifications for both business and IT services.
- Identify existing IT applications that provide IT services.
- Identify new IT services needed.
- Identify subsystem for placing the services.
Figure 6 highlights the business services and subsystems involved in our solution. The business services are categorized by provider and consumer types. In a complex IT system that uses a services approach, it may not be easy to distinguish between a service provider and service consumer. Often, a service consumer can also act as a service provider to a requester. From a larger perspective, the distinction may not be very obvious, but the differences are clear at the subsystem level. Infrastructure services play a critical role, as they are shared by multiple business services.
Adopting a universal naming convention for the services is another important aspect that is critical in larger projects. A universal naming convention helps avoid ambiguity, because often the same business function exists in multiple layers of the system. For example, in our application, Task Manager as a service exists in both the presentation layer and in the business-logic layer. Adopting a good naming convention and ensuring its compliance by the various services development teams, help avoid ambiguity and naming collision.
Figure 6. Subsystems and services
System context and architecture
The business services are identified and mapped to composite and atomic IT services. And we've identified their placement in the subsystems. The next step is to do a system context diagram and identify all the interactions between these services.
Figure 7 shows the subsystems and components that expose the services. The solution reuses three existing IT applications to provide comprehensive functions. The existing applications become subsystems of the new composite workflow. New subsystems and components are needed for additional functions. Figure 7 also shows the interaction between the services and users. The specific roles are identified, and the interactions identify the services being used.
Figure 7. System context
Now let's look at a logical view of the solution architecture created for the new composite workflow system. The architecture shown in Figure 8 identifies the subsystems, their components that expose services, and high-level service interactions among the subsystems.
The logical view of the architecture helps visualize services and components in the context of the solution. The diagram identifies the existing IT applications as subsystems, and shows the new subsystems needed for the solution. The various flavors of services are also shown in Figure 8.
Figure 8. Solution architecture
The deployment topology, as a logical view of our execution architecture, is shown in Figure 9. The topology involves one application server and one database server. Interfaces to the CRM Siebel system and document management system (DB2 CM V8.2) are deployed. An interface to Enterprise Lightweight Directory Access Protocol (LDAP) directory is used for user authentication service. Figure 9 also shows service artifacts of various subsystems that are deployed, identifying the placement of artifacts on the subsystems.
Figure 9. Deployment architecture
Solution run time and product mapping
The composite workflow solution architecture for our real company, (fictitiously named Worldwide IT, Inc.) was conceived in late 2004, and the first version of the solution was developed and deployed in May 2005. There were a couple of product-mapping options available for the workflow engine run time. WebSphere® Business Integration Server Foundation (Server Foundation) or WebSphere MQ Workflow could have been used as a workflow process engine. The product selection and mapping depend upon many factors, such as product capabilities, availability of skilled resources, development time and cost, project schedule, and so on.
We chose WebSphere MQ Workflow over Server Foundation because its capabilities better matched with our solution requirements, and the out-of-the box monitor capability was key to meeting our business requirements.
The composite workflow solution was built using the following products:
- WebSphere MQ Workflow V3.5
- WebSphere MQ Server V5.3
- WebSphere Business Integration Monitor V4.2.4
- WebSphere Portal Server V5.0.2.2
- WebSphere Application Server V5.0.2.6
- WebSphere InterChange Server V4.3
- WBI Adapters for Siebel and MQ Workflow
- System Monitor for WebSphere Interchange server V4.3
- DB2® Universal Database™ V8.1
- Information Integrator for Content V8.2 to interface with DB2 Content Manager V8.2
We used the following tools (IDEs):
- WebSphere Business Integration Modeler V4.2.4
- WebSphere MQ Workflow Buildtime V3.5
- WebSphere Application Developer - Integration Edition V5.0
- Rational® Application Developer V6.0
- Rational Rose® for design
To manage the development process, we used:
- Rational ClearCase® for source-code management
- Rational ClearQuest for managing defects tracking and resolution during testing
- Rational RequisitePro® for managing requirements and use cases
The solution was deployed on:
- IBM AIX® V5.1 ML6
This series covers the architecture, design, and development of a composite workflow solution for a real company using IBM middleware technology. In this article, you learned about:
- BPM, collaborative workflow, and the approach to the solution implementation
- The business scenario, business objectives, and expected benefits of the solution
- Process design and modeling considerations, along with a workflow implementation approach
- Designing the solution around services, including an example for identifying business services and mapping them with IT services
- An overview of the solution using system context and solution architecture diagrams, highlighting services, key subsystems, and interactions between key components
- A logical view of the deployment architecture and deployed key artifacts supported by the run time
Stay tuned for future articles that show you subsystem design details and how to leverage IBM middleware technology and concepts (such as composite application, process portal, and integration techniques) to build a composite workflow solution.
Learn
-
WebSphere MQ Workflow: Learn much more about this product that supports long-running business process workflows as they interact with systems and people.
-
IBM and Siebel: Read about the
IBM and Siebel alliance, which unites the recognized market leader in CRM with the largest Siebel integrator and implementer worldwide.
-
SOA and BPM: Read about this winning combination that helps businesses run faster and respond quicker to market changes.
- Stay current with developerWorks technical events and webcasts.
- Search for related books at Safari Bookshelf.
Get products and technologies
- Build your
next development project with IBM trial software, available for download directly from
developerWorks.
Discuss
- Participate in the discussion forum.
- Participate in developerWorks
blogs and get involved in the developerWorks community.
Logan Vadivelu is a certified senior IT architect with IBM Software Group and helps customers implement enterprise solutions using IBM middleware technologies. He has extensive experience in the architecture and design of enterprise integration solutions. His current focus is Service-Oriented Architecture (SOA) and composite solutions that leverage Web services, process choreography, and Enterprise Service Bus (ESB.) Logan has presented technical topics at conferences. He holds a Master's degree in Engineering and Management. Contact Logan at vadivelu@us.ibm.com.
