Compared to traditional information technology (IT) projects, Service-Oriented Architecture (SOA) projects face more severe challenges when it comes to requirements gathering and requirements processes. Articles and research materials from leading firms talk about how the lack of proper requirements is the primary cause of failure in IT projects. You may have dealt firsthand with this issue as an IT project manager, architect, or developer. A significant number of projects go over budget and don't meet their timelines, due to missing, incorrect, or changed requirements. At the end of the day, technology doesn't matter: A project that has the most efficient architecture, is SOA-enabled, leverages all standard technologies, is robust, and performs beyond all expectations -- but doesn't meet the original business requirements -- is a waste of time and money.
Gathering requirements needs a unique skill set; it's both a science and an art. For example, you can't avoid the human factor -- people sometimes change their minds about what they want. It's unrealistic to assume that you can capture 100 percent of requirements or that requirements won't change. A good business analyst involves the users and sells them on the value of accurate requirements. The analyst demonstrates the extreme importance of the users' participation in this process and makes them take accountability for any changes or omissions. It's a case of "garbage in, garbage out" -- if you start with poor requirements, you're sure to end up with a product that isn't useful.
This article is the first part of a three-part series that delves into the requirements process for SOA implementations. This article concentrates on the technical aspects of SOA projects and how you should define the technical requirements for such projects. Part 2 of this series will demonstrate how to define requirements and create use cases for services that are an essential part of your SOA. Part 3 explores how to capture requirements for the ongoing management of your SOA. Throughout this series, I'll use IBM® Rational® RequisitePro® as the requirements tool to capture these requirements.
I won't go into the basics of SOA or what the different flavors of an SOA implementation roadmap can look like. You're probably reading this article because your organization has a defined SOA roadmap (or is in the process of defining one). Perhaps you've identified a starting point on this roadmap and have a funded project to build out the first three to five services.
You need to define two types of requirements at this stage: the requirements for your services and the technical requirements to support these services. This article focuses on the latter: the technical requirements. I'll cover the business requirements in the second article. But wait -- don't the business requirements come first, you ask?
As much as I'd like to focus first on business requirements, most SOA initiatives are led by IT rather than by the business team in collaboration with IT. IT groups tend to get caught up with new technology before the business does. They begin bringing up questions of governance, support, cost models, and so on. On a technology front, they start talking about Universal Description, Discovery, and Integration (UDDI) repositories, technology frameworks to build services, Enterprise Service Buses (ESBs), and so on. I've rarely seen IT groups talk about choosing a business service and doing a proof of concept (POC). They do pick a service, but then they focus heavily on the technology. They talk about what technology to use for the POC, what Extensible Markup Language (XML) standards to use, what platforms to use, what ESB to use, and so on. It isn't incorrect to start here; I haven't seen an SOA initiative slowed down or postponed until the next fiscal year because IT teams can't agree on these aspects of the SOA rollout. So, I'll begin here, too, and then move on to business requirements for the services.
Another reason for me to start here is the logical flow of this three-part series. This article incorporates all the tech talk; the next two articles will focus on the business; first, for the initial services and then for the maintenance and exploitation of those services.
Technical deliverables for SOA roadmap requirements
How do you capture the technical requirements for your SOA initiative? I assume you've identified three to five services that you plan to roll out as part of the SOA initiative.
To begin with, you must be able to support a handful of services. In order to do this, you need to define the following:
- Operational service-level agreements (SLAs)
- Support SLAs
- Implementation requirements for the services
- Deployment requirements
As soon as these initial services are in production, you can begin formalizing other technical requirements for your SOA. These include the following:
- Overall operational strategies for long-term SOA
- Governance around service discovery, provisioning, and delivery
- Best practices and patterns on service-oriented development
- Operational SLAs
- Support SLAs
This is the time to start thinking of ESBs, Web services management platforms, and other such technologies for making your SOA truly enterprise scale.
Capturing the technical requirements
Capturing technical requirements is never an easy task. For example, if you ask someone how fast they want a system to respond, they'll answer, "As quickly as possible." Technically, this requirement doesn't help much. In the case of SOA, capturing technical requirements becomes even more difficult. You need to be able to define operational levels for your services: response time, up time, average number of concurrent users, and so on. In addition, you must define service levels: how long it will take to fix a severity 1 bug compared with a severity 2 or 3 bug, how long it will take to build a new feature or enhancement, and much more. Gathering these requirements from the consumers of these services is definitely more of an art than a science. The science lies in defining the correct set of questions to ask. The art is in getting your customers to answer those questions in a concrete manner rather than with vague responses.
A technical architect or a technical analyst must meet with the consumers of your initial services and begin capturing this information. The success of your SOA project rests heavily on your team's ability to capture these requirements accurately and realistically. For example, suppose one of the requirements is that your system be able to support a million hits a second and a two-second response time. The amount of time and money necessary to satisfy this operational level may be devastating to the success of your project; for an SOA project pilot, you need to be able to start small and grow organically. On the other hand, if this service does need that extreme operational level, you may need to choose a different service or set of services for your initial SOA.
The SLAs and Operational-Level Agreements (OLAs) are the most difficult set of technical SOA requirements, because everyone wants the service to respond as quickly as possible, to be available 24/7, to support an infinite number of users, and so on. It's difficult to develop well-defined parameters for the service and even harder to balance these with the time and cost required to build the service and make it operational. Once you have the business requirements (discussed in Part 2), the SLAs, and the OLAs, you can begin to come up with your implementation and deployment requirements. As mentioned earlier, at this stage you shouldn't get hung up on technology, frameworks, tools, products, or even too many standards. Start simple, using SOAP and Web Services Description Language (WSDL) as the fundamental standards. Use .NET® or Java™ technology -- whatever your enterprise has chosen as a standard or has more experience in. Pick the bare minimum number of development tools. From a deployment perspective, use Internet Information Server (IIS) if you choose .NET. However, if you choose Java technology, use a simple application server such as Tomcat or Geronimo. You don't even need JBoss at this stage, let alone WebLogic or IBM WebSphere®. However, if your enterprise has standardized on a particular deployment container (WebSphere, WebLogic, or something else), by all means go with it.
The architect must be forward thinking. Start small, but always keep the big picture in mind. Let the implementation begin using whatever simple tools and architecture you have in place. As these services mature, you can define the overall technical requirements for your SOA. You'll have more empirical knowledge to make better decisions regarding your ultimate architecture, infrastructure requirements, tools and product requirements, and the level of each standard you want to adopt. The services you pick should have requirements that help you make decisions on a broader scale.
In this article, you focused less on learning about technical requirements for an initial SOA project and more on where to begin in the requirements gathering process. SOA provides grand visions. However, to achieve such visions, you should start small. Trying to tackle SOA in its entirety can delay your project and cost so much that your CIO might have trouble justifying its value to the business. You even risk having the initiative canned during the next budget cycle.
Approach your SOA project and the capturing of SOA technical requirements much like the Capability Maturity Model (CMM). When you begin, think of yourself at level 1 of the CMM. Don't try to solve problems at levels 4 and 5. Focus on a short-term SOA rollout, keeping the big picture in mind.
The next article dives into the business requirements for your initial SOA services. It demonstrates how to capture these requirements and uses Rational RequisitePro as the tool to do this. However, the ideas and concepts work with any tool; you can use Microsoft® Office Word or any formal requirements repository to capture the same information.
Learn
- Read about
SOA maturity and methodology.
- Read about an
SOA maturity model from Sonic Software.
- Read more about the Capability Maturity Model at the SEI Web site.
- Read more about Rational RequisitePro at the IBM Web site.
Get products and technologies
- Build your next repository with a trial download of Rational RequisitePro.
Discuss
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.
