BEA founder and CEO Alfred Chuang was in New York recently when news came through that JP Morgan was selling its BrownCo business to eTRADE for $1.6bn.

	express delivery
	• print  • comment
	SOA can only deliver business agility if it's built to adapt to changing demands throughout the lifetime of the architecture: Service-oriented architecture must be designed for change Architects must work as part of a strategic team Policy configuration and composite assembly enables more flexibility Building and managing for change requires skill and ingenuity IT must reorganize to get closer to business
	Glossary terms: SOA, governance, business process, development, orchestration, lookup tool Sponsored links: your text link here

The event, he says, is typical of a growing trend in the financial services sector, where the big firms are re-evaluating their portfolios and, where appropriate, re-consolidating and de-merging non-strategic businesses. Such moves highlight a crucial dilemma for IT departments as they set about building the next generation of application infrastructures.

"That [disposal] would not have been possible if JP Morgan had rigidly integrated its businesses," says Chuang. The story illustrates that, while sharing services and IT resources is the baseline objective of SOA, the ultimate aim is achieving the flexibility to connect — and disconnect — disparate functions to meet changing business needs.

"Will companies go from one big package [application] to another?" asks Chuang. "It's very unlikely; [for a start] they cannot afford to implement a big new system. They will instead go with composite applications, plugging them in and building on what they've already got."

CIOs are thus coming to realize that moving to SOA is more than a one-time project to design a set of services that can be orchestrated together to support business processes. They need to have systems in place to ensure governance, not only of the initial design-and-build phase but then throughout the continuing lifecycle of the system.

The core challenge is nothing particularly new — IT departments have been trying to rein in wayward developers for some years now — but the scale and scope of the challenge in an SOA is such that it requires a different approach.

Instead of viewing IT development and maintenance as a series of discrete projects, new expectations of business agility — and indeed IT agility — have turned development and maintenance into an ongoing, continuous change management process. The architecture itself needs to be designed and engineered to sustain change, a requirement that has moved the role of the architect to centre stage, with major repercussions for those organizations that have already embarked on this path.

To navigate this uncharted territory, IT must form leadership teams, says Chuang, comprising executives, architects, developers and IT managers: "They succeed or fail as a team." He believes architects now have the power perhaps for the first time to impact both vision and strategy. "We're moving from a world of code to a world that is policy driven. And now we have policy architects."

New-found flexibility

Moving to a policy-driven architecture brings more flexibility because many of the decisions about how processes operate become configuration choices, stored in an XML file, rather than being permanently written into the underlying software program. That means that decisions about a range of matters — such as security levels, performance standards, prioritization of certain services or users, notification thresholds and exception handling — can all be implemented directly by business users rather than having to wait for developers to make changes to the software code. "You can have a change-time layer that can be done much more declaratively," explains Miko Matsumura, VP product marketing for SOA governance vendor Infravio.

A second layer of flexibility comes from taking a composite approach to application assembly and process automation, which reuses existing functionality to meet new requirements rather than building new software from scratch. Although this takes more sophisticated skills than simpler policy configuration changes, it can often be carried out by business analysts and developers without having to tamper with the core application software code.

All this new-found flexibility comes at a substantial cost, of course. Building a system to fulfil a pre-defined requirement — the way IT has always approached new implementations in the past — is much easier to plan than creating and managing an architecture that allows for a range of permutations, some of which are barely imaginable at design time. Add in the need to establish governance that remains effective throughout a lifetime of successive configuration and composition changes, and the enormity of the undertaking becomes evident.

Sheer inspiration

With little to no best practice examples to fall back on for guidance, the SOA architect often has to rely on sheer inspiration and brute determination to make progress. Preconceptions that an architect's working life comprises "clean sheets of paper, well drawn-up plans and ribbon cutting at the end of successful projects" don't apply, says Jim Crookes, director of platform design and build at British Telecom. The reality is somewhat different, with architects struggling to make headway in the face of a host of practical obstacles to their vision.

As much as any approach to designing software, SOA also means changing organizational design to accommodate much closer liaison between IT and the business. "Any transformation that confines itself to the IT space will fail. If SOA wants to get out of the sandpit of web services demos, then it mustn't start with software," says Crookes.

This is an abridged extract from a four-page feature article published in the October 2005 Loosely Coupled monthly digest. To read more about how early adopters of SOA are architecting for change, download your copy today.

More on this topic