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.
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.
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.
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.
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?
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.
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
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.
- Participate in the discussion forum.
-
Read the developerWorks article "
Creating an ideal SOA team."
-
Read about
SOA maturity and methodology.
- The developerWorks article "
Service-oriented modeling and architecture," by Ali Arsanjani explains how to identify and model SOA services.
-
Read about an SOA maturity model from Sonic Software.
-
Read the developerWorks article "
Capturing business requirements using use cases."
- Read more about the Capability Maturity Model at the SEI Web site.
- Read more about Rational RequisitePro at the IBM Web site.
- Discover how Rational Software Architect can help you to easily create SOA applications.
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.
