Toward Reusable Business Services
If our goal is to elevate reuse to a point where the business can directly benefit from our efforts, we need our projects to deliver business services. Thinking about and planning for business services is also important for capitalizing on your success with the initial project-driven SOA initiatives and transitioning to the next level: either infrastructure-driven or enterprise-driven SOA.

What are business services?

There are several definitions, and they vary widely, depending on the context. In the context of SOA, services that provide functions related to one or more business processes and can be described with purely business semantics can be classified as business services. These types of services are typically composed from other, more fine-grained services, such as utility services. As we all know, a service is a logical grouping of semantically similar operations. For example, you may have a service named Customer with CRUD operations. Business services typically provide higher reuse value than utility, entity, data-oriented, and connector services.

There are essentially two ways of getting business services: (1) proactively prepare for them by putting together a service portfolio plan or (2) live by the law of the jungle - namely, let each IT group build services that populate the repository and can be reused by anyone. Although the latter requires no coordination between projects or departments (a huge advantage), the problem with it is that you invariably end up with an excessive number of services that frequently overlap and may not be useful beyond the project that implemented them. This service proliferation ultimately increases the costs and complexity of governance greatly. For example, you may end up with several services for customers, each of which has the following attributes and necessities:

• Similar operations
• Lifecycle management
• Operational management

Taking care of these duplicate responsibilities is a major headache and a costly exercise. So as we've been describing, you have to choose between pain now (planning to avoid the overlap and redundancy of services) or pain later, in the form of much higher governance costs and complications.

At a recent Gartner conference, a presenter spoke of an extreme case of duplicated effort. A major banking firm had a CIO with four direct reports, and he had mandated that they move toward SOA, having made it clear to everyone that he was retiring in two years. The four direct reports were in fierce competition for his job and, as a result, didn't work together or even communicate well between groups. Instead they wound up building four distinct SOA-based solutions that solved the same set of problems. Since then the CIO has retired, two of the direct reports moved on to other companies, and now the bank is in the process of consolidating the four SOA projects into one, paying way more in terms of time and money to undo the three extra SOA projects than it did for the initial investment.

Of course, one of the ways of ensuring that you don't get service proliferation is to put together a service portfolio plan - a key activity in the enterprise-driven SOA approach. Service portfolio planning is the iterative process of developing an enterprise-wide service portfolio. A service portfolio planning exercise helps in identifying and normalizing candidate services. Doing this at the enterprise (or domain) level with major involvement of the business, or at least within a significant domain of the organization, assists in finding services and their constituent capabilities that are aligned to where the business is going and are hence more likely to be reused in multiple projects. A service portfolio plan also helps in creating service blueprints that projects can use when building new services.

Typically, the first iteration of this exercise produces a portfolio of services that are mostly conceptual in nature. As projects get delivered, they will build out the services they need. These new services will conform to the specifications in the service portfolio, thereby ensuring that they're not project-specific. Over time the service portfolio will migrate from a purely conceptual exercise to one populated with living, breathing services. Creating a service portfolio plan is crucial to realizing key SOA benefits such as reuse, ease of development, and enhanced ROI. Please don't ignore it. Or, rather, don't ignore it for long.

Each of the three adoption approaches has its own pros and cons: the enterprise-driven (or domain-driven) approach requires buy-in and organizational alignment up front, but the services developed in this context will be reused without much effort and cost, ultimately leading to a reduced governance burden. The other approaches have less upfront impact but can impose a greater governance burden later on - a fact you have to live with.

Now Back to the Real World
A reality that all of us, however sold we are on SOA, have to live with is that most organizations today are taking the project-driven approach to SOA, typically addressing immediate integration or composite application requirements by using a service-oriented approach. How do you execute the project-driven approach to SOA correctly? Here's our checklist:

1. Decide what you need from SOA in the medium to long-term. No doubt you've heard the expression "think strategically, act tactically" applied to SOA. There are many benefits to using SOA tools at the project level (see Figure 5). Not everyone needs to be at Level 5 in the SOA maturity model straightaway, if at all. So assess which SOA benefits best fit your business, understand your constraints (funds, corporate culture) and build a plan that will enable you to deliver those benefits - perhaps even as part of existing projects. An SOA maturity model is helpful not only in pinpointing existing capabilities but also in identifying the end state and what needs to be put into place to get there. So think about what you need in terms of SOA benefits. Do you really need the benefits of the enterprise-driven approach? Are you, or rather, is the business willing to make the investment funds available to make it happen? Not everyone needs to win the Super Bowl and certainly not within 12 months. Be realistic and chart out your goals.

2. If you're taking the project-driven approach, partake in a few activities to get better results. Of course, the priority for any project is to solve the business problem at hand. If SOA helps deliver the project in a better way or results in a more maintainable and flexible system, that's great. But not all projects are suitable for SOA. For projects that are suitable, you can still get some of the benefits of enterprise SOA, such as interoperability, by adopting architectural principles - application reference architecture, canonical data models, agreement on standards (and versions of standards) that will be supported both in projects and across projects - at the project level.

Technology does matter, so select a standards-based, integrated, and flexible toolset that enables you to deliver on the promise of SOA and use those tools in the right way. For example, we have often seen developers get carried away and implement all forms of business logic in BPEL. Finally, avoid restrictive policies. Everyone says governance is vital to SOA, but you really don't need that much of it when you adopt the project-driven approach - we've often seen companies spend many cycles enacting restrictive policies that stunt their progress with SOA. Exert the minimum amount of control required.