Introduction
Typical SOA initiatives can potentially suffer from one or more of the following problems:
- High complexity and short time to market, leading to an increased risk of failure
- Low tolerance for failure because of high costs and difficulty quantifying return on investment (ROI) associated with the SOA project
- Dynamic requirements and business needs that need proper managementYou need an adaptable software methodology — a systematic approach to the way software is developed — that can provide rigid controls and processes during the initial SOA rollout but also be adaptable to change and streamlining as you move toward an optimized SOA. Before you consider the software methodology outlined here, you should read the second article in this series, in which I describe the service-oriented architecture maturity model.
But how can your enterprise make the transition from one level to another while still maintaining a coherent development process? In this article, I propose a best-of-breed hybrid methodology for building and then continually optimizing an SOA. I’ve nicknamed this methodology the service-oriented unified process, or SOUP.
What is SOUP?
SOUP is a software methodology that takes the best elements from RUP and XP. It is targeted specifically at SOA projects that are underway in any organization.
The major driving factors of a typical software development project are the application development process, project management, and the technologies used. These are all driven by the specific consultants assigned to the project. A generic software development project has four variables: time, budget, scope, and quality. Compromising on any one variable has an impact on the overall project. Because of changing business needs, scope and quality are the two most difficult factors to manage. Technological complexities can lead to problems with time and budget management, as well.
SOA projects are significantly more complex than typical software projects, because they require a larger, cross-functional team along with correspondingly more complex inter-team communication and logistics. Typically, an SOA is not well defined, and the vision for the final result is thus often not clear at the project’s inception. An SOA can have a very positive impact on an organization, but it comes with a potentially high price tag. The key factors that can help an SOA rollout succeed are a clear definition of the development process, enhanced lines of communication across project teams that know the business, and clear support and governance policies.
SOUP is a six-phase approach to software development. Each of these phases represents a distinct set of activities critical to the success of an SOA rollout. Of course, as in any project, you need to tailor the process to your own organization.
Figure 1. The SOUP process
I break the use of the SOUP process into two categories.
- SOUP for initial SOA deployment
- SOUP for ongoing SOA management
SOUP for initial SOA deployment
Let us take a look at each phase of SOUP as it applies to initial SOA rollout.
Figure 2. SOUP and RUP
Incept
In this phase, you establish the need for an SOA project in your organization. You can apply the SOA maturity model to determine your organization’s level of architectural maturity and determine the basic driving factors towards an SOA. In addition, at this point you would explain the basics of the SOA concept to all project teams serving the business and plan a strategy for a feedback and suggestion process.
The key deliverables of this phase are:
- SOA vision and scope.
- SOA strategy.
- ROI analysis.
- Communications plan.
Clients do not always fully understand the benefits of new software products in their business. The enterprise teams that define the SOA strategy need to leverage the domain experience of the project teams to help identify business problems and ways and means to streamline operations.
Cross-functional analysts and project managers analyze the business of the clients to determine the advantages of an SOA-based solution. The key factors analysts examine are the clients’ internal operations; interactions with their partners, suppliers, and consumers; and their overall business model. These help the analysts develop and recommend an SOA strategy.
An ROI analysis should clearly show the cost benefits to the organization — in the short, medium, and long term. The single most important deliverable at this stage is the communications plan. Ultimately, project IT teams and the business stakeholders know the business better than the architecture teams and analysts. The communications plan ensures that these internal stakeholders understand and are involved in the process.
Define
This phase is by far the most critical of the SOA project. Business and project team involvement here ultimately determines the project’s success. Team members need to be committed to participating in the definition the requirements and use cases developed as part of the initial SOA rollout.
This phase of a project lifecycle involves such activities as:
- Requirements gathering and analysis
- Nonfunctional requirements definition
- Project plan with timelines and estimates
- Technical infrastructure definition
- Use case definition and realization
- Overall architecture definition and documentation
The key deliverables of this phase are:
- Functional and Nonfunctional requirements document.
- Use cases and use case realizations.
- SOA architecture and applicability document.
- Infrastructure definition document.
- Project plan.
- Support and governance model.
Various studies have shown that requirements-related issues are the number one reason for the failure of software projects; SOA projects are no different. Software quality is sometimes defined as software’s conformance to its requirements. However, the quality of software is probably better measured by the quality of the requirements it meets, not just the number of requirements it meets.
As the descriptions of the deliverables should make clear, the SOUP methodology recommends a formal requirements-gathering and management process. XP does not really define a formal process to gather and document requirements; instead, XP developers create user stories and try to put these stories in a logical order to provide a sequence to requirements. For this stage of development, such a process is inadequate. In RUP, the process is more detailed and uses more formal techniques to ensure that requirements sessions are complete, documented, and validated. I recommend the use of a requirements repository that will ultimately tie into use cases, design, and code, providing traceability through the project. A change management process is also important.
In my opinion, the most important deliverable in this stage is the support and governance model. How will the organization support the SOA? What are the governance guidelines?
It is important that the business start the project with a realistic set of plans and objectives. Extra or superfluous requirements should be left for later. An effective business-to-IT (B2IT) collaboration on requirements that are achievable for the expected time and budget can set up the project for success from the beginning.
You define the technical infrastructure required to support the entire SOA early in the life of the project. This includes detailed estimates on servers, network infrastructure, training requirements, and so on. A realistic and pragmatic approach to planning will always be successful.
Design
In this phase, you elaborate on the design artifacts from the Define phase. The use case realizations and the software architecture document translate into detailed design documents.
At this time, SOA architects (typically a subset of the enterprise architects) need to involve project architects to make sure the design presented by the SOA team will work for specific projects. The SOA architects might even choose to do a couple small proof-of-concept projects to prove the SOA vision. The key deliverables of this phase are:
- Detailed design document.
- Application programming model.
- Database model.
- Testing and QA plan.
Construct
During the Construct phase, you can basically use any iterative build methodology you like to build your SOA. This phase involves new development as well as integration activities. Your activities are not limited to software but can also involve infrastructure-related subprojects, such as hardware consolidation projects or efforts to centralize hosting of servers. The overall effort is managed in a single SOA project plan, but in all probability various small sub-teams will be working on different construction activities.
This phase of a project lifecycle involves such activities as:
- Iterative development
- Iterative QA and testing
- User documentation
The key deliverables of this phase are:
- Code base.
- Test results.
- Documentation.
Deploy
In this phase, you actually deploy your SOA. You roll it out to individual project teams, who start using the SOA on their projects in a production setting. Perhaps the most obvious key deliverable for this phase is your application in production. However, even more important is the plan that establishes the projects that will pilot the SOA. This leads into the next step of the SOUP methodology, which determines how ongoing projects will use the new architecture. The other key deliverables of this phase are:
- Deployment model.
- Usage model.
- Ongoing support levels model.
Support
Although this is the final step of the software development cycle, it is nevertheless a very important phase. In this phase, you ensure ongoing SOA support, bug fixes, and new functionality development. This phase of a project lifecycle involves such activities as:
- Maintenance
- Bug fixes
- Training
- Continuous project buy-in
At this point, your SOA is in production. But how do your project teams benefit from the architecture? Do they now need to follow all the steps described above in detail when building applications that consume existing services or when designing new services that make use of an existing SOA? As you’ll see in the next section, they can in fact benefit from a more lightweight methodology.
SOUP for ongoing SOA projects
The SOUP methodology can still be useful for projects that are using an SOA that has already been rolled out. In such situations, SOUP draws more heavily on XP for inspiration.
Figure 3. Overlaid SOUP and XP processes
What is the key premise here? The value of the SOA project is that it provides a well-defined architecture and firm technology guidelines. You have a framework on which to build your applications as services. The project teams’ main tasks are building and consuming services. They are most fit to perform these tasks because they have the necessary business domain knowledge. However, they do not need to worry about the technical architecture or invention of technology, as that is left to the SOA teams.
Incept
When you’ve got an SOA up and running, there’s still development work to be done. You’ll no doubt want to build projects that consume existing services or expose new ones. In the Incept phase of such a project, you establish the project’s overall scope and vision. The key deliverables of this phase are:
- Project vision and scope.
- Project strategy.
- ROI analysis.
Define
In this phase, you build the tie-ins to the SOA project and understand how to leverage the SOA. You need to identify the services that the SOA already makes available and those that still need to be built to meet the goals of your project.
This phase of a project’s lifecycle involves such activities as:
- Requirements gathering
- Services identification
- Establishing a project plan with timelines and estimates
- Test case development
The key deliverables of this phase are:
- Functional requirements document.
- Use cases and use case realizations.
- SOA applicability document.
- Project plan.
- Services strategy.
- Test plan.
The requirements gathering in this phase does not need to follow the formal standards that were followed during SOA rollout. Instead, you can make use of agile requirements gathering involving user stories or Class, Responsibilities, Collaborator (CRC) cards. In line with XP thinking, test cases are built early on in this type of project.
Design
This phase is really quick, because most of the design was completed in the initial SOA rollout. In this phase, you only have to worry about how to use the services, what more needs to be built on top of the existing services, and what new services need to be built.
The key deliverables of this phase are:
- Detailed design document.
- Database model.
Construct
This phase involves more assembly than new development. As more services become available, each project will have more to reuse and less to build. XP’s iterative development techniques are ideal at this stage of development. In XP, iterative cycles are theoretically set at two weeks, which should be more than ample time for one development-QA cycle when building a small service or consuming a set of services in an SOA environment. With this iterative approach, an SOA can provide valuable business agility via quick software releases.
This phase of a project lifecycle involves such activities as:
- Iterative development
- Iterative QA and testing
- User documentation
The key deliverables of this phase are:
- New services.
- Test results.
- Documentation.
Deploy
In this phase, you either launch an application that consumes several services, or you launch new services. The infrastructure is managed by the SOA team; thus, this process is relatively straightforward.
Support
In this phase, you are only providing support for your new services. In doing so, you will follow the support guidelines laid down during the original SOA project; thus, individual projects don’t need to spend much time developing new support guidelines.
Managing the SOA lifecycle
This article has introduced SOUP, a new software methodology for building your SOA and then realizing the benefits of the architecture on individual projects. I’ve taken a very high-level look at how this methodology would work, transitioning from an RUP-like methodology (for initially building an SOA) to an XP-style agile process (for ongoing services rollout). By combining the best qualities of these two processes, you can rely on a unified development scheme that nevertheless provides the flexibility needed to manage different stages of an SOA’s lifecycle.
