From the Desk of Mohamad Afshar, PhD

Mohamad Afshar

Subscribe to Mohamad Afshar: eMailAlertsEmail Alerts
Get Mohamad Afshar: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Oracle Journal, SOA Best Practices Digest, Sustainable Investment, SOA & WOA Magazine, ERP Journal on Ulitzer, VITO Report

SOA Best Practices: Article

Going Beyond Project-Driven SOA

Why are you doing SOA? And how are you going to do it?

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.

More Stories By Mohamad Afshar

Mohamad Afshar, PhD, is VP of Product Management at Oracle. He has product management responsibilities for Oracle's middleware portfolio and is part of the team driving Oracle's investments in SOA on Application Grid - which brings together SOA and data grid technologies to ensure predictable low latency for SOA applications. Prior to joining Oracle, he founded Apama, a complex event processing vendor acquired by Progress Software. He has a PhD in Parallel Systems from Cambridge University, where he built a system for processing massive data sets using a MapReduce framework.

More Stories By Prasen Palvankar

Prasen Palvankar is a director, SOA Strategic Engagements, in Oracle Fusion Middleware development and is primarily responsible for helping Oracle?s strategic customers with SOA adoption. He has more than 25 years of experience in the field of software development.

More Stories By Robert Schneider

Robert D. Schneider is a senior SOA consultant, a certified SOASchool.com instructor, and a published IT author with more than 15 years of experience. He is also an experienced speaker who has led many technical sessions and workshops at various events. He has written four books and numerous articles on SOA and high-performance database applications and implementations. He is currently working on a new book on SOA governance as part of the ?Prentice Hall Service-Oriented Computing Series from Thomas Erl,? and he is a regular contributor to The Big SOA Grid, a Web site providing current data relating to WS-* specifications.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.