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?

Beyond IT flexibility, agility is also determined by how quickly and cost-effectively new changes and requirements are handled without sacrificing quality. Moving from creating thousands of lines of code - the traditional approach - to more of an assembly model can dramatically reduce the overall time and cost required for delivering new applications. In a service-oriented approach, this typically means reusing services from a well-defined service portfolio, orchestrating them, using the right set of tools to provide the required business functionality, and capturing business policies using a business rules engine (see our previous article "Building Flexible Business Processes Using BPEL and Rules").

Looking at Figure 3, you can see the SOA enablers (purple) and tasks, activities, and technologies (pink) needed to deliver agility for SOA projects. Aspects such as canonical data models and service portfolios are often missing from integration projects - limiting business agility.

The more SOA enablers and supporting tasks, activities, and technologies are in place, the more closely you'll realize your higher-level IT and business objectives. Many organizations use this benefits map to plan their SOA journeys and ensure that both business and IT are on the same page about what investments will actually deliver

It's not enough to decide on SOA - you also need to know why you're following this path - hence the need to be really certain of why you are doing SOA. One large inter-governmental organization we spoke to recently said that the key SOA benefit it was looking for was easier information exchange enabled through interoperable systems. From its perspective, the key SOA benefit it wanted was interoperability - and it was single-mindedly focused on that.

Clearly, the more SOA benefits you want to attain in a given time frame, the more investment, from a financial and organizational perspective, is required. Of course, everyone wants agility, but what's required in the short term?

What Approach Are You Going to Take to SOA?
Once you've decided on what SOA will mean to your organization, you should put together a SOA strategy and supporting roadmap for delivering on these SOA objectives.

Based on our experience with numerous customers that have undertaken SOA initiatives, we have identified three distinct SOA strategies:

  1. A project-driven approach in which SOA considerations are confined to the context of an individual project.
  2. An infrastructure-driven approach in which the focus is on building out the utility/foundation services and an SOA platform that is reused across projects.
  3. An enterprise-driven approach in which there's a wider view to leverage SOA for business responsiveness that typically involves building a portfolio of reusable services.

The three approaches are depicted in Figure 4. The project-driven approach can deliver successful SOA projects you can incrementally build on as long as the right level of buy-in and appropriate governance and portfolio planning are included; don't be fooled into thinking that anything other than an enterprise-driven approach is inadequate. An example of this is a Fortune 500 company that undertook a $250,000 pilot project and used it to learn valuable lessons that helped it in subsequent enterprise-driven SOA initiatives.

Let's look at each of these approaches in greater detail.

Enterprise-Driven Approach
Organizations engaged in the enterprise-driven approach typically have an active enterprise architecture group defining architectural standards, an SOA center of excellence for disseminating best practices, buy-in and involvement from businesspeople in the SOA initiatives, a managed portfolio of services, and governance focused on delivering business results through enterprise architecture and SOA as a discipline within EA.

Enterprise-driven SOA, or rather the capabilities it epitomizes, are a necessity for projects that involve process automation and span application silos and lines of business or that are aimed at consolidating applications across various departments. The enterprise-driven approach requires significant upfront investment to establish the required SOA framework. Because this outlay can engender a major ROI justification challenge, few companies are engaged in it.

What is a distinction between enterprise-driven and enterprise wide approaches? In the enterprise-driven approach, many of the planning and architectural aspects normally associated with enterprise wide SOA - such as canonical data models, architectural standards, blueprints, a service funding model, service portfolio planning, and service and process owners - are restricted to a domain in the enterprise. The enterprise is segmented into non-overlapping domains, each of which establishes its own boundary. A domain typically crosses multiple application silos and provides a significant and meaningful context in which services can be independently standardized and governed, architectural standards are defined and enforced, a service portfolio can be planned and built, and there is consensus (within the domain).

The key to taking the enterprise-driven approach is to adjust the scope of the domain so that it's manageable and doable. The domain may end up being a department, or multiple departments, but the key consideration is that it's feasible and you can pull it off. For more on the domain inventory pattern, click here

An enterprise-driven approach provides the most benefits because it's enterprise (or rather domain)-focused. This broad focus means that the initiative will be complemented by both planning and actual implementation work to ensure that services are created within an enterprise service portfolio plan. A service portfolio is defined as a collection of related services that are independently standardized and governed. Services in this context are treated as an enterprise resource, whereas units of business logic have typically been designed to be used in the application silos in which they were implemented. Creating a comprehensive service portfolio that includes business services - encompassing entity services, such as a customer service, with associated create, read, update, and delete (CRUD) operations, and task services, such as credit eligibility - and utility services will go a long way toward enhancing the ease and speed of new application development. Application development efforts can be substantially reduced because development activities in an enterprise-driven SOA organization would involve assembling services to provide business functions, rather than writing large amounts of new code.

Unfortunately, enterprise-driven SOA can fail if the organization is not aligned with the SOA initiative. For example, an organizational culture that doesn't encourage sharing can severely inhibit the expected SOA benefits. A comprehensive governance framework that addresses technology, project execution, data, architecture, operations, finance, portfolios, and people and skills is a vital foundation for the overall SOA success.

When we talk to customers, we typically refer to the enterprise-driven approach as requiring capabilities at Level 3 of the Oracle Level 5 SOA Maturity Model. For those of you who are interested in knowing the kind of capabilities required for adopting an enterprise-driven approach, you may want to refer the SOA Maturity Model found at Cheat Sheet. Suffice it to say that a lot of stars need to align to execute the enterprise-driven model successfully. To increase the chances of success with the enterprise-driven approach, cast the domain net wide enough to cross application silos but narrow enough to provide a meaningful context.

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 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.