The four pillars of service-oriented development

Guest Commentary
The four pillars of service-oriented development
by Jason Bloomberg, Senior Analyst, ZapThink, LLC

As companies move to adopt service-oriented architecture (SOA), their application development process will change. In fact, SOA promises to transform the basic definitions of "application" and "development" themselves as a result of SOA's promise to shift the responsibility of application development into the hands of the business user. It's crucial, therefore, for developers, business users of information technology (IT), and the consultants that serve them to understand the changing nature of applications and the process for creating and managing them in the context of SOA.

The SOA context mandates a form of application generally known as a composite application. Composite applications consist of services orchestrated or otherwise combined into service-oriented (SO) processes, which are in turn exposed as services. The development of such applications therefore involves configuring such processes. As explained in an earlier ZapFlash, most composite application developers are business users who work with tools that enable the configuration of metadata, thus enabling them to create and manage business logic declaratively rather than programmatically above the services layer of abstraction that SOA provides. Such users may have many different titles, but for the purpose of this ZapFlash, we will refer to them as business analysts.

While moving all business logic to the composite application level is a noble goal to be sure, there's no question that a large portion of the business logic in today's organizations will remain locked away in existing business applications. It's important to keep in mind, therefore, that in the SOA context, there are two basically different kinds of applications: composite applications that business analysts create and manage declaratively, and the "legacy" business applications that will continue to exist below the Services layer of abstraction.

SO architects, however, must have the big picture of the SOA implementation that crosses the services layer of abstraction. They must create and manage an SOA metamodel that includes models of the business requirements, services, and the underlying implementation. At the crux of this metamodel is the service model, which abstractly represents the Service contract metadata that forms the services layer of abstraction.

One of the challenges of SO development is in following an approach that maintains the business agility benefit, which, after all, is one of the main value propositions of SOA. The secret to building for agility is to assume that business requirements are always in a state of change. So, rather than building applications that address a specific, static set of requirements, a composite application has the "meta-requirement" of a responding flexibly to changes in the business environment. The traditional gather requirements-design-build-test-deploy waterfall methodology for software development fails to address this meta-requirement of agility. SO development, therefore, requires a different approach that depends on the Service model to represent the business requirements to IT, as well as to represent IT capabilities to the business.

As a result, SO development follows one of three basic scenarios. In the first scenario shown in the figure below, business analysts work with business users to understand and gather current business requirements. These analysts then work with composite application tools to declaratively configure services and processes to meet those requirements. In this scenario the available Services are sufficient to meet the needs of the business; the development process is purely declarative. The analysts work in an iterative fashion with the end-users, adjusting the processes as needed to fine-tune their functionality. In this scenario, business analysts work to satisfy specific business requirements, without the need to involve IT. They are thus able to respond quickly to changing business requirements on an ongoing basis.

However, what happens if the line of business requires functionality that current services are unable to provide? In this second scenario as shown in the figure below, business analysts find that the existing services in production are insufficient to meet the needs of the current set of business requirements. As a result, they describe the newly required functionality by creating or modifying service contract metadata as described in the service model. Basically, they provide instructions to the programming staff by establishing requirements within service contracts.

The component developers then code to the contract by developing services that meet contract requirements, without having to know the specific usage scenarios for those services beyond the information contained in the contract. service contract metadata therefore form the requirements artifacts necessary to create or modify existing components in order to expose service interfaces that satisfy those contracts. At that point, the business analysts can incorporate the required working services into their processes.

The third scenario only involves component development, as shown in the figure below. In this scenario, there is some technical or infrastructural reason for changing the programming of a service without changing that service's contract, a process known as refactoring. For example, refactoring might be called for if the IT staff determines that they must make changes to satisfy non-functional requirements for levels of service, say to maintain the scalability or fault tolerance of the underlying components. Another example would be when IT decides to replace a legacy application or other part of the existing infrastructure. Refactoring may also take place to streamline components by removing redundant parts of the code. The critical point to this third scenario is that the business users are none the wiser about any changes, since the contracts remain the same, and ideally, IT addresses any potential performance issues before they affect the business.

Pillar #1: Iterative development -- we're representing each sphere of development with a pair of arrows to indicate the fundamentally iterative nature of SO development. Business analysts must work iteratively with business users, both to satisfy the original requirements as well as to maintain agility as those requirements change. Likewise, component developers must continually iterate their code to satisfy ongoing changes to the service contracts.

Pillar #2: User involvement -- unlike the waterfall model, where users specify requirements at the beginning of a project only, business users continually drive SO development. The meta-requirement is for a system that responds well to change, and as a result, the "requirements definition phase" of any SO project is actually a set of ongoing activities.

Pillar #3: Contract-first development -- Business analysts work with users to distill requirements into contracts that then act as the marching orders for component developers. Such metadata both represents the requirements as well as the test plans that analysts can execute to guarantee that services meet their requirements. In other words, contract-first development is an example of test-first development, and both approaches are examples of metadata-driven application development.

Pillar #4: Refactoring -- The services layer of abstraction affords IT the luxury of a curtain that hides the inner workings of the technology from the business. Rather than an excuse to maintain a poor infrastructure, this abstraction layer actually gives IT more leeway to make continual improvements to the technology. Refactoring is thus the underpinning of reuse, as IT may now work to streamline technology across platforms to meet the needs of the business.

Broadly speaking, agile methodologies follow the Agile Manifesto for software, which values individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. ZapThink believes that to be successful, SO development must follow these principles. SO development, however, is not the same as Extreme Programming or any of the other agile approaches. Instead, the Service model and the associated Service metadata enable a different approach to development that can enable companies to take advantage of the promise of SOA. To build agile SOA, though, companies must follow the four pillars of SO development and the principles in the Agile Manifesto.