Bridging the Gap between Business Modeling and SOA

I’ve found topics to be more interesting if I can apply them to something or someone I’m familiar with. If a relative has cancer, I’ll listen more intently to news items about cancer treatment. If a friend is moving to Mexico, I’ll think about international events in a slightly different light. I call it the “relevance factor”. We each evaluate information against our own personal scale to determine what to do with it. If we can find some frame of reference for or application of it, we’ll pay attention and store it for future use. If not, we’ll dismiss or ignore it.

So how does this apply to Business Modeling and SOA? In my experience, this relevance factor plays a large role in people’s view of business process models. From a design perspective, they’ve often been viewed as “pretty pictures” that help business people articulate their requirements. But is that all they are? How can they be made more relevant and therefore more valuable?

I was recently asked to help a company understand their current delinquent collections process and associated business rules. Then, based on that understanding, develop their future ‘to-be’ model which was expected to:

1. Consolidate user work flows
2. Simplify screen navigation
3. Provide standardized scripting
4. Reduce agent training time and complexity
5. Provide a more consistent and comprehensive customer experience

This exercise was part of a larger initiative to create a process driven front-end for a mainframe Customer Service support system using a Service-oriented architecture (SOA). To achieve this we had to move through two phases of the Business Process Management Lifecycle (Diagram 1) which included an extensive modeling effort at both the business and explicit technology layers.

The model stage brought all the business process stakeholders together in facilitated work sessions to explicitly model the business process with its associated rules. Opportunities for improvement were identified and the process analysis applied to:

• Analyze the current business process
• Define an improved future process
• Manage the enterprise process repository
• Capture appropriate metrics
• Assess process enablers
• Set the strategy for implementation

The typical enable stage takes the business process models and assembles the needed process enablers (people, operations, technology, facilities, and regulatory enablers) to fully implement them. For this project, we found that the primary enabler was technology so that’s where we focused. The required business services for supporting technology were identified for development.

So after four months of work we completed both the Model and Enable stages and were ready to circle back to evaluate lessons learned. Specifically we wanted to know if there were any ways to make business process models more useful and relevant to system design. Here are some practical suggestions we hope you might find valuable in making your modeling effort more effective:

• Make Sure Everyone Has the Same Goals for the Project. This was an interesting phenomenon. In retrospective analysis, we found that the business was most concerned with getting the new process implemented on the front-end system. Yet the business analysts and facilitators were focused on improving the existing process and its measures. Why bother rebuilding a bad process, right? At the same time, the technologists were focused on further enabling SOA within the organization. None of this was right, wrong, good or bad. But the fact that we didn’t balance the goals of the business (getting product out) with the methodology (embraced for running better as an organization by focusing on enterprise process design and fit) earlier in the process led to more frustration and questioning of relevance (i.e. “why do I care about that”?) than was necessary. In spite of the documented goals of the project, have an early conversation about the relative value of improvement, implementation, and methodology to the project sponsorship, its funding, and perceived success by stakeholders.
• Get Technology People Involved in Model Stage. The earlier, the better. The modeling stage is where discovery and discussion of business rules occurs. The business experts knew most of these, but some were buried within the system coding or involved complex decision trees. These exceptions required investigation by a systems analyst and occasionally we were surprised by their findings. It’s true that these issues were probably more critical since we were dealing with an older legacy system, but regardless we feel that involvement from Information Technology throughout the process is a recommended best practice–involve them early for fuller understanding and clarification; later for actual "doing".
• Keep the Key Business Team Members Consistent throughout the Model and Enable Stages. We found that the same questions were asked and answered again and again as the project shifted from stage to stage and new roles were added. That’s OK. But without consistent business representation, the answers may change! This danger can be avoided by having a blended technology/business team throughout the modeling effort and into design. It also eliminates the rework, rehashing and delay created when new folks drift into the middle of a modeling effort. A consistent team creates a foundation of knowledge that can be built on throughout the process. New folks can be tapped for specific knowledge, but bringing them into the process cold turkey will have a backward effect on progress and the team.
• Designate System Activities on Your Business Process Model. We realize this isn’t standard for many business process models, but when moving from business to explicit modeling we found it extremely helpful. You can either create a “system” swimlane on your model or tag steps with the system name. Either way allows easier identification of the system receives, invokes, and replies necessary in the executable BPEL models.
• Use Business Scenarios at Each Stage to Demonstrate Relevance. For this project we developed business scenarios (i.e., Use Cases) during the Enable Stage and found them extremely helpful in validating the model. However in subsequent projects we’ve started developing them during the Model Stage with much success. It allows us to validate our business model and rules and creates a bridge between the Business Process Models and the Executable Process Models. This tool ensures that the executable process is truly driven by and links back to the business process. It’s also gives you a great start on test cases for implementation.

We admit that nothing we’ve listed here is rocket science. In fact, I’m surprised we did not realize and implement many of these things earlier. Evidently we didn’t find it “relevant” at the moment. It’s our hope that you have a better frame of reference for applying these lessons and will be able to further reduce the perceived gap between Business Modeling and SOA.

Ms. Adams is the Managing Partner of Chaosity LLC specializing in Business Process Analysis and Project Facilitation. For the past 12 years, she has worked with project teams in a variety of industries to elicit, capture and translate their shared knowledge about processes, products and services into tangible improvement. Ms. Adams is a Certified Professional Facilitator and currently serves on the Board of the International Association of Facilitators. She is a Certified Quality Manager and co-author of the books “Facilitating the Project Lifecycle” and “The Project Meeting Facilitator”.

Mr. Myles is a KeySpan IT Manager with over 20 years of experience in IT project development and implementation. He has spent the past year working in his company’s Business Process Management Center of Excellence as a Process Lead/Architect on various BPM initiatives.

Bookmark / Share This

Bookmark or share this with others.