Feature

posted 26 Apr 2007 in Volume 10 Issue 7

Splitting headache

When service-oriented architectures are the norm, new and more sophisticated applications will be possible. But to succeed, it will need to be tackled in tandem with business process management. That is easier said than done.

By Jessica Twentyman

The concept of the service-oriented architecture (SOA) is causing Peter Birley, chief information officer at law firm Browne Jacobson, considerable consternation. In March 2007, he issued a heartfelt complaint via his blog: “My head hurts with SOA.”

“I have done a little bit of research and I don’t think I am the only one [who’s] confused,” he continued. “If I ask a vendor, ‘Are you SOA-compliant?’,

he will probably say yes, because he has XML or APIs [application programming interfaces] or web services or whatever else he can use to back up his statement.

But I’m a practical guy working at the coalface, so I need a practical explanation that I can relate to the real world – and not some ‘consultancy-speak’.”

Birley is not alone in his confusion. The SOA may be the ‘subject de jour’ with IT vendors, who pepper their sales spiel and marketing documents with the term, but their prospective customers are far from confident about the appeal and potential benefits of the technology, or what it might entail for their organisation.

A 2006 survey conducted by analyst group Quocirca bears witness to that general sense of bewilderment. It polled a sample of 1,500 respondents, representing a mixture of business and technical people, about their understanding of, and attitude towards, the SOA concept.

The results were revealing: More than 30 per cent said that they have absolutely no knowledge what SOA means. More than 25 per cent said they have only “minimal” knowledge, and just 20 per cent stated they have a fair understanding or a good working knowledge of what SOA is all about.

That split was even more pronounced when Quocirca questioned only the business respondents – more than half (55 per cent) said they have absolutely no idea what SOA is about and only ten per cent said they have sufficient knowledge to understand what impact, positive or negative, SOA could have on their business.

“This presents a problem,” says Clive Longbottom, principal analyst at Quocirca. “SOA is an evolutionary approach that does not require a rip-and-replace of infrastructure and applications, but does generally require buy-in from the business to gain the major benefits it promises,” he says.

In other words, SOA is a valid concept that can deliver real benefits, but only if it is well-understood and well-implemented. “As more [companies] go down the SOA route, the question has to be: can you afford not to? At worst, you need to understand what SOA is – and what the real arguments for and against it are,” says Longbottom.

A good place to start

There is some good news, however. Most organisations now have a relatively good understanding of business process management (BPM) and, according to most analysts, SOA and BPM are complementary – and indeed converging – technologies.

In essence, BPM aggregates business tasks to create end-to-end services, such as order-to-cash, for example. It is the next stage on, technology-wise, from workflow, which was widely deployed in the 1980s and 1990s to coordinate tasks within single IT systems, such as SAP enterprise-resource planning (ERP) deployments. BPM, by contrast, orchestrates tasks that run across several different systems.

Take, for example, the case of a components manufacturer that receives a large order for windscreen wipers from an automotive company. Sales executives at the company may need to query an SAP inventory management system in order to see if they have sufficient quantities of the product in stock, enter the customer’s order into a customer relationship management package from Siebel and check the customer’s credit status in an Oracle accounting system.

Using BPM, those sales executives can work at an abstracted layer, performing all three tasks via a single interface. They do not need to key the data into each of the disparate business systems, because all three are integrated via the BPM layer. Indeed, in most cases it can be done automatically without the user even being aware that the process he or she is doing is touching so many different systems.

While BPM aggregates business tasks, SOA is complementary in that it aggregates technical assets to support cross-platform business processes. In effect, SOA is an architectural approach that treats software assets not as a limited number of large, monolithic applications from individual vendors, but as a vast pool of numerous functional components that can be linked together to create entirely new, cross-package applications. When business processes change, functional components can rapidly and flexibly be rearranged accordingly. And the same functional component may be re-used in a number of different business processes.

“Quocirca’s view is that BPM and SOA are intrinsically linked,” says Longbottom. “Through the use of SOA, processes can be built rapidly and can then be used as necessary – and then disposed of. This approach creates a far more flexible environment that is far more supportive of the organisation’s aims in the marketplace,” he says.

So that’s the proposition: By mapping the needs of business processes on to the capabilities of the technical architecture, organisations can create a platform that is supportive of the business, is capable of responding rapidly to changes in the market and can be managed at the infrastructural level “across applications, departments and members of the overall value chain”.

Tackled in tandem

For these reasons, it makes good sense to tackle BPM and SOA initiatives in tandem, says Gartner Group analyst Janelle Hill.

But to date, she adds, that hasn’t often happened. “Many organisations have BPM and SOA initiatives under way. However, the majority of these efforts are independently initiated and have been largely disconnected. BPM initiatives typically start in business areas and are often led by functional leaders; SOA has been more of an IT-based grassroots effort, driven by developer interest in newer technologies and easier application integration.” However, she adds, there is increasing recognition that “BPM puts a business face on SOA as a key enabler of process flexibility for automated tasks, and SOA can easily ride in the wake of the strong tangible benefits of BPM”.

That’s certainly the message from a host of suppliers that now market BPM and SOA products. In general, these companies tend to come from the world of enterprise application integration and include Tibco, BEA Systems, IBM, WebMethods and Software AG.

Such companies originally provided tools for messaging, connectivity, transformation, and routing that were proprietary in nature, but have subsequently adopted open standards and added BPM features such as process modeling, process orchestration and business activity modeling.

And over the past two years, they have also added many features specifically designed to facilitate SOA, including support for both core and extended web services and registry/repository features that improve the management and governance of web services.

“Clients typically think of BPM software solely as products that support process improvement efforts,” says Ken Vollmer, an analyst with Forrester Research. “While this is certainly their main role, integration-centric BPM products offer other key value propositions, as well. One of the most important of these is their ability to provide tools that not only support SOA, but also provide a fully capable SOA platform.”

That’s certainly been the case at The Carphone Warehouse, the UK-based retailer of mobile phones and related services, which has deployed SOA and BPM products from Tibco in order to support its order management and fulfillment functions. According to David Byrne, The Carphone Warehouse’s architecture director for group information systems, his team is able to deliver the underlying IT services to support new business processes between 30 per cent to 50 per cent faster than previously.

The project was driven by both IT and business needs, says Byrne.

“In IT we wanted to get closer to the business and be involved in the same problem solving, so we could understand what the strategy is and build out a solution, rather than being the recipient of a set of requirements from them and then figuring out how to meet them. To do this, business process was key – we had to understand how different functions of the business worked at a more detailed level,” he explains.

“On the technology side, we wanted to build an architecture that was flexible enough to be recombined and reused, so we selected an SOA approach because it was flexible and adaptable. We are architecting our solutions for change and scalability, using our legacy, but adding package-based development,” he says.

The software will support new products as well as improve delivery times of existing services and Tibco middleware has already replaced homegrown, hand-written system-to-system links that were built to cope with the strain of the company’s fast expansion in the 1990s, says Byrne. “It has made quite a difference,” he adds. “There is an immense amount of functionality being delivered and we can find and fix problems much more quickly.”

On top of that, using an SOA approach, says Byrne, means that typically, changes in business requirements have “lower, more localised” impact on the design and development of IT systems. “This increases our ability as an IT function to provide high quality solutions faster, enabling our business to bring new offerings to market earlier,” he explains.

He readily admits that he understands the levels of confusion when it comes to SOA. “There’s a lot to talk about SOA. There’s a lot of communication and education needed.”

At the same time, he adds, he would certainly recommend the approach The Carphone Warehouse is taking to any company that is introducing new business processes and faces considerable integration challenges.

But even the fairly sophisticated BPM/SOA approach underway at The Carphone Warehouse is still a work in progress, he says. “It’s helped us define what we really mean by some of our business services – although we have a long way to go. There’s a level where you just have a day-to-day understanding, then you have a real understanding.”

Jessica Twentyman can be contacted via e-mail, jtwentyman@ark-group.com.

What to look for in infrastructural SOA/BPM products

When looking for tools that will enable full business-process management (BPM) in a service-oriented architecture (SOA) environment, several factors should be considered, according to Clive Longbottom of analyst group Quocirca:

Standards

It is important that the tooling adhere to open, generally adopted standards. As we are increasingly looking at a more virtualised environment, the need to be able to interoperate with other services is of paramount importance;

Connectivity

Few organisations are completely homogenous in existing tooling, or even in adoption of consolidated standards. Therefore, the capability to connect to existing applications, to data sources and so forth must be considered;

Interoperability

Wherever possible, the chosen package must be able to understand the applications that it connects to. With this capability, process flows are maintained in context;

Component registry

It is important that the resulting system has knowledge of what functional components are available for re-use. Therefore, a solid, scalable and secure registry will be required that adheres to open standards to enable interoperability with other, possibly external, component registries;

Process modelling

With the markets moving at a fast pace, business processes need to change more frequently. Therefore, we need to have tools that enable us to model new processes rapidly, to simulate these processes and then to pilot and implement them;

Monitoring and audit

The chosen solution must be capable of monitoring process events on an end to end basis, and to be able to report on these events for audit needs;

Resilience

Although SOAs are resilient by nature, it is important to ensure that the chosen SOA/BPM combination has inbuilt capabilities for failover, and for ‘roll-back and resume’, should anything happen in any part of the process (for example, within a non-resilient application) that adversely impacts the process;

Scalability

As we are looking at functional re-use here, it is difficult to carry out effective scaling modelling for the future. Therefore, we need to ensure that any solution has the headroom to deal with possible future growth;

Ease of deployment, use and management

There is little point in choosing a solution that takes too long to implement and is then unfriendly in usage and difficult to manage. The chosen tool needs to be rapidly implemented with minimum negative impact to the ongoing running of the technical infrastructure, and should easily integrate with existing management tools.

Source: Quocirca

Manage your SOA process architecture as a key asset

“The roadmap that guides developers’ choices about process implementation within the SOA strategy is a critical asset that will enable users to achieve and amplify many of the benefits of SOA in practice,” says Ken Vollmer, an analyst with IT market research company Forrester Research. Without an intentional approach, he says, processes can be scattered across the infrastructure in a myriad of containers, or force-fit into the wrong containers. “Scattered processes are more difficult to manage, can inadvertently duplicate key processes and allow inconsistencies to creep in,” he adds. He advises companies to:

Develop an SOA process architecture roadmap incrementally

“Like other elements of a SOA strategy, the process architecture should emerge over time as experience is gained with the available options for process implementation. The first roadmap should apply to your first few projects and should address the first year of implementation,” says Vollmer.

Revisit your roadmap on a periodic basis

For fast-moving and fast-changing organisations, says Vollmer, it may be appropriate to revisit and extend the roadmap every six months. In other organisations with less rapid evolution, “an annual tweak may suffice”. There will be three factors to consider each time around, he says: How have the technical options for process implementation changed? What experience has been gained from past implementations? And which new process architecture patterns are needed, if any?

Manage your library of process architecture patterns

A practical ceiling on the number of patterns will vary by organisation, but a range of three to five is reasonable for most, given the range of applications, processes, and platforms available today. “Each pattern should be easy to associate with key business initiatives, such as the need to support customer-facing processes with persuasive content or the need to manage the supply chain. This kind of business-focused strategy will be easier to sustain and fund than one that focuses on academic technical distinctions.” It may also be helpful to store business-process models in a central repository for general reference and reuse and as a focal point for change management of those models, he adds. This may be difficult to accomplish with current technology, “but it will get easier in the next year as more products are released and as those on the market today grow more mature and more functional”.

Source: Forrester Research