Think Holistically, speak clearly

Recently I've had a couple of occasions where I've needed to work on some direct communications to some execs. In all of these (both internal and external) there have been a whole list of issues but a couple of actually core ones. People often like to hide in the detail of these conversations, particularly in change programmes, and you lose the big picture as they sink into arguing line 83 of the spreadsheet.

Most of the time the issues come down to something very specific from which other issues stem and I've found that by ignoring the detail when engaging with people it helps hugely in getting the result you want. So if the lack of a specific person means that you aren't engaging with the business, aren't getting the documentation and aren't getting the sort of clarity you need then completely ignore the later points just be specific that "lack of Bill = FAIL". If they want to get specific then just say "engagement, documentation, clarity, I can go into the specifics but it all comes back to having Bill". Let the senior people ask for the detail, let yourself just provide the clarity.

If you don't then its certain that the person you are talking with won't, after all you are the expert in this area so how are they meant to understand it better than you?

With some SOA efforts I've seen this where people start saying things like "We need to reorganise the teams, set up a new procurement process, buy an ESB, get a rules engine, get finance engaged, agree on the KPIs" and the list goes on. The reality is that the first two bits are the most important and the rest will either drop out or be materially effected by the first two.

The problem is that engineers, and especially architects, like to "think holistically" which means "telling everyone all the problems" in other words there is a lack of filtering between the brain and the mouth.

So take that list of 20 "big issues" on your project and look at it. If you could fix just 2 (or at most 3) which would they be? Do they now seem quite a lot bigger than the rest of the list? So go and be clear "these mean FAIL".

Technorati Tags: SOA, Service Architecture

When to switch to static

One of the bits I always find funny is the "X scales" pitch, whether it be stateless EJBs, REST or anything else its always one of the magic phrases. Mainframes scale, really quite effectively, they handle some very impressive numbers. Those Blue-Gene systems from IBM seem to scale pretty well too.

The key to the claims at scaling in most of these things is that you can throw more tin at the problem. Often this ignores the fact that there is a chumping database behind the scenes where scaling is a bit tricker, and more expensive, or they do smarts like Amazon's S3. The point is though that sometimes the unexpected happens and you have two options.

1) Scale to the possible peak that occurs in an exceptional circumstance
2) Prepare a static page for the exceptional circumstance

Sometimes, for instance if your website is the way you handle customers in the exceptional case, you have to go for the peak. Lots of times however its about getting information out.

As an example, the South East of the UK today was brought to a halt by the sort of snow levels that people in Boston would consider a "flurry" and the folks in Scandinavia would just shrug and walk on. This brought lots of the various sites down, for instance SouthEastern (my local rail company) had their site offline for most of the day.

What did they need to tell me? ALL TRAINS ARE CANCELLED INTO LONDON. But their dynamic site couldn't handle it. Later in the day they switched over to a PHP solution with a minimal (single) page on it but it took a good half of the day.

This is why people should always think about the ultimate fail-over for their sites. Sure you've scaled to some peak, but what if the worst happens and you get treble that peak? The answer is to switch to a file based approach, load that file into memory and just serve it as fast as you can, its amazing how many connections you can support when you are just returning a single static memory loaded page.

Some people will say "scale to that extraordinary peak" but you know what? 99.99% of the people hitting the site were looking for the same single piece of information and saying "normal service will be resumed once the snow has melted" would have been fine for the one random person looking to visit their aunt next June.

Failure conditions don't always mean that you site hasn't failed, it means that you've coped with that failure in a smart way.

Technorati Tags: SOA, Service Architecture

Getting lost at the EDGE

Speaking with a business & commercial chap today he had a bit of a moan to me about architects worrying about edge scenarios. His complaint was that they kept trying to consider all of the edge conditions and then design around them when in fact he

a) didn't think those things would happen
b) even if they did happen he'd be fine for the system to collapse
c) thought the investment the architects had made in edge conditions was a waste of time

The point here is that sometimes its okay for a system to fail and also its okay to specify what a system won't handle rather than trying to make it handle everything.

Now some architects may leap forward and say "well what about the future, what about extension"

But you know what? If the business doesn't want to pay for these edge conditions then why on earth are you bothering? Sure you should force the point and say "the system won't handle X,Y,Z or pigs learning to type in ancient greek, is that okay" rather than "The system doesn't handle X,Y,Z or greek typing pigs so what we should do is redesign the keyboards to enable pigs to work with the system when they learn to type".

The sort of architectural "perfectionism" that underpins this mentality is, IMO, one of the worst traits of architecture, namely the avoidance of getting into the solution. By putting these edge cases in the way the architecture and design phase takes longer and the dirty solutioning piece when the architecture actually has to be proven can be postponed.

Edge conditions can be non-functional as well "What if your carbon blade procurement system is turned into a Facebook app and gets 10m hits in an hour?" The answer is of course "That won't happen, and even if it did we sell carbon blades to the airline industry so why on earth would we worry about a Facebook app?". Still architects will argue about the "most scalable" way to build the solution that is currently targeted at 5 end-customers with up to 20 concurrent users max.

Sometimes architects claim this is them being "professional" and considering the "future" while taking a "holistic" view. What rubbish, its about architects focusing on architecture and losing track of the big, and simple, picture and merrily pursuing their own mental exercises to demonstrate their architectural prowess.

Edge conditions can be hard to deal with, but that doesn't mean you HAVE to deal with them. Often, in fact most times, the right approach is to declare them out of scope and make it clear what the system won't do as much as what it will.

Technorati Tags: SOA, Service Architecture

One Service many interfaces

I'm doing some departmental re-org stuff at the moment and its made me really believe in the difference between the service and its interface. Way back in 2000 I worked on a project and developed a framework (who didn't in 2000) that allowed you to have multiple different interfaces on the same back-end service. The reason for this was that different clients needed to see different subsets of capabilities and rather than showing everyone a great big interface with everything on it, which would be complicated, it seemed simpler to just separate the interface from the service.

Doing the business bit has made me really strongly realise how important it is to keep them apart. Right now I've effectively got four different groups who need to interface to this one business service.

Now the core of the service is the same for everyone, they all want basically the same thing. The difference comes in exactly how they want to interact with it and the specifics of the capabilities that they will use. This means four independent sets of external KPIs (remember to always think of the consumer when designing service descriptions) and four semi-independent sets of capabilities. By semi-independent I mean that they are in fact strongly linked but the mode of interaction is slightly different in each case.

Now if you were building the code for this you might be thinking of four independent services that shared information together. The problem is that this means that you have disjoint processes as the reality is that one of the major KPIs for the service is that you are linking properly with all the other groups.

Sometimes you will build the interface as just that, an interface, other times it will be a lightweight façade that might do some process or data manipulation work, on a very few occasions it might be something heavier weight but still using the same underlying base service.

The other technical view would be the "sod the users" and just have one interface. The trouble is that this just means that it will be rubbish to use for everyone and it will in fact be harder to manage because that doesn't represent the way that the world actually operates.

So what I've got is a service description that describes what the service does and then I'm building four service interfaces (which are to all intents and purposes service descriptions) on how it will interact and be measured by the four external parties. This means that from a catalogue perspective I have five services, from a consumer perspective they are all getting the service that they want and from my perspective I'm getting the consistent management and centralised governance that I need.

Everyone ends up happy and the amount of duplicated work is reduced. So keep your interfaces independent of your service.

Technorati Tags: SOA, Service Architecture

REST is a crap name in a web world

Okay I was looking around for some REST stuff today, specifically around performance tuning for the mandlebrot stuff. So I thought I'd search for "REST performance tuning" and its no better on yahoo. Like when Microsoft talked about having a language called "COOL" and its bad enough that they ended up with .NET (image searching for COOL .NET application tuning).

For something that was designed for the Web, indeed which helped design the protocol behind the Web there really wasn't much thought put into naming it so it works well on the Web.

Technorati Tags: SOA, Service Architecture

REST is dead long live the Web

REST met its demise on January 1, 2009, when it was wiped out by the catastrophic impact of the economic recession. REST is survived by its offspring: mashups, SaaS, Cloud Computing, and all other architectural approaches that depend on the web.

REST had begun to gain some traction in 2008 as the "next big thing" in technology, promoted by vendors, analysts and champions as being the only way forward, often by the same people who had promoted both EAI and Web Services as the only way forward. The economic downturn however has led to people looking at REST as nothing more than a new technology driven fad that was disconnected from the daily problem of a profitable business. Proponents would laud Google, Amazon and a small number of new startup companies as being the example that all the old crusty companies should follow.

These old crusty companies however have heard it all before, both from the .com boomers who were meant to replace them and from the technology vendors who have shipped them varying degrees of snake-oil over the year. Fortunately all is not doom and gloom for REST as these old crusty companies are doing exactly what they did with .com and looking at what they can do to drive down costs and increase profitability by using the web. As REST proponents shout about PUT/DELETE/POST and GET and whether anything from a browser can truly be "RESTful" because it doesn't have DELETE then the business users are looking at the Web, and more especially the services delivered via the Web as an excellent way of managing their IT costs.

Integrating these new Web delivered services into their enterprise often means using exactly the approach that REST proponents advise, but it is not REST that is important it is the Service. REST vainly tried to make itself the thing that people should care about but the sad reality was that its role was simply in helping people connect to the services that they use.

Already REST advocates are leaving the funeral a promoting the "web centric view" as being the only way of the future, but the crusty old companies continue to operate successfully often using systems that predate the web and chuckle at the cute naivety of these technology prophets.

Surviving REST are a series of technologies that at their core are about using the principles of REST hidden away in their dark hearts like a secret that must not be told. Mashups and SaaS often rely on REST but proclaim instead the business benefits, the productivity gains or the business service that they deliver. The biggest child of REST is the Web, it shouts as a colossus across the globe a shiny beacon of light which proclaims the success of its heritage, but no-one knows or cares about its parentage only about its usefulness.

So RIP REST the business never really knew you at all.

With deference to Anne

Technorati Tags: SOA, Service Architecture