|
Latest Articles
|
|
|
|
|
Business Analysis in a SOA World |
|
Written by Kyle Gabhart and Kimberly Terribile, CBAP
|
 Service Oriented Architecture (SOA). At first glance, this seems like the sort of thing that only software architects and application developers should be concerned with. Upon further investigation, it is clear that while the technology team is intimately involved in implementing a Service Oriented Architecture but, there are other essential (and sometimes overlooked) roles such as the Business Analyst. Before you can implement SOA, you have to analyze your business and understand the core functions you perform. Getting a handle on your organization to support a SOA strategy is not for the faint of heart. It requires significant commitment from the “powers that be” and a commitment to investing in the initiative from a strategic enterprise perspective. Additionally, there are huge chasms in understanding and perspective regarding what SOA is about and how best to go about service orienting the enterprise. This leads to tremendous communication challenges as each division or even each team perceives and approaches SOA in a different manner. Developing a shared vocabulary and a common understanding of service orientation and how it will be applied to align and transform the organization is essential. In many respects, the role of the business analyst is to bridge the communication gaps within the organization.
Bridging the Communication Gap
The business analyst is in the unique position of understanding both the technical and business components at work in the enterprise and is tasked with facilitating an alignment between the two. No where is this more prevalent than in the adoption of service orientation. There are two basic approaches that can be taken:
- A complete top-down decomposition of the enterprise, beginning with a comprehensive Enterprise Analysis and the creation of a Business Architecture
- A project-focused bottom-up creation of services and related business processes
Each approach has its short comings with respect to cost, time, and risk. In our experience, a blended approach is recommended (sometimes referred to as ‘meet-in-the-middle’). This blended approach involves the following steps:
1) Documenting your business architecture
2) Modeling out your high level business processes
3) Selectively service orienting key systems and or processes
Documenting your Business Architecture
In this case, the first part of embarking on a SOA journey is understanding and documenting your Business Architecture. Don’t run screaming yet. Documenting your Business Architecture does not have to be a complicated endeavor. In simple terms, it involves creating a visual representation of your core business activities. It is very helpful to create a small team of people that can think about and analyze the business without thinking about the current organizational structure, project teams, or systems employed within the enterprise. A fresh analysis of your business, unimpeded by the status quo, is desired at this point. Throughout this paper, we will examine a fictitious company in the insurance industry for the purposes of illustration and application of concepts. We have extensive experience working with various companies in the insurance industry and there are several high profile examples of business architecture and SOA that our illustrations draw upon. The particular company explored here is a fictitious composite based upon actual experience. We Got Your Back (WGYB) is a midsized insurance carrier that provides health, term life, and whole life policies for small businesses. The example below represents the high level business architecture for WGYB. Once you have identified the highest level of “what your organization does”; you can begin to break it down from there. Documenting your high level view of the organization is an important first step in service orientinig your enterprise. From here you will need to conduct a detailed analysis and evolve the Business Architecture based upon this framework. It is critically important to your success to find people capable of understanding the business at this level of abstraction. It is not as simplistic as it sounds on paper. The interesting part of the paradigm is that because Architecture is in the title it implies an Architect should do this work. That is not necessarily true. You need to find and identify resources with an analytical mind to help cement these concepts. Additionally, these individuals need to have the ability to explain these concepts effectively to other people.
How do I identify my high level processes?
As you continue to move towards a Service Oriented Architecture, it will be important to identify all the high level processes within your organization. We recommend doing this in phases. Target one area of the business to use as a pilot and begin to document all the high level processes within that business unit. Several methods are available for this task. Recommended methods include the following:
- Review the goals and objectives of the business unit and begin to identify the high level processes they use to accomplish those goals
- Do a Business Use Case for the area to identify all the high level processes
- Create a Functional Decomposition Diagram to identify the high level processes
Returning to our case study of WGYB, you could take the Manage Claims area of the business architecture identified above and begin to think about the core activities in that area. Three primary actors readily come to the surface – member, provider, and claims representative. In thinking about that those three actors and the key business processes that occur within claims management, a handful of high-level business processes will likely fall out – Receive claims, Process claims, Research eligibility, Request more information. An illustration of this business use case diagram can be found in Figure 2 (see below). At this point, some businesses proceed to document their key processes with more detailed diagrams (Level 1 and Level 2). While this is certainly an ideal scenario and an excellent step to take, in our experience, few enterprises have the luxury to do a complete top-down redesign of their enterprise. Instead, these high level processes provide an essential framework for understanding the scope of business activity and the context into which specific projects fit.
Meeting in the Middle
Whether you start with the top down approach outlined above or you start with the current and future state business processes for a specific business area, your next step will be to analyze more detailed process flows. If you have a specific project that is a good candidate for service orientation, then ypou could attack that. Otherwise, you may choose to identify one or two candidate systems or processes that would make sense to service orient. Regardless of whether you selected a system or process or identified one based upon a specific project’s needs, the steps you will go through as a business analyst are the same:
1) Document the current state or “as-is” process
2) Collect requirements and identify measurable objectives
3) Document the future state or “to-be” process
4) Provide the technology team with a SOA blueprint
Business Process Flows
You can create business process flows using a variety of tools (back of a napkin, Visio, process modeling software, etc.). In the example below (Figure 3) we have created the current state business process for Process Claim. This is a simplified version of the actual process claims business process used within WGYB, Inc. In this example, we are going back to the days before massive claims engines when a Claims Representative reviewed and “processed” the claim. He/she would go through all the edits and make a determination as to whether the claim should be paid or not. The management team within WGYB has provided some requirements for the future state of this business process. An automated claims engine is requested and a step within the process is requested to determine if the healthcare service required prior authorization and a verification check regarding that authorization. In the future state process flow (Figure 4), the Claims Representative has been replaced by a Claims Engine and new edits have been added regarding Prior Authorization.
Provide the Technology Team with a SOA Blueprint
Once you have your business processes documented and you can lay them all out in front of you, it’s time to put on your heavy duty analysis hat because you are going to know these process models inside and out. It is during this step, you will begin to identify possible candidates for “services”. Analyzing your business process from a service oriented perspective involves two major steps: mapping process activities to potential service operation calls and then organizing those operations into logical services.
Step 1: Mapping process activities to service operation calls
Within the context of a business process, each activity will translate into a service operation call (see Figure 5). This is true regardless of whether or not any other business unit can benefit from that service. We have already defined a business process as a set of activities. In SOA, these activities are performed by services (service providers include software, people, and machines). Each service is capable of performing a set of tasks. The business process orchestrates these services together to perform specific tasks accordingly to the activity flow and business logic embedded within the process. In SOA, the business process is actually a piece of software. This software controls the sequence of activities. This effectively automates the whole business process, although, some of the activities in that process may be done by people. Before a process was automated, people used to manually control the flow of activities. This is not an easy thing to do and mistakes were common. An automated process is likely to make the process execution more accurate.
Step 2: Organizing operations into logical services
After a list of service operations has been assembled, the next step is to organize those operation calls into logical services (see Figure 6). It is important to understand that we are not actually defining specific services at this point; we are simply analyzing the business process to take a business view of the problem and translate it into a logical mapping of services to fulfill that process. A technical architect will come along later to review the logical set of services and modify the list based upon opportunities to reuse existing services, alignment with enterprise strategy or similar objectives outside the scope of this process. The role of the business analyst is to provide a coherent mapping between the business process and services that could potentially enable that process. The process of identifying services that correspond to the activities within the business process enables the linkage between the process modeling view of the things and the service oriented perspective. The end result of this activity is a business blueprint that can be handed to the technology team. The business process diagram, along with detailed requirements and a mapping to logically identified services gives the technology team a starting point. Moreover, this is a starting point that aligns closely with the business. In more advanced service oriented environments, powerful business modeling tools can be used. These tools are capable of translating the visual model into an actionable format that the technology team can begin using immediately.
Summary
Applying the principles and best practices of business analysis into a SOA world is not trivial. At the same time, it’s not rocket surgery either. It simply requires a disciplined approach and willingness to learn about and adapt to the new perspectives and priorities that a service oriented enterprise emphasizes. The benefits for organizations that take the time to do the upfront analysis and truly understand and document the services from a business perspective are significant. It can create a paradigm shift within your Information Technology department where the focus is on the business and technology is the enabler rather than the other way around. It will also allow the organization to become more agile and adaptive over time. The only catch is putting in the work and detailed anlysis so you have a solid foundation from which to build. There’s an old adage ‘measure twice, cut once’. If you don’t spend enough time in analysis and design, then you will find yourself re-factoring your content over and over. There is a critical gap in many enterprises that adopt a service oriented approach to doing business. That gap is the chasm between business and IT. The role of the business analyst has never been more important than it is today.
Kyle Gabhart is a strategist and subject matter expert specializing in SOA, EA, BPM, MDM and currently serves as the SOA Solutions Director for Web Age Solutions, a premier provider of customized technology education and mentoring solutions.
Kimberly Terribile is a CBAP-certified business analyst with extensive expertise in business analysis education and mentoring. She currently serves as the Director of Product Development for B2T Training, an education firm specializing in business analysis training.
|
|
|
|
