Share this content
MyCustomer.com

SOA what?

by
30th May 2007
Share this content

Stuart Lauchlan

By Stuart Lauchlan, news and analysis editor

Salesforce.com is getting into the service oriented architecture (SOA) space with Salesforce SOA, which delivers SOA as a service.

"The journey to SOA shouldn't be slowed by the baggage of legacy software," said Salesforce.com CEO Marc Benioff. "Salesforce SOA will radically accelerate the kinds of applications that are available on demand by continuing to remove the barriers of software infrastructure that have been imposed by SAP, Oracle and Microsoft."

There is a large degree of confusion and scepticism about SOA. A recent survey of 100 UK IT directors by research firm Vanson Bourne found that 84 percent of those polled thought their CEOs and financial directors do not understand SOA and its benefits. At the same time, two-thirds of the IT heads in the survey consider it hyped and a term used for marketing purposes.

SOA is the latest in a long line of highly hyped strategies. No industry outside of the catwalks of Milan is quite so hype oriented as the IT business. This year's next big thing is quickly supplanted by next year's next big thing, often before the first one is even implemented. There is a long and not particularly impressive list of abortive silver bullets that have been fired and which spectacularly missed their targets.

"Salesforce SOA will radically accelerate the kinds of applications that are available on demand by continuing to remove the barriers of software infrastructure that have been imposed by SAP, Oracle and Microsoft." Marc Benioff, CEO, Salesforce.com

AD cycle, object orientation, SAA, client server - the last one is probably particularly controversial as client server did work for a long time and there are those who would argue that SOA is in many respects just a variant of client server, tarted up in the latest frock from Milan.

But client server is a useful illustration of how fashions and fads change. Oracle CEO Larry Ellison tells us that client server was really dumb, a really stupid computing model that didn't work. Well, that didn't stop him selling it to hundreds of thousands of companies around the world for the best part of 20 years. A cynical mind would suggest that only once those sales began to level out and when there was the chance of a new technology model to 'start all over again' did Larry see the light about the 'stupidity' of client server and decide to let the rest of us in on the secret.

Now Larry somehow gets away with this sort of thing; others are less fortunate. And even Larry hasn't quite pulled it off this time. He's tried to get his applications customer base up off of client server and onto internet-only versions for a few years now, but there's been a fair bit of resistance that has led to Oracle having to extend support and maintenance deadlines several times.

Customers are increasingly cynical and increasingly prone to putting their feet down and not simply being led along by the vendor community. There have been examples in the past. Database firm Informix tried to bounce the market into what it called the post-relational era after sinking millions into advanced database technology. It told its customers that they couldn't buy relational stuff any longer in a bid to set the agenda; the reality was that customers took one look at the new technology on offer, decided they were quite happy where they were and decided that if Informix wouldn't sell them relational technology anymore then Oracle or IBM would. It wasn't much longer before Informix caved in and IBM ended up with some new database technology and a large installed base.

Winning by example

Customers these days are more marketing and PR savvy that ever before. They are far less prone to being won over by a flashy Powerpoint presentation and being told by an industry guru that there is a new religion and they must fall into line.

Many CIOs lived through the unfulfilled promises of the Common Object Request Broker Architecture and the Distributed Common Object Model, two failed attempts at service orientation. People just don't believe in silver bullets any more - you need to express it in ways that are credible and which speak their language.

Genuinely successful new computing models need to be expressed in real terms, hard cash terms, benefits terms. Look at the software as a service model as epitomised by the likes of Salesforce.com and NetSuite - they win over customers by example, by encroachment into enterprise accounts, by return on investment examples of savings and productivity increases for customers.

Of course, while caution and scepticism on the part of the punter is understandable, there is the extreme version of this which is harmful - both to the customer and to the vendor which is the tendency to bury your head in the sand.

A recent study by The Yankee Group shows that 44 percent of 473 respondents said their lack of understanding of web services and loosely coupled architectures were two inhibitors in adopting an SOA.

A recent survey by the Business Performance Management Institute found that only 11 percent of executives say they're able to keep up with business demand to change technology-enabled processes - 40 percent of which, according to the survey, are currently in need of IT attention. Worse, 36 percent report that their company's IT departments are having either 'significant difficulties' (27 percent) or 'can't keep up at all' (9 percent).

Despite obvious interest, a recent study by The Yankee Group shows that 44 percent of 473 respondents said their lack of understanding of web services and loosely coupled architectures were two inhibitors in adopting an SOA. Another 44 percent said they were unconvinced of the business benefits, while IT executives said the biggest challenge to interoperability and standards adoption is the cost of software and services.

The drivers for confusion are not hard to come by. Every major vendor claims to have adopted SOA and has published its own view and reference architecture for SOA. SOA start-ups are being acquired by larger vendors, creating further volatility. Every major standards body has multiple groups attempting to define SOA, adding to the confusion and slowing adoption of SOA. At last count there were more than 56 standards bodies addressing various aspects of SOA. Their efforts are not coordinated, so the result is almost the same as having no standards at all. It's up to individual IT groups to decide which 'standards' to follow.

There's a lack of common vocabulary across the industry that has made it difficult to share best practices. Then there's the age old problem of how IT and business can come to speak a common language. IT typically does not communicate effectively to the business how money spent on SOA will automate business functions and deliver solutions cheaper, better, and faster.

Why does SOA matter?

So why does SOA matter? What are the buzzwords that make it worthy of attention? First up is globalisation. All business need organisational agility to survive globalisation. When competitors can make the same product for less or can get it to market more quickly, a business needs to respond creatively and quickly. Then there's the age old need to do more with less. It's a standard industry refrain, one might almost say cliche. But it's never been more true than today.

Companies are trying to achieve growth through mergers and acquisitions. These put additional pressure on both business and IT organisations to consolidate and simplify disparate people, processes and systems. Companies are also on a perpetual hunt to cut costs. You can't go wrong talking to the wallet. How do you justify SOA in terms of pounds, dollars and euros?

In the post Enron world, all companies have to comply with government regulations to stay in business. Some recent regulations, such as Sarbanes-Oxley and Basel II, have required IT organisations to review and in some cases retrofit all business systems. And it's not over yet. Once the regulators get the bit between their teeth they're not going to stop. More red tape will be on its way and there's not choice but to comply.

There is a common myth that SOA is just a load of old objects. One reason that this causes problems is that a lot of the CIOs who should be looking into SOA are the same ones who were frankly let down by the object oriented revolution that never quite happened.

The prospect of the CEO doing time in jail tends to focus their attention on matters that they normally wouldn't bother themselves with - including IT priorities! Can SOA help you meet your regulatory requirements more effectively and keep you from a date with the lads in g-wing?

There is a technology aspect obviously. The starting point for implementing an SOA is with the systems you have today. After all, SOAs are not about replacing systems, they are about getting those systems to interoperate. If you are the typical IT organisation, you probably have an infrastructure that looks a lot like a very big pile of IT spaghetti. The chances are that you can't even name all of your mission critical applications, never mind figure out how to make them interoperate. So it's a herding cats sort of a situation.

In this respect you need to bear in mind that this is what enterprise application integration was supposed to do. And what business process re-engineering was supposed to do, for that matter.

There is a common myth that SOA is just a load of old objects. One reason that this causes problems is that a lot of the CIOs who should be looking into SOA are the same ones who were frankly let down by the object oriented (OO)revolution that never quite happened. The natural tendency is to assume that SOA evolved from OO and is therefore an OO technology. Actually SOA has nothing to do with objects and components. It is all about service providers, service consumers, and the services offered by the provider to the consumer.

This service component is vital. Too much attention is paid to the architecture element, not the service element. Think about the business processes. Think about SOA in action, what is it going to do for the business. Most people talk about SOA and web services interchangeably, but it is important to understand that they are not the same. SOA is an architecture concept, whereas web services is an implementation concept.

Some people define the difference here as being the same as that between mammals and humans. 'Mammals' refers to a class of species with common characteristics (such as a specific type of architecture). All human beings are mammals, but not all mammals are humans. Similarly, all web service implementations can be classified as SOA, but not all SOA implementations are web services.

So does SOA matter or is it a case of 'SOA what'? Ultimately it's up to you and whether your organisation is ready and geared up for the architectural and cultural shift it entails. But for a bandwagon in the software industry, this one has been rumbling pretty impressively - and the wheels don't look set to come off just yet.

Find out more about Stuart Lauchlan

Replies (0)

Please login or register to join the discussion.

There are currently no replies, be the first to post a reply.