What conference calls tell us about REST

I've just got off a conference call, the topic isn't important. What is important is that at the end of the call lots of other people started joining. Why was this? Well they were joining the next call that the meeting organiser had.

This got me thinking about REST and resource identifiers and why if you are doing REST its really important to understand what the right resource is. With conference calls there are basically two choices

1. Have a unique conference number by person, this person therefore can just hand it out to people and they can dial in at anytime for a meeting
2. Have a unique conference number by meeting. So when you want a meeting you have to arrange it and get a unique ID

Now the first one basically means that you always have a meeting ID but of course has a major problem: Your meetings can all begin melding into one.

The second is what you should be doing as it means that the meeting is the resource and the participants join the meeting. Someone can still be the chair if required but its the meeting that is the discreet entity.

The point here is that when doing REST you need to think about the implications of your resource hierarchy selections and not tie them to the first thing that you think makes sense.

Technorati Tags: SOA, Service Architecture

Start on the road to SaaS with SPUD

Lots of companies are leaping onto SaaS in the manner of a drowning man grabbing onto a tiger shark in the vain hope that all will be fine. The problem is that they haven't really thought about what they want and what it takes to properly adopt SaaS so what they do is take the same old approach to package adoption

1. Work out what you want to do
2. Buy a package/SaaS solution to do some of it
3. Customise the package/SaaS solution to a point where its specific to your business
4. Act surprised when it goes over budget, over time and turns out to be a nightmare to maintain

SaaS can actually be worse in the 4th point that traditional packages as at least if you do the truly dumb of changing the database schema under Oracle or SAP then you have the choice of not upgrading something that just isn't possible with SaaS where all of your customisations and specific developments have to be upgraded when the SaaS vendor says you do.

The right way to adopt SaaS is really the right way to adopt packages. Its not rocket science and comes down to a very a simple point

You've chosen to use a package as you don't see this area of your business as differentiating

If you do think its differentiating then why on earth are you picking something that all of your competitors can buy? If you think its "10%" differentiating then you are probably kidding yourself and in reality its a case of its 100% non-differentiating but there is something you should be building on-top of the package that could add something. In otherwords you've got something extra that differentiates, not something different.

Anyway so once you've faced the reality what is the obvious conclusion?

Package implementation is about changing the business to fit the package not the other way around

So you need to focus on fitting the business to the best-practice that you've purchased from the package vendor and delivering a Standardised Package (SP) as quickly as possible. Not unsurprisingly companies that do this tend to find their package implementations hit time and budget much more often and they tend to deliver greater operational efficiencies as it challenges locally held truths that turn out to just be historical relics. The point here is that in reality you are undertaking a business programme that is just enabled by IT and the package vendor is providing the business processes.

Now the next question is of course how do you pay for this sort of solution? Well its now not about differentiation so its really about cost to serve which means that what you want to do is pay based on the business utility that is being provided. Implementation aside this means that the running of the solution should scale up and down in-line with that utility. The utility could be number of staff, number of transactions, value of transactions or anything else that represents what the business is actually paying for. This means that the package needs to be utility delivered (UD).

Hence the best way to adopt SaaS is really to look at it as just one delivery mechanism the core is really around two key decisions, the first is the business decision

• Standardised Package (SP)

The second is the economic decision

• Utility Delivered (UD)

Hence the best way to adopt SaaS is to ignore SaaS and concentrate on what you are trying to achieve as a business, which is SPUD. SaaS is the UD part of SPUD but to make it successful you need to do the SP bit as well.

Technorati Tags: SOA, Service Architecture