The first article in this series discusses the technical requirements for Service-Oriented Architecture (SOA) projects. You delved into the reasons for examining technical requirements before business requirements. You also explored the details of different types of technical requirements and the gotchas! you need to watch out for when capturing these requirements.

In the second article in this series, you went through the requirements process for your first SOA services, including understanding the different types of requirements that you need to gather to start your SOA project and build the first wave of SOA services.

Now you discover how to move from the first set of SOA services to a mature SOA platform, including the requirements you must address before you can roll out an enterprise SOA platform. The focus here is on the business; the article doesn't get into technology products such as an Enterprise Service Bus.

Enterprise SOA

The previous article in this series talks about the business requirements for your first wave of SOA services. At this stage, you chose at most three to five services. Now we're going to talk about the business requirements for your enterprise SOA.

Enterprise SOA (as the term is used in the context of this article) refers to an organization that has tens or hundreds of services. These include a collection of internal services (used by customers within your enterprise), partner services (used by your business customers), and customer services (both your business-to-business customers and maybe your end customers or the consumer). Your SOA project is moving from pilot to wide adoption. You're starting to see your company as a mature SOA organization -- or, rather, as a maturing SOA organization.

At this stage, you're probably past the question of whether you should do SOA. Funding is not an issue -- you've justified the value of SOA. Of course, you'll probably still face funding challenges over individual services or sets of services, but no one is questioning the value of your SOA overall.

Back to top

Technical requirements for enterprise SOA

Although the majority of this article focuses on business issues, we need to first look at some basic technical concerns.

Requirements from your initial SOA

The requirements for your first SOA services, as discussed in the previous article, focus on five main categories.

• Accessibility. With hundreds of services, you need to define a solid way for your customers to find the right services and know how to use them effectively. I tend to stay away from promoting registries or Universal Description, Discovery, and Integration (UDDI) during initial SOA. A good threshold for beginning to use a registry is 50 services. There's no magic number and no basic guideline for what number to pick; this is a decision you need to make.
• Functionality. As you build more services, it's important to analyze the functionality for each service. Make sure you minimize overlap. For example, can the new service you're building be a composite of existing services? And, is this service really new, or is it just a different incarnation of an existing service?
• Interaction. At this point, you probably don't know what you don't know. You can't predict how (with what technologies), when, where, or why someone will decide to use a particular service. Your service interaction must be well thought out and very standards oriented.
• Information. This area doesn't change regardless of the number of services. Just keep in mind that as you have more services, the amount of information flowing through them must be managed. The use of common vocabularies becomes important, and you need to start thinking of existing XML standards or new ones that you can define and adopt.
• Process. How do the 50, 100, or 200 services in your organization work together? How do these processes change, and how do the changes affect each individual process?

These categories still apply to each of the services that you'll roll out as part of your enterprise SOA. However, the definitions for the things you need to worry about in each case are expanded. This article points out the additional information you need to capture -- this doesn't replace what you captured for each category in the previous article.

Additional requirements for an enterprise SOA

What additional requirements do you need to collect for a true enterprise SOA? Remember, the concept of enterprise SOA is based on change. The fundamental business requirement to use SOA is enabling business agility -- also known as change. The main thing you'll learn as you start to collect these requirements is that no one really knows the right answer. You need to plan for change in each requirement category. A successful enterprise SOA is always in a state of flux -- it's constantly evolving and enabling change.

The high-level categories for such requirements include:

• Orchestration. You have evolved from having a few services that interact with other application or applications to having services you built that interact with others you built or with other services that other companies built. Orchestration or modeling between these services is vital. As part of your requirements, you need to make some assumptions about these interactions and plan for them. It's important to document asynchronous interactions, service versioning, retirement planning for each service, and so on.
• Security. Undoubtedly, security concerns will be raised. Make sure you take security seriously in terms of your SOA services. Who can access which service? Who can access what data within each service? And how is data secured when it's transmitted between services?
• KISS (keep it simple, stupid). How easily can anyone who wants to use the service actually use it? This requirement borders between business and technical requirements, but you must get your head around it. Make minimum assumptions about the business and technical maturity of any potential consumers of your service. The services should be easy to invoke, function well, have good error reporting, and generally be able to integrate with other services. A less-mature company should be able to use your services without a huge investment in technology or major changes in its business processes.
• All the "-alities". Consider availability, scalability, reliability, and so on. How do these impact your SOA from a business perspective? Make sure the business and technical teams are in sync.
• Globalization. Do your services need to be localized for international users? How does this impact performance, availability, capacity, and so on?

At a high level, capturing requirements in these basic categories is an excellent starting point. Of course, each step includes much more detail, a lot of planning, coordination, and just plain good project management. However, the guidelines for the sort of information you need to capture can help you define your requirements process.

Technical requirements for your enterprise SOA

As you get into an enterprise SOA from a technical perspective, you need to be careful about your overall architecture. The demands on your services platform in terms of availability, scalability, performance, reliability, and so on are even more important than they are in a non-SOA world. You significantly increase your risk of losing business if your infrastructure can't meet the demands -- and you have no sure way of predicting or planning for this demand. So, be cautious: Plan ahead, and keep the communication loop open. Be proactive in terms of knowing the relevant business trends and how the services in your SOA will be used, what new ones are being built, customer trends for the services, and so on. Follow a process, and stay ahead of the curve in terms of capacity planning, management and monitoring, and proactive troubleshooting.

From a software architecture perspective, make sure you keep your eye on the changing SOA technologies, standards, and frameworks. Your services' customers are probably using many of the vast range of technologies available, so you need to continually monitor the technology trends and test your services with as many emerging technologies as you can. Plan for interoperability -- or, rather, predict interoperability challenges in terms of technology choices.

Back to top

Reviewing the requirements process

All of the typical requirements processes apply to SOA projects, whether you use a formal tool such as IBM® Rational® RequisitePro®, CaliberRM, or iRise Application Simulator, or if you use an informal tool such as Microsoft® Office Word or Visio. Draft two processes to gather the requirements for your enterprise SOA: one process to gather the requirements for each individual service, as described in the second article of this series, and a second process to gather requirements to see how that service fits into the existing SOA, as described in this article.

Create your templates for the use cases, or requirements document, or whatever metaphor you use to capture requirements, but make sure they have two distinct sections that map to these two processes. You can continue to use the use-case template shown in the previous article or extend it to capture the additional sections for the enterprise SOA services.

Back to top

Summary

In this three-part series, you explored the requirements process for the entire life cycle of your SOA project beginning with the technical requirements. The second article covered the initial requirements for your first SOA services. And this final installment wraps up the discussion by explaining the overall requirements for your enterprise SOA.

Remember, technology is the easy part of your SOA initiative. To make sure your SOA is successful, focus on the key areas addressed in these three articles. Document your requirements carefully, foster business-to-IT and IT-to-IT communications about these requirements, and stay alert. SOA is about change, so your requirements will continually evolve. Don't get caught off guard!

Resources

• Participate in the discussion forum.
  
  
• Read Part 1 and Part 2 in this series.
  
  
• Read about SOA Maturity and Methodology.
  
  
• The 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.
  
  

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 article

Comments

Back to top

Table of contents

• Enterprise SOA
• Technical requirements for enterprise SOA
• Reviewing the requirements process
• Summary
• Resources
• About the author
• Comments