In-Depth

SOA Development: The New Wild West

SOA may be a new technology, but it requires all the rigor of past development projects.

The technical community has been abuzz about SOA for a while, but this past year we have been especially vocal. A casual glance through prominent vendors’ Web sites shows they have been flooding the media with SOA propaganda. Their message is clear: SOA Now! Don’t get left behind! And, by the way, buy tools, tools, tools from us, us, us!

Organizations have been inundated with articles, alerts, and Webinars this past year, and it wouldn’t be surprising to learn that some have jumped into SOA the same way some tried to cash in on the dot-com frenzy without first understanding the why and how behind the technology.

Why SOA?

There are excellent reasons for organizations to adopt SOA. It can promote and facilitate agility for businesses operating on faster and faster time-scales and can also help reduce development costs through service reuse. When implemented well, SOA can dramatically boost the productivity of development organizations.

Not all SOA initiatives are implemented well, however. Projects fail when IT organizations focus on technical rather than business reasons for moving to SOA. Furthermore, SOA can be expensive to implement, and without sound business reasons, the promised ROI never materializes. This often happens because IT organizations, eager to adopt new and sexy technology, overstate the benefits of changing architectures.

What separates organizations with successful SOA initiatives from those whose SOA implementations did not meet business objectives? I’d like to turn that question around. Why should the disciplines necessary for successful development projects be any different for SOA?

They aren’t different. Organizations with a history of successful software development initiatives should have successful SOA initiatives. Shouldn’t we expect organizations to carry forward and adapt their successful development processes?

Hardly. From my own experience as a developer moving to object-oriented development, Web-based applications, and now SOA, excitement seems to override good sense. We always think we needn’t carry forward the processes that worked for us before. New technologies give IT a severe case of corporate amnesia (or perhaps corporate euphoria).

More Guns … or a Sherriff?

We technical advocates jump into the new technology and start to implement, promising rich rewards. When the ROIs do not materialize, we look to vendors—tool vendors mostly—to help us get our failing initiatives under control. The vendors, eager to capitalize on the buzz, have many tools to sell us. Unfortunately, tools are not the answer. As a colleague of mine likes to say, “Buying tools to solve policy and process problems is like a town full of people in the old Wild West buying guns when what they really need is a sheriff.”

While some tools are necessary for effective SOA-based development initiatives, the secret to success is not to buy more and more tools. Nor is the secret to throw more and more money at the problem. The secret is to implement policies, procedures, and processes around technology changes that enforce professional rigor without strangling business agility. The secret is change governance.

Change governance stipulates that all change-related activities—planning, developing, implementing, monitoring, and enforcing—are integrated across the enterprise to bridge silos of change and create a common frame of reference for business and IT. This approach enables companies to understand the interdependencies and impact of a change before it happens, translate that understanding into effective policies and processes, and ensure consistent adoption of policies and processes across the enterprise—regardless of who originates the change, where the change will be implemented, or what tools and technologies are involved.

Change Governance and SOA

Change governance is especially vital for applications built using SOA. These applications are inherently more complex and have more moving parts than their more traditionally architected counterparts. They may also make use of services delivered from anywhere in the world by third-party vendors not directly under the control of IT. This can wreak havoc within IT development organizations if (or perhaps when) services are updated, replaced, or removed without rigorous controls.

The promise of agility and the cost savings from reuse will come to nothing without strong governance policies and procedures in place. Industry analysts have all recently published research telling organizations to slow down, consider business objectives, and put governance in place before jumping into potentially expensive and disruptive SOA initiatives.

Governance, as defined by the registry and infrastructure vendors, is concerned with runtime performance and integrity of Web services. However, change governance at runtime is not enough. Change governance must reach all the way back to initiative inception and reach all the way forward to the maintenance cycle where services and infrastructure are evaluated, updated, re-factored, and perhaps retired. Most of the steps necessary for successful SOA initiatives are familiar to us: Understand the business need, validate your assumptions and conclusions with the business owners, avoid scope creep, and so on. There are a few places where SOA initiatives may require your methodologies to be adapted, however.

Steps to SOA Success

First, start by defining your application rather than your services. Unless you are going to sell services commercially, starting with production will just lead you down the path of A Bunch of Services (ABOS) rather than a set of reusable services that meet business needs. In the end, it isn’t the services that will provide value to your organization, it is the applications that consume the services. If you are using agile methods and can’t afford a top-down approach, be certain not to skip over the re-factoring step or you will end up with project-specific services that aren’t going to be reusable across projects.

Second, ask your business analysts to express application requirements using visual tools. It is much easier to identify the services that can be reused, must be built, or need re-factoring when the application interactions are in a visual model rather than buried in a word processing document or spreadsheet.

Third, make sure your developers and application designers have access to existing services, understand where they are, what they do, and how they work. Developers won’t use a service if they don’t know it exists. If you plan to use a design-time service metadata repository, make sure it integrates with your IDE.

Finally, you must manage and control your service-deployment process. If you have done your job right and you’ve created services that are highly reusable, the impact of putting a bad service into production is much more severe than a single application going down. Put strong and enforceable policies and processes in place to govern service-deployment activities.

Don’t let the lure of new and exciting technology lull you into thinking that you need not continue to apply the lessons of the past to new development. SOA isn’t magic. It requires discipline and rigor, just like any other successful development effort.

Must Read Articles