Manage Learn to apply best practices and optimize your operations.

The SOA pilot pitfall

A good SOA pilot is necessary for successful SOA implementation. This article discusses critical pilot elements and what mistakes can lead to a pilot pitfall.

All new technology projects have to start somewhere, and pilot projects are a great way to try out new approaches as challenging and complex as service-oriented architecture (SOA). Over the course of the past five years, ZapThink has interacted with countless companies who are planning or executing SOA pilots, many of which are well-conceived, competently executed and reasonably successful. However, we have also seen a foreboding pattern of ill-conceived SOA pilots forming in information technology (IT) shops throughout the world, and these problem pilots all seem to succumb to the same pitfall. It is time, therefore, to take a closer look at what makes for a good SOA pilot, and how to learn from the mistakes of others and avoid the SOA pitfall.

Defining the SOA Pilot
A pilot project is a trial project that seeks to evaluate some new technology or approach and determine whether a company should invest further to expand the project to meet critical business needs. A pilot project should also yield a working result that, while limited in scope, should address a real business problem. Pilots often yield limited results, but those results should actually provide a real return on investment to the business.

There are many reasons why a company would want to undertake an SOA pilot project. Among these reasons are the following:

  • To build acceptance for SOA within the organization
  • As a means to work through some of the harder aspects of architecture and service modeling
  • To bring the technical team up to speed on the intricacies of SOA
  • To develop and fine-tune methodologies and approaches for implementing SOA
  • To evaluate various commercial products that purport to help with SOA rollouts

Pilot projects are a great way to reduce the risks involved in moving to a new architecture. However, today's perennially constrained IT budgets don't allow for high-risk projects, so it's vitally important to build acceptance for SOA with the powers-that-be, particularly because architectures don't have features -- only implementations do. As a result, the best SOA projects solve some real business problem, and do so cost-effectively. After all, the best way to build acceptance for your new approach is to solve a problem on a shoestring budget. Furthermore, since implementing SOA in an iterative fashion is actually a best practice, the SOA pilot serves as a low-risk first step in the ongoing, iterative process of implementing SOA.

This desire to build new functionality that solves a particular business problem, however, can lead to trouble, if you focus too much on the new functionality, and not enough on the architecture. Remember, the whole point of the SOA pilot is to pilot SOA, which means architecture, not simply new software! And that's the SOA pilot pitfall -- putting together a project that purports to be an SOA pilot, but in reality doesn't adequately pilot the architecture. Or even worse, is simply the old architecture warmed over with new, standard-based interfaces.

The SOA Pilot Pitfall
It constantly amazes us at ZapThink that even after belaboring the point for five years now, people still confuse SOA with Web services. SOA, after all, is software architecture -- a set of best practices to follow, or a discipline, if you will. Web services are little more than standards-based software interfaces, so piloting SOA is very different than piloting Web services. Implementing a Web services pilot is a near-trivial exercise in exposing standards-based interfaces with little need for a consideration of architecture. SOA pilots, however, are mostly exercises in architectural planning, modeling and organization.

It's possible to implement SOA without Web services, and it's also quite straightforward to build Web services without SOA. Just about any SOA project today, however, will include Web services, since Web services can simplify loose coupling dramatically, but building Web services is by no means sufficient to guarantee that you're doing SOA. As a result, companies that fall into the SOA pilot pitfall have pilot projects that are ostensibly SOA pilots, but in reality they're only piloting Web services.

It's quite possible to fall into this pitfall even if you have a crystal clear understanding of the distinction between Web services and SOA. Such pilot projects often begin with the best intentions of truly piloting the architecture, but the pilot team ends up focusing on building the services, and they neglect the architectural work necessary to run the new architectural approach through its paces. After all, developing architectural best practices is hard! Figuring out how to build the right services at the right level of granularity, all the while assuring loose coupling through contracted interfaces and policies, is not for the faint of heart.

Sometimes an enterprise's neglect of architecture results from a constrained budget, micromanaging executives or a technical team that lacks an adequately skilled and experienced architect. It's important, therefore, for your SOA pilot to have adequate funding, as well as architectural leadership both skilled enough to put together the architecture pilot and experienced enough to manage the team and play interference with senior management.

Critical Elements of an SOA Pilot
To further clarify the difference between an SOA pilot and a Web services pilot, let's take a look at what your SOA pilot should have:

  • An architectural plan -- Enterprise SOA is enterprise architecture that provides a comprehensive, high-level plan for how the business interacts with IT. Specifically, an SOA should help a company build IT that can respond to unpredictable change. An SOA pilot, therefore, must take some subset of this enterprisewide plan and put it through its paces.
  • Process scope -- Implementing SOA includes identifying the right services to build. The best way to accomplish that identification is to start with existing or desired business processes and decompose them in order to identify areas of redundancy that might lend themselves to reusable services. For your pilot, you must decide which business processes are within the scope of the project. Too few and you won't have much of an SOA exercise, too many and the value of the pilot decreases. Also, it's imperative that companies don't try to tackle too big of a business process at once. It's best to start with a simple, yet important business process that can enable your SOA pilot to show a rapid, verifiable return.
  • Resource scope -- Your approach to SOA should be both top-down (through process decomposition) as well as bottom-up (exposing existing functionality as fine-grained services and composing them into coarse-grained business services). For your pilot, it's important to identify those resources you wish to include in your wrapping-and-composing activities. However, don't simply build services based on the systems you already have -- think about the services you need in order to make your pilot a success.
  • An iterative methodology -- It might seem like we've worked our way into a Catch-22: How do you know which resources are in scope until you decompose your processes? How can you be sure a process is in scope until you identify the appropriate resources? The answer is that you simply need to dive into the project and get the lay of the land. You should start with a broad architectural plan and then follow a methodology that enables you to dive into the process decomposition and service definition activities, only to circle back, improve the plan and revisit the processes and services. Having such an iterative, agile methodology for the SOA project, therefore, is critical: without it, you'll either build the wrong services, fail to stay within the scope of the project or create enormous rework for your team as they try to fix their mistakes. So, start small, but iterate quickly towards services that show a real business return.
  • Clear acceptance criteria -- Every pilot must be able to answer the following questions: How will you know when your pilot is complete and how do you determine whether it was successful or not? More broadly, how can you best leverage the SOA pilot to teach you the lessons you set out to learn? You should have an explicit finish line for your project with specific acceptance criteria that enable you to score your results. Finished doesn't mean done -- it just means that the pilot has met its goal. In all likelihood, the pilot is just the starting point for all future SOA endeavors in the enterprise.

Understanding which acceptance criteria you should have is especially important for avoiding the SOA pilot pitfall, because they act as specific goals your team can focus on as they plan and execute the pilot. Acceptance criteria will vary from company to company and project to project, because there are so many different reasons for companies to undertake SOA projects. Here are three common acceptance criteria that may make sense for your SOA pilot:

  • A complete architectural design -- By complete, we mean within the scope of the pilot project. Such a design should not only include the broad plan you started with, but details about service contracts, invocation styles and other elements of a working SOA implementation. You may even have the requirement that this design should be adequate as a starting point for a follow-on SOA project.
  • Reusable business services -- Services are necessary but not sufficient for SOA. Your acceptance criteria might contain a target level of reusability for the services you build, including the number of services and the number of consumers per service.
  • Governance criteria -- You want an SOA pilot that you can continue to iterate, not an ad hoc SOA project with no future. A full-blown SOA project should include a governance infrastructure that handles identities, policies and rules for the ongoing management and evolution of the SOA implementation. Your pilot may lay out a framework for this governance infrastructure, and if it does you should have acceptance criteria that define success for such a framework. This governance framework will then help you leverage your SOA pilot as you build out your SOA implementation.

The ZapThink Take
If you're an IT manager, the best thing you can do to avoid the SOA pilot pitfall is to put a seasoned architect in charge of the pilot project. Never forget that SOA is architecture -- you can't buy it from a vendor, and you can't build it with programming code. Architecture is a set of best practices that guide your implementations, regardless of the technologies you choose to implement them. No one but an architect will have the expertise to drive the architectural parts of the SOA pilot.

In practice, however, SOA pilots rarely if ever consist entirely of architecture. To achieve the goals of the pilot, you must put SOA into practice with a working implementation. Never mistake the implementation, however, for the architecture. If you do, you'll be joining all the other failures in the SOA pilot pitfall.


Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchSoftwareQuality

SearchAWS

SearchCloudComputing

TheServerSide.com

Close