Introduction
SOA projects tend to be large initiatives with a lot of risk and potential reward associated with them. The Return on Investment (ROI) on a SOA project is sometimes very hard to quantify (and thus hard to sell), which brings about the need for a solid process and methodology to ensure the success of an SOA project.
A SOA is a set of tools, technologies, frameworks, and best practices that enable the quick and easy implementation of services. In addition, the process of developing a SOA uses methodology for identifying reusable services in your applications and organization. SOA is not a product or a standard.
The architecture is focused on allowing enterprises to identify, build, exchange, and maintain their business processes as services rather than as large, monolithic applications — applications that today are often termed “instant legacy.” SOA existed well before Web services. (If you think back, CORBA and IDL were just flavors of SOA.) However, as Gartner puts it, “Through 2008, SOA and Web services will be implemented together in more than 75 percent of new SOA or Web services projects (0.7 probability).”
The technologies that enable SOA are targeted at reducing the complexities involved in software development. They address issues with distributed software, multiple platforms, and application integration. SOA provides an application architecture in which you define processes as services that have well-defined interfaces. These services can be dynamically invoked over a network. For the Chief Information Officer (CIO), SOA enables faster time-to-delivery of business processes and cost reduction resulting from reductions in development and maintenance costs.
This three-part series is designed to tie industry-adopted processes and methodologies to SOA and demonstrate how you can use them together. This article introduces you to the process (namely, CMM) and methodology (namely, RUP) underlying SOA and lays the groundwork for how and why they can benefit your organization’s SOA project.
Software process
The Software Engineering Institute introduced Version 1.0 of the CMM in 1991. A model used to describe the principles and practices of software process maturity, the CMM is a recognized benchmark for assessing software process maturity. The model’s aim is to increase the effectiveness of information technology (IT) organizations to deliver software products or projects by making the software process more predictable and repeatable.
Process repeatability is important, because the software process has to be applied consistently and methodically for organizations to deliver high-quality products or projects on time and on budget. Best practices that are defined need to be shared across software teams and be adaptable to the needs of individual groups.
The CMM defines a model that organizations can use to assess their software process maturity, but it also defines a model that you can use to advance from one level to another. The five maturity levels that the CMM describes can be characterized by the primary process changes made at each level:
1. Initial: At this level, the software process is characterized as ad hoc and chaotic. Success is individual-based, because very few, in any, processes are defined.
2. Repeatable: Basic process are defined and repeated consistently by an individual project team on similar applications.
3. Defined: The process is well defined, documented, and standardized. All projects within the organization use the same software process, tailored to their specific needs.
4. Managed: The software process is managed in terms of applicability and quality. The process has been examined quantitatively and controlled.
5. Optimizing: Continuous process improvement is enabled by quantitative management. New technologies and processes are incorporated to respond to the changing technology and business marketplace.
Why should CMM be applied to an SOA project?
The application of a process maturity model, for software development, such as CMM can help you identify the need for an SOA in your organization. Doing so can also help you quantify the costs and benefits of an SOA for purposes of establishing a solid ROI for the project.
In the second article in this series, I will actually introduce a new version of CMM that I call the SOA Maturity Model. The SOA Maturity Model allows you to apply the CMM to the IT architecture of your organization. Similarly, by using this model, you will quickly be able to build a vision, scope, and plan for your SOA project as well as determine key performance indicators for its success.
Product companies and consulting firms can also leverage the SOA Maturity Model to line up their products and services so that organizations can get from a lower level of architectural maturity to a higher level.
After you have a process and have determined the need for an SOA, the next step is to identify a methodology that you will use to build your SOA. You also need a methodology for the ongoing maintenance of the SOA project after you have rolled it out to your organization.
Software methodology
A software methodology is a systematic approach and control of how to develop software. Basically, a software methodology addresses the “hows” of software development, while the CMM process addresses the quality of that methodology and the software produced using the methodology.
Two distinctly different methodologies can be used with SOA: RUP and XP. RUP is a more traditional, heavyweight technology that’s particularly appropriate for large and complex projects. In contrast, XP is a more lightweight, agile methodology that is particularly suited for Internet-based development.
I have chosen these two methodologies because I believe that an SOA project has two high-level phases. The first phase is initial SOA rollout, in which you actually build your SOA. This phase requires a methodology like RUP. The second phase is SOA maintenance, in which new projects build on top of the initial SOA. This phase can benefit from a lighter methodology such as XP. (More on this later.)
What is RUP?
RUP is an IBM product offering that provides an out-of-the-box software implementation methodology. The first iterations of RUP were focused more on requirement gathering and less on software development. Now, RUP requires the use the Unified Modeling Language (UML) for system design and also encourages creation of a full prototype during the initial phases of a project that includes all functional and technical layers for the final target system. Building such a prototype can become complex as developers attempt to solve all the nonfunctional requirements during the prototype phase.
Although RUP is adaptable to fit the methodology of any organization, it is a very prescriptive, heavy methodology designed around the software implementation process. It breaks software development into four distinct phases: Inception, Elaboration, Construction, and Transition. The Inception phase is generally where you define the vision and scope for the project and develop the initial Return on Investment (ROI). You complete the requirement-gathering and design processes in the Elaboration phase. The most time-intensive phase is the Construction phase, which corresponds to the traditional development phase of a project. In the Transition phase, you deploy the system to production and manage the first round of support. It is important to realize that almost every organization that is using RUP has probably tailored it somewhat. For example, you could do all requirement-gathering in the Inception phase and make the Elaboration phase the phase in which you do your design work. Regardless of how your organization might have tailored RUP, the fundamental concepts remain the same.
The RUP process is well supported by the IBM Software Development Platform toolset. The IBM Software Development Platform and the IBM Rational Suite® have built-in features to support Web services and SOA development. IBM Rational® Software Architect and Rational Software Modeler allow you to quickly model your SOA, and the development tools in the Rational Suite allow you to build and deploy your SOA.
What is Extreme Programming?
Extreme Programming is a fairly new software development methodology that gained tremendous momentum during the internet boom. XP encompasses concepts such as short iterations, pair programming and test before coding. About seven years old, XP has already been proven in cost-conscious companies like Bayerische Landesbank, Credit Swiss Life, DaimlerChrysler, First Union National Bank, and Ford Motor Company. XP has been successful because it stresses customer satisfaction. The methodology is designed to deliver the software your customers need when it’s needed.
XP empowers you to respond confidently to changing customer requirements, even late in the project life cycle. It introduces the concept of defining small user stories using the Class-Responsibility-Collaborator (CRC) cards technique or other definition methodologies. (User stories are the XP equivalent of use cases.) XP is a quick and effective method of capturing requirements and organizing them into logical iterative builds, assigning priorities, and developing the user stories. However, XP does not cover validation of the requirements. Yes, XP presents an optimized methodology to develop requirements, but if the quality of the requirements is not addressed, the result might not be satisfactory. This is exactly why in the third article in this series I distinguish between when to use XP and when to use RUP as part of your SOA rollout.
And now…
This article has introduced the basics of SOA and skimmed the surface of concepts such as the CMM, RUP, and XP. In the next two articles in this series, I will combine these concepts to provide a framework and methodology for building your enterprise SOA vision.
In the second article in this series, I will use the CMM to define an SOA Maturity Model, which can help you grade your organization in terms of architecture maturity and define a series of steps to get to a higher level of maturity (with a true SOA being the highest level of maturity).
In the third article in this series, I will introduce a new software development methodology that is a hybrid of RUP and XP: SOUP. SOUP breaks up the software-development process into two phases: It uses RUP to build your SOA, then switches to XP to maintain it.
