The SOA Conundrum

As enterprises rush to assess how they can benefit from service-oriented architecture (SOA), many naturally but mistakenly focus on the technological aspects of the solution. As an architecture, it’s unfair to paint SOA as a panacea to independent software vendors’ (ISV) most daunting business problems.

In order to determine if SOA is right for your development organization, you must first clearly understand exactly what SOA is — and what it isn’t, how SOA impacts software development, and the importance of best practices and governance.

The Nuts and Bolts

Despite all the marketing hype and media attention given to SOA, at many initial consulting engagements there is still a significant amount of education that needs to happen, with questions such as: What exactly is SOA? How can it benefit our organization? How do we know if it’s right for us? Finally, where and how do we get started?

Simply put, SOA is just one of many development architectures, like object-oriented, resource-oriented or message-oriented. Considered the next natural evolution of these existing architectural paradigms, SOA is a way of looking at building enterprise systems based on services.

One of the key drivers for SOA adoption is companies’ desire to build more flexible and agile systems to support changing business dynamics caused by new customer demands and increased competition. More specifically, SOA is the link enabling changes to back-end systems while allowing front-end services to remain intact — and keeping technology out of the equation.

The first steps to benefiting from SOA come with the recognition of what results can be reasonably expected. Looking at SOA as an architectural approach to developing software, SOA can deliver more than just simple problem solving related to cost of development, quality and revenue. It can help organizations achieve new results derived from more agile applications that support new partnerships, drive new revenue streams and create freedom from closed, rigid applications.

Assessment Tools

Many organizations that think they will benefit from SOA often don’t — or can’t. While there are no hard and fast rules about what makes the perfect SOA deployment, there are some general guidelines for assessing SOA-ready environments:

• Clearly defined services: Companies must be able to chunk their operations into well defined services. If you can’t define your services, you don’t need SOA.
• Measuring time vs. business value: If the amount of work it takes to orchestrate and choreograph services is significantly more than its value, SOA isn’t for you. The value of services come not from the way they are built, but through the realization of business benefits that only comes through extended use.

Organizations will benefit from SOA assessment tools that are built to help identify key organizational and technological aspects essential to both mitigate risks and maximize opportunities; these assessments are used to identify potential areas of improvement and should be used in conjunction with a SOA Maturity Model to focus future efforts.

SOA readiness is determined by focusing on key areas such as SOA governance, software development life cycle and architecture. Combined with a business readiness assessment that includes business sponsorship, strategy and SOA awareness, companies are able to determine their level of SOA maturity.

Pushing Beyond Traditional Development Mindsets

SOA changes not only the way in which systems are developed, but who they are developed by. Unlike traditional architectures — where business processes and functionality are mostly implemented through developers — in the SOA world, new business activities or changes to existing practices can often be implemented directly from the modeling activities performed by business analysts.

Through business process choreography, new work flows can be made of out existing services captured as changes made to their business process execution language (BPEL). This is more of a configuration of process direction rather than customization of business code.

It’s also important to note that in addition to the changes to requirements analysis, design and testing, services need to be well defined, easily discoverable, well behaved and very reliable. However, with emphasis on building these reliable and dependable services comes distinct testing challenges.

In traditional software development, it’s easy to test code, but testing their interaction on a large scale can be a problem. As the number of services choreographed within a given environment increase, the number of potential interaction increases exponentially. These composite systems can grow to a point where an emergent behavior is much different than that expected from their composited services.

Today, SOA is moving into a second generation of sorts, powered by more dynamic environments supported by BPEL, which focuses on the functional aspects of business processes. Increasingly, the types of applications and systems clients are considering are more dynamic in nature, including those in heavily regulated, transaction-oriented environments, which are looking to address their structured computing environments with a more modern architecture.

SOA and BPEL can help inject work flow into a distributed service environment. As a result, there are increasingly interesting opportunities in highly work flow-oriented environments that have modular components that need to be orchestrated, while dealing with regulations and external governance challenges.

Best Practices Start With Governance

As addressed earlier, SOA is becoming more widely adopted largely in part to the business value it provides — agility and flexibility, in addition to classic time-to-market and lower cost benefits. For a true commercial grade instance of SOA, ISVs need governance — specific, consistent guidelines for defining, measuring and monitoring their work. Ultimately, these steps enable developers to analyze and take action on how those services are being delivered: Which work? Which don’t? Which ones need to be added? Which ones need to be removed?

We recognize that governance is challenging. It’s not tangible and it’s hard to measure. However, there are key questions every organization can ask itself: What is our SOA reference architecture? Where are our services, who owns them and how are they maintained? How are we managing rogue services — unknown services or services that are being used without someone’s knowledge?

SOA exposes operations to disruption through Web services and, therefore, establishing governance and ensuring compliance with business policy is extremely important. Organizations must determine what services are being consumed internally, exposed to insider threats, and exposed externally to malicious hackers.

Operationally, it must be clear how services are being used and whether or not they are being used in a way that is consistent with users’ roles and normal delivery models. In terms of “baking in” security and governance into the SOA development process, organizations must assess threat models, engineer for it, assess the skill sets of engineers and identify emergent behaviors.

In the end, SOA practitioners must focus not only on development, but also on developing strong governance practices that tie business value into the commercial delivery of services up the SOA maturity curve — from ad hoc and repeatable to managed and beyond. The goal is to reach the optimization level where you are changing the way your business is developing services as a function of the value business partners are paying for.

Above all, it is essential to keep governance simple. Don’t go overboard or make it too complicated, otherwise it becomes a burden, not an asset to the development team.