REST is dead long live SIP

One of the things that always amazes me in technology is how people seem to think that technology revolutions have suddenly stopped because they've found a hammer. Whether it be Web Services, REST, EAI, ERP, Excel or anything else certain classes of IT people seem to become blind to the history of IT and think that because they are happy with what they are using that there will be no other developments.

As an example of this lets look at REST (as implemented by HTTP) and SIP, now REST lays down a bunch of constraints and has its HTTP implementation as the way to do everything. HTTP is of course limited in what it can achieve and certain tasks it just doesn't seem to be the right way to go, VOIP being one example, now SIP provides some similar elements in terms of philosophy of simplification (which is nice) but enables multiple protocol interaction and can (in theory) support application to application communication.

Now I've been looking at it and I'm not sure why you couldn't use SIP as a boot strap before electing to use HTTP, VOIP, Video or something else for communication between applications and from applications to people. After all wouldn't it be nice for the application to send you an SMS when something changes rather than polling a web server? These people talk about using SIP to kick off VoiceXML as a reasonable approach today, and VoiceXML is an HTTP based standard.

This would of course mean that HTTP, and potentially REST, would be relegated to specific application problems with an increased requirement for sophistication around the actual mode of interaction between systems and between systems and users.

The real point here is that no one technology will ever remain for ever as the pinnacle of achievement. It is either replaced (e.g. CORBA to Web Services) or commoditised (e.g. TCP to HTTP) and in both cases it ceases to be the cutting edge of IT delivery.

Will SIP relegate HTTP to "one" of the options? Who knows. But what I do know is that backing HTTP to be the cutting edge of IT delivery for the next 20 years is on a hiding to nothing.

Technorati Tags: SOA, Service Architecture

Why procurement is meant to be hated

There are three hated departments in most companies, they compete to be the most loathed of the bunch but one stands out from the other two as different.

The departments? HR, IT and Procurement.

These are always loathed and cursed and accused of preventing progress or just creating a set of bureaucratic processes that stifle peoples soul and remove the joy from the world. Only one of them has an excuse however.... procurement.

Now the reason that procurement is hated is that in fact this is the job of procurement. Have you ever wondered why procurement systems are almost always a pig to use, and why every "upgrade" seems to work in a completely different and more perverse way?

The reason is simple, the goal of procurement is to stop people buying things. If the CFO wanted to make it easy they would just give everyone credit cards and a cheery wave of "whatever you want is fine". The reality is that the purpose of procurement, a centralised service in the business, is to monitor and control all purchasing decisions, from a new pen through to a new building. The system should be painful to both suppliers and users, ensuring that both sides try and avoid interaction unless completely required. In this way procurement helps to focus spending on what is really required and removes spending on items that are just "wanted" because its not worth the effort.

This is an important thing when looking at building a business service architecture, understand the true drivers of services and don't assume that there are common elements across them all or that the end-users opinion always is the most important. Usability, performance and reliability are all great things when interacting with your customers, but in procurement they are positively to be avoided and a focus on annoying the user and making things slow and painful and prone to failure helps to deliver on the goal of reducing spend.

Don't assume that the goal is always to make things better, or that a system that is seen as "rubbish" isn't actually doing its job. Understand the business value that a service has and the drivers that create that value. This helps you to understand what "good" looks like in different parts of the business and focus your investment and effort accordingly. Don't assume that everything in a business needs to improve and get better, somethings either aren't important enough (general ledger anyone?) or are actually better off being bad (procurement).

So that is why procurement is meant to be hated. The more hated it is, the more successful it is actually becoming.

So that really leaves HR and IT in their daily fight to the bottom of the satisfaction league.

Technorati Tags: SOA, Service Architecture

Should IT deliberately create chaos?

There is an old IT joke

A farmer, an architect, a gardener and an IT guy are talking about which is the oldest profession. Now these chaps are bible literalists so they think the Garden of Eden was the start of everything.

The farmer says "Mine is the oldest profession as Adam had to tend all the animals and get all the fruit from the trees, if he wasn't a farmer he would have starved."

The gardener jumped in saying "yes but someone had to design the garden of Eden and put all the plants in place, so God must be a gardener"

"No, no" said the architect "First God had to create order and structure out of the chaos and build the universe so he must have been an architect"

"Ahhh" said the IT guy "but where did you think the chaos came from?"

Now the reason for saying this is that I saw one of the best pro-REST presentations at the Enterprise SOA conference in Belgium last week (which actually talked about business SOA). One bit I did have issue around was a concept that disorder and fragmentation was the "norm" of enterprise IT and thus the problems were the same as the web (its slide 37)

Internet vs. Enterprise
One is a gigantic, uncontrollable anarchy of heterogeneous systems with varying quality that evolve independently and constantly get connected in new and unexpected ways.

The other is a worldwide, publicly accessible series of interconnected computer networks that transmit data by packet switching using the standard Internet Protocol (IP).

Now in part Stefan has a good point, namely that IT systems currently suck. But where I'd disagree is that the goal of IT should be to create such a chaotic system with so little governance and control. This is one challenge I have when people talk about applying Web principles to the enterprise, it misses out on a fundamental difference between businesses and the internet. Namely that of compulsion.

It is true that IT unfortunately does create IT estates that are a mess and which have in the main part been driven by people who focused on the technologies first. This isn't however true for the businesses that they support, there is the ability in companies to compel change and to enforce conformity. Companies establish procurement departments, HR departments and even IT departments with these aims. Taking the Web view and applying it to business seems to imply that the chaotic nature of the web is the correct approach to take in creating an IT estate that works for the business. This doesn't make sense.

We need to understand in IT that sometimes compulsion is a better approach, if you are putting in SAP its best to fit the business to the package not the other way around, equally if you are looking at links between businesses is it better to take the standardised approach of procurement and enforce conformity of contract or to enable a "dynamic discovery" approach (whether UDDI or via MIME)?

IT needs to learn from the business an understand the power of enforcement and contracts, rather than thinking that its the business that needs to learn from the chaos that IT creates.

(Oh and Stefan, join the revolution. My presentation on SOA Methodology is web delivered :) )

Technorati Tags: SOA, Service Architecture

Great parody on technical IT

Pete Lacey has a great parody on the technical focus of IT folks. Its a wonderful trawl through the way that business people ask for solutions and how IT in return focuses on technology.

In this hilarious romp through how businesses continued to ask the same questions and the IT department continued to offer them yet another technology that would this time solve the problem. There is a great bit in there where he demonstrates his comedic brilliance by pretending that he thinks that VOIP is a business requirement (rather than the requirement of course being to reduce the phone bill), this wonderfully highlights how technologists can't see the difference between a business requirement and a technology solution.

There are great bits in there to highlight, almost too many to mention, but for me the real bit that made me realise how great a parody was this bit

"And… Well, you know the rest. They picked the wrong technology again, despite the fact that the right choice was staring them in the face. Like CORBA before it, SOAP..."

Brilliant, a superb highlighting of the extreme arrogance of technologists in thinking that the next technology really will be the silver bullet. He then drives the point home by brilliantly misunderstanding SOA and equating it to network oriented computing (although I think just saying Distributed Computing would have underlined the parody a little better).

Thanks to Pete for the shout-out at the end to my BSA post. He hilariously pretends to misunderstand the difference between architecture and requirements gathering, a common problem for technical IT.

I don't think I've seen a better post that sums up the problems of technologists thinking that technology is always the solution and that anything more contextual is a bad idea.

Truly well done Pete, a great post on the issues of technologists focusing only on the technology and assuming that this will meet the business needs.

Technorati Tags: SOA, Service Architecture

Business Service Architecture - is it time to admit defeat on SOA?

Over on the Yahoo email list there are a bunch of emails around SOA/REST etc etc and as ever Mr Tilkov summed it up well when he talked about Business level SOA being implementable using REST, but technical level SOA being different to REST.

So what I'm thinking is it time to bring clarity to all of this and admit that the techies and vendors have "won" the battle for the SOA name? Time to give up on the SOA name as something that has been co-opted purely to the technology and which is sometimes more focused on selling products than on delivering solutions?

My proposal is that we should start being clear when we mean business SOA by calling it a Business Service Architecture. The goal is to clearly differentiate business SOA from technical SOA and help move the debate on from the current technology centric debate towards one that is about changing how IT works to make it focused more on business solutions than technical implementations.

Business Service Architecture - Business problems solved, no matter what the technology.

Technorati Tags: SOA, Service Architecture

Exception Management and SOA - a Webinar

Last month I recorded a Webinar with Vitria (one off registration required) on how exception management fits into SOA. The key point I was trying to get across in the presentation is that exception management is a business issue and that SOA should be about the business and therefore thinking about business exceptions is a core requirement for any successful SOA.

Exception management is about when things go wrong, two core points here

1. Sometimes its okay for things to fail and ignore them
2. Exception management is a cost overhead, getting people back onto the primary flow is value creation

SOA as technology wouldn't think about exception management, SOA as business must.

Technorati Tags: SOA, Service Architecture