Level: Introductory Kunal Mittal (kunal@kunalmittal.com), Director, Domestic TV IT, Sony Pictures Entertainment
12 Dec 2006 In this article, you model use cases and business requirements for services for Service-Oriented Architecture (SOA) projects. You also learn how to best capture and document these requirements.
Overview
In the first article in this series you learned about determining technical requirements for your Service-Oriented Architecture (SOA) project. It started with a debate about the reasons for examining technical requirements before business requirements. Although there is no "correct" answer, but in my experience most, if not all, SOA projects are led by information technology (IT) departments, discussions tend to begin with technology. The previous article explores the details of different types of technical requirements and the various gotchas! that you need to watch out for when capturing these requirements.
In this article, you learn more about the business aspects of SOA projects. You'll understand key aspects of the business requirements you need to capture as part of your initial SOA services rollout. You'll also learn about fundamental requirements techniques you can use to capture these requirements (although it's more important to address the "what" than the "how").
This article's scope covers the requirements process to identify and build out the first few services in your SOA project. The third and final article in this series takes you from these first few services to gathering, documenting, and managing the requirements for an enterprise SOA rollout.
Getting started
This article assumes that you have a well-defined SOA initiative. You've identified a basic set of technical requirements for your SOA and are now asking yourself, "What SOA services should I build?" Different IT groups within your organization may be saying different things: Some may want to build technical services, such as a content management service, security (authentication/authorization) related services, or something else. However, the key to an SOA project is your first set of business services. I won't get into a debate about where to start -- I assume you're starting with business services. Let's first examine ways to identify those business services.
 |
A word of advice
Any SOA project is a hard sell. In most cases, the initial project doesn't have a short-term return on investment (ROI). You need to make sure you have a pragmatic SOA roadmap that you can sell to the people who control the pocketbook -- the business leaders. Partner with your business leaders early on, and find an executive sponsor on the business side (other than your CIO or CTO). This is critical to the success of your SOA project. Not only will it help you keep the project funded, but it will also make sure your business community participates in the SOA project and takes the time to understand what's in it for them.
|
|
Service identification
Let's touch on some basic ideas of how to identify the first service or the first few services you're going to build as part of your SOA. These services need to be isolated in terms of impact to the business, and they must be fully scoped out. On the flip side, they should be significant enough to demonstrate the value and vision behind your long-term SOA roadmap.
Top-down service identification
In a top-down approach, you begin with high-level business use cases or business-process flows that exist within your organization. You can also start with a business strategy or an IT strategic plan presentation (which would include the business strategy). This is just a starting point for you to begin breaking down the processes into functional areas or subsystems. You lay these out for your entire organization and then start to identify any pain points, highly reusable use cases, or functions you can short-list for your candidate SOA services. Remember not to choose the most complex or controversial service.
The top-down approach is business driven: Business documentation exists that can serve as references to identify your SOA services. Figure 1
shows a simple set of steps that you could use for the top-down approach.
Figure 1. Top-down approach
Bottom-up service identification
In a bottom-up approach, you begin with existing systems or applications. You try to dig out any documentation that exists for these systems and then build your functional areas, subsystem maps, and higher-level business use cases from there. This may be more difficult, but in most organizations it's unavoidable because the high-level documents used in the top-down approach either don't exist or aren't up to date. The bottom-up approach appears to be more IT driven; the business lacks documentation of its strategy, functions, and core competencies.
|
Top-down or bottom-up?
You can locate articles on the Web that prefer one style over the other. In reality, most organizations use a hybrid of these two approaches. It's important to understand that the top-down approach is more business focused -- with a complete absence of that approach, you're likely to have a harder time over the course of your SOA project. This is primarily because SOA can succeed only when it is business-focused rather than purely IT focused.
|
|
Figure 2 shows a sample bottom-up approach for service identification. It's not that much different from the top-down approach -- but the starting point is very different.
Figure 2. Bottom-up approach
See Resources for an informative article that drills much further into the concept of service identification.
Gather the requirements for a single service
This section drills into one service. It discusses the types of requirements and the process you need to follow to gather the requirements for a service in your SOA.
Types of requirements
You're ready to capture the requirements for your first SOA service. In a broad sense, you need to capture requirements in the following categories. Remember, this article focuses on the business requirements -- the previous article talked about the technical requirements for the service(s):
-
Accessibility. How does the user of the service find and access this service? This requirement borders being a technical requirement and a business requirement. For now, think of the business process that needs to find and invoke the service you're building.
-
Functionality. What core business process or function will this service provide? What business problem are you solving? This discussion can become very long. You must determine the appropriate granularity of what becomes a service in your SOA. (See the Resources section at the end of this article for articles that discuss this in more detail.)
-
Interaction. How does the service or application that calls this service interact with the service? How does the service handle error conditions?
-
Information. What data is sent to this service and back from this service?
-
Process. What are the relationships between the actions and events of this service?
Requirements process
Now that you know the type of information you need to capture as part of the requirements for the service, let's talk about the process. In a non-SOA world, you would need the users of the service or application to describe in business terms what they want the service to do. In an SOA, you don't always know all the customers (or potential customers) of the service. In this case, you need the service providers (the business stakeholders for whom you're creating this service) to describe what they want the service to accomplish. You should validate this description with a few known customers of the service -- but you can't and shouldn't try to reach all the potential customers. Doing so isn't feasible.
|
Meeting the needs of the business team
The business wants the application on time and on budget. Management wants more with less. They want results more quickly then before. They don't care how IT does it. These are all true statements. Many IT leaders resist partnering with the business on SOA due to these realities. The business doesn't care about the implementation details of your SOA. However, management needs to understand the fundamental concept of services -- how to think of their business and business processes in terms of services, and how to identify the services they can reuse across business functions.
For your SOA project, you need to clearly articulate business-user involvement as one of the project's biggest risk factors. You must get management involved and show them the value of SOA and how at the end, you will deliver the only things they care about -- on time, faster, and cheaper.
|
|
From a process standpoint, you need to get the service providers to describe the service functionally and nonfunctionally. You first capture all the types of information described in the previous section using any requirements methodology or tool: IBM® Rational® Unified Process and IBM Rational RequisitePro®, or a simple word-processing document in a spontaneous requirements meeting. At this stage, I don't want to recommend too formal a process. The idea is to quickly deliver a few services that demonstrate the value of your SOA. However, you should still document these requirements in some way.
Document the requirements for a single service
How can you effectively document the requirements? This documentation process helps you validate the requirements with the business in order to get sign-off, and it helps you communicate the requirements with the technical team that will implement the service.
You've probably used use cases in the past. This is an excellent technique to capture requirements for your SOA. Figure 3 shows an example of a use-case template you can use to document these requirements. Rational RequisitePro and other Rational tools come with many other templates you can use. The point is not which template you use. As long as you capture the type of requirements described earlier, you'll be OK.
Figure 3. Use-case template
Summary
So after reading this article, you should how to identify a few initial services as part of your SOA project. You also learned how to gather the requirements for these services and document the requirements using existing requirements processes and techniques. The article "Creating ideal SOA teams" (see Resources) explains how to structure your team more effectively and the role of the business analyst in your SOA project.
The next article shifts gears to assume that you're planning an enterprise SOA -- your pilot was successful, and you're ready and funded to launch a widespread SOA program. You'll learn more about how to gather, manage, document, and communicate your requirements for this larger and significantly more complex undertaking.
Resources
About the author | 
| | Kunal Mittal is a consultant specializing in Java technology, J2EE, and Web services technologies. He is the coauthor of, and has contributed to, several books on these topics. He works as a director within the Domestic TV IT group for Sony Pictures Entertainment, where he's responsible for the technical architecture and management of applications for that division. In his spare time he writes for IBM developerWorks, consults on SOA, and is a private pilot. For more information, visit Kunal's Web site at www.kunalmittal.com or contact him at kunal@kunalmittal.com. |
Rate this page
| 
