Benefit of the Benefit

April 27, 2008

Every good salesman knows that when you’re selling you don’t sell features – you sell benefits. But that’s not enough. Weak proposals that are based on generic benefits (e.g. copied from a vendor whitepaper) are unlikely to be convincing. Luckily, there is very simple brain storming exercise you can use to come up with benefits specific to your organisation – thus making your proposal far more compelling.

The technique involves taking a benefit and then refining it by asking “what is the benefit of that benefit.” You basically keep going until you find something that resonates with the prospective client or customer.

For example, lets assume you’re trying to sell a car which has excellent fuel economy. The fuel economy is the feature. The obvious benefit is: you’ll save money on fuel. Benefit of that benefit: you’ll be able to spend more money saved on things important to you.

That’s a simple example, but you should keep drilling down until you find a benefit that appeals most to the prospect. Here’s an example. Another benefit of low fuel consumption is: you won’t have to fill up the car as often. Benefit of that benefit: you’ll spend less time in petrol station queues. Benefit of that benefit: when you go on family holidays you’ll be able to maximise the quality time you spend together. Benefit of that benefit: the memories you’ll have from the quality time you spend together will last a lifetime.

The slightly cynical readers will be thinking “that sort of stuff is for shady used car salesmen”. If that’s what you’re thinking then remember that all buying decisions have significant emotional element. And this includes IT proposals. A proposal is essentially a sales tool – you’re trying to sell the reader on your idea. So you have to press the right buttons. And this technique will help you find those buttons.

It’s hard to do a genetic SOA example because every organisation has different “hot buttons”. This example is somewhat contrived but it will give you some idea of the power of this technique (especially when you have a few people brainstorming).

I’ve seen mediocre SOA proposals that have a bulleted list of benefits and maybe a definition of what each one means. Definitions don’t sell. Here’s an example of how to do it better: Take the benefit of “reduced integration costs”:

  • Benefit of the benefit: because the cost is less, you will be able to integrate more applications.
  • Benefit of the benefit: you will no longer be tied to delivering additional functionality through enhancing existing applications built in-house
  • Benefit of the benefit: IT will be able to devote more time to evaluating best of breed solutions that meet business requirements.
  • Benefit of the benefit: best of breed solutions are typically higher quality and provide richer functionality that bespoke applications written in house
  • Benefit of the benefit: the richer functionality means that staff will be more productive and the higher quality will mean less downtime due to computer issues

The person reading your proposal is not being called on to think or to make these connections themselves. Instead, you’re walking the reader through your thought process. This is all pretty simple stuff, And it works.

SOA Business Proposals

April 25, 2008

Recently I’ve been preoccupied with the issue of poor proposals from internal IT departments to the business. Unlike external service providers, internal IT departments don’t have as much practice at writing proposals and they don’t access to sales people to polish them up. So I thought I’d devote a few blog posts to business proposals and share my experiences about what works and what doesn’t.

I’ve got university degrees in both IT and accounting/finance (both ‘hard sciences’), so not surprisingly my proposals are focussed on hard science – facts, dollars and cents. Of course my proposals include non-financial benefits (as all proposals should) but those aspects are secondary. But it seems that my proposals have been missing something.

Yesterday I had a chat with former boss and we were discussing my previous post. He cautioned me not to get too hung up on black and white facts in proposals. He suggested that good proposals should sell a vision. He’s a very smart guy and has been around a lot longer than me so I had a think about what he said. And here’s what I came up with.

Typically when the business has a problem they go to the IT Department and the IT Department comes up with a solution and tells the business how much it’s going to cost and how long it will take. More often than not, the two sides then begin a dance around the project triangle as they negotiate tradeoffs between cost, time and scope. Eventually both sides come to an agreement and the project begins.

This approach has been around for a long time and it works well when everyone is “project focussed.” The process of producing a proposal for one particular project is largely a management exercise – you’re concerned with project management concepts such as resources, scope, quality and time. However, when we shift to an “enterprise focus” (as in the case of SOA) the proposal should contain elements of leadership.

In my mind the distinction between management and leadership is simple: managers manage tasks and leaders lead people. This is an important distinction because the single most important success factor for any SOA initiative is understanding people issues. Technology and the mechanics of managing a project are secondary.

Experience tells us that when it comes to “people issues” taking a management approach won’t work. If you’re relying on management structures, policies, procedures and the like, then most enterprise wide initiatives will fail. Rather than managing, you need to lead.

And leadership starts with the very first proposal. If your proposal is focussed purely on numbers and only tries to sell a solution then SOA will never get up – in almost all cases there are far less risky, cheaper, less disruptive and quicker ways of delivering a solution to a single problem than SOA.

So of course your proposal needs to sell a solution – but it also needs to sell a vision. Thanks Adam.

Business Agility and SOA

April 24, 2008

It’s rare to find an article or blog post about SOA that doesn’t have the word ‘agility’ somewhere. It seems that the two words are inextricably linked. The problem is that a lot unimaginative folk make ‘agility’ the centrepiece of any business proposal featuring a service oriented solution. For reasons I’ll present here, agility-based proposals risk being rejected.

By all means, include agility in your proposals, but there’s a few reasons why you shouldn’t make it the headline

Agility is unachievable – I.T. will always be a bottleneck.
No matter how agile you become, it will never be agile enough. If it currently takes you 3months to deliver a solution and you can reduce this to 1 month because of SOA – everyone will be happy with the improved agility. Until next week. When someone needs something in 3 weeks not 4. As the organisation becomes more agile, people will begin to see more and more possibilities. Unfortunately, coming up with new ideas will always be quicker than implementing them. This is particularly true when people begin to truly innovate and seek revolution rather than evolution.

Of course “more agility” is better than “less agility” – but (sorry for the cliché) agility is an endless journey not a destination.

Agility is not tangible.
Agility is an abstract concept and as such it can’t be measured. If you can’t measure it then you surely can’t calculate ROI so why make it the centrepiece of your proposal?

To make the concept meaningful and measurable you need to operationalize it. In some cases this is relatively easy to do but in many cases it could be very difficult, not least because there are no metrics for the “current situation” so you can’t quantify improvements.

Agility is a long term goal.
Increased agility is a long term goal. Its hard to say how “long term” but anecdotal evidence seems to suggest 3 maybe 5 years. Its almost impossible to calculate any meaningful ROI figures that far in advance.

And there’s another complication. Say you produce a perfect SOA today and 3 years down the track you have perfectly accurate and indisputable metrics to show that the business is more agile. How do you calculate the percentage improvement you can attribute to SOA vs. the improvement derived from other things (e.g. better productivity tools).

Businesses are already agile enough.
This may sound controversial but isn’t really. In my career I have yet to see any organisation pass up a lucrative business opportunity because IT couldn’t deliver a solution. Businesses will bring in an army of temps, develop spreadsheets, Access databases, paper forms – you name it. It will all be glued together with “swivel chair integration#”, file extracts/imports and countless reports. Hardly and optimal solution but it will work. Businesses have an amazing ability to mobilise to exploit opportunities – with or without IT help.

# if you’re not familiar with the term it basically means a person sitting in a swivel chair and spinning around manually re-entering the data into multiple applications.

Businesses don’t invest in agility.
Think about it. If the business asked you for something and you gave them two estimates, one for a quick and dirty solution and one for a more considered long term solution, which one would they choose. Most probably the first one. Most businesses are only concerned with the “here and now”. It doesn’t matter if you can do it quicker next time – if they have to wait longer now. If they’re not interested in agility now, why have a proposal that says “we’ll give you agility in X years?”.

So there you have it. When you create a proposal it has to be credible. Make no mistake, most business managers are astute. If you put something into your proposal that can easily be dismissed then the whole proposal will struggle to be approved. This is especially the case if the reader dismisses the ‘headline’ item.

If Your SOA Uses Decentralised Data – Don’t Cheat!

April 21, 2008

There are a lot of debates in the SOA space. One of those debates is about centralised vs. decentralised data. Recently I reviewed an architecture that on the face of it seemed to use decentralised data. But after digging a bit deeper I noticed that someone had been cheating a bit.

One of the key principles in SOA design is respecting service boundaries. We need to create loosely coupled services. I recently reviewed an architecture that seemed to tick all the boxes. Overall it was quite well done but I had a nagging feeling that something wasn’t quite right. I finally figured it out – and in hindsight it was obvious.

It turns out that even though service boundaries were well defined and adhered to at the front end, the back end was another story. I didn’t spot the problem immediately because services didn’t share physical data stores – they were physically separate databases. The trouble was that some clever developer decided to create cross-database queries. Service A needed a bit of data that was in Service B’s domain and rather than getting the data via a service call, the developer went via the back door!

The benefit of this approach is obvious: it’s quick. Quick at development time and quick at runtime (performance of a cross-database query will be far better than a service call)

The downside: it’s rubbish. It’s violating one of the fundamental principles of SOA. Now there’s tight coupling between two services and Service B is no longer autonomous. People working on it may have no idea that someone is relying on the schema not to change or the data store not to move.

In SOA, distributed data does not (necessarily) mean physically distributed – it means logically distributed.

There is nothing with having multiple services having their data store on the same physical server. Although I personally wouldn’t do it, you could even have multiple services in the same database on that server – provided each data store is an island (e.g. in SQL Server making sure tables are owned by different users).

As we’ve see in this example – having physically different data stores doesn’t mean that architecture has decentralised data.

My advice: if you need centralised data then design for it from the start. If you design for decentralised data then don’t cheat. If you cheat, you’ll get the worst of both worlds.

The SOA Camel

April 16, 2008

There’s a well known saying: “a camel is a horse designed by committee.” The saying has been attributed to Sir Alec Issigonis the car designer responsible for the hugely successful Mini. Design was his chief concern – as it is for Enterprise Architects – so it pays to heed his warning.

There are plenty of people with the word “architect” in their job title: information architects, business architects, infrastructure architects, software architects, solution architects and enterprise architects – just to name a few. There is no doubt that each of these people has a unique skills set and speciality. When you’re building something as complex and far reaching as an SOA it pays to consult with everyone you can to make sure you’ve got all the bases covered. In other words, the process of designing your SOA should be inclusive. But there is a fine line between being inclusive (which is good) and designing by committee (which is bad).

When you get a bunch of highly skilled technical folk in a room “groupthink” is definitely not a problem! Each person passionately explains why his area of expertise is the most important issue. The Information Architect says “it must be about the data!” while the Infrastructure Architect says “we must be able to manage this – that’s the most important thing!” If you try and reconcile the disparate view and try to reach a consensus you”re on your way down the “design by committee” path. The resulting design will be needlessly complex – and the whole process will take an excessive amount of time.

So how do you leverage the valuable knowledge of everyone concerned and keep everyone on-side, while actually delivering a design that is more like a thoroughbred racehorse and less like its fellow ungulate – the lumbering camel?

A colleague of mine came up with a brilliant solution to solve this problem. Rather than debate each and every decision he decided to spend some time devising a “Decision Framework”, which is basically a list of criteria for resolving conflicts. He was working in the software design space with senior developers and I’ll use his examples but the same could be done with architecture decisions in a room full of architects.

Criteria 1: Consistency and readability of source code is important so we will standardise on the coding standards used by Microsoft.

This means all arguments on the naming conventions of classes, projects, variables, namespaces and the like are avoided.

Criteria 2: We will use standard libraries from Microsoft”s Enterprise Library.

This means (for example) that all arguments on the “best” way to connect to a database and execute commands will be nipped in the bud. We will do it the way the Enterprise Library does it. We wont roll out own code and we wont download other toolkits or libraries. It will also avoid arguments about exception handling, caching, logging, security and everything else covered in the Enterprise Library.

You’ll note that the criteria in the decision framework are clear and unambiguous. No fuzzy “motherhood” statements which are open to interpretation such as “we shall use best practice”. Also, the criteria are hard to argue against. You can’t argue that “Microsoft is wrong.” You may have a personal preference which contradicts Microsoft but that doesn’t make Microsoft’s idea wrong.

Once you have a decision framework in place you need two things. Firstly, you need to get everyone to agree that the criteria in the framework are sound. This ensures that any decision made with reference to the framework will be well thought out and logical – and cannot be accused of being a “whim” or “personal preference”. Secondly, you need strong leadership to make sure everyone follows the “rules”. When there are opposing views, they are each measured against the decision framework. And the “winning” opinion is the one the most closely resembles the criteria in the framework.

SOA and the Monkey’s Paw

April 13, 2008

One of the reasons that SOA gets so much press is that it has the potential to become the catalyst for the alignment of business and IT. In most organisations the IT folk crave recognition and they want to be seen as equals with their business counterparts. SOA can be a great way for IT to get their wish, but it could have unexpected consequences.

The Monkey’s Paw is a horror story written in the early 1900’s. The paw of a dead monkey has the power to grant the holder three wishes. Unfortunately the paw is cursed and when a wish is granted there is an unforseen and horrific side-effect.

So what’s this got to do with SOA?

IT has a wish: we want to get out of the back office and rub shoulders with the business and to be seen as equals. To achieve this wish we need better alignment between business and IT, and SOA is seen as a key plank of our alignment campaign. The theoretical benefits of SOA are so compelling that in many organisations IT may get its wish. But beware the curse of the Monkey’s Paw. With increased alignment comes increased visibility.

In days gone by, architecture was largely a back office endeavour: object oriented programming, client-server, web based applications, n-tier/distributed applications. To some extent we could learn on the job. In fact in many cases we had to learn on the job because when you’re on the cutting edge there is not a lot of ‘best practice’ guidance available. We built things and they may not have performed as well as we’d like and they may not have been as secure or elegant or maintainable as we’d like. But they worked. As we learned things new things we could ‘tweak’ individual parts of the solution. The beauty of this learning process was that we could do it in the IT department, behind closed doors. IT wasn’t visible in the business unless something went horribly wrong.

Now we have SOA. And SOA is not like previous architectural shifts because the business is interested. IT will have greater visibility so we have to change our ‘modus operandi’. We need to recognise two things in particular:

  • We can’t be seen to be learning on the job. Can you imagine going to a doctor and seeing him thumb through a textbook while he tries to diagnose you? You wouldn’t be overly confident in his abilities. IT is often criticised for not “delivering the right thing”. SOA doesn’t change that. But lets at least make sure we’re capable of “delivering the thing right.” Before you tout SOA in your organisation, you better know what you’re doing.
  • Mistakes will be costly and visible. When you delivered your first web solution it probably wasn’t great. Sure, the solution may have needed some refactoring, but I cant think of a single (sensible!) architectural decision that may have forced the whole application to be thrown away. SOA is different in three ways: a) there are many architectural decisions to be made; b) almost of then are sensible, in a certain context; c) most of them are extremely costly and time consuming to reverse. I repeat. Before you tout SOA in your organisation, you better know what you’re doing.

When your IT department steps out of the safety and anonymity of the back office into the full glare and scrutiny of business, you’d better be ready. They’ll be watching you.

Business Hierarchy of Needs

April 10, 2008

Anyone that has had basic exposure to the field of psychology would be familiar with Maslow’s “Heirachy of Needs”. Businesses have a similar heirachy of needs.

Maslow’s Hierarchy of Needs is often presented as a triangle :

Physiological Needs

A person’s physiological needs include air, food, water, shelter, sleep etc. Physiological needs are the difference between life and death. A business also has physiological needs : they need suppliers to provide raw materials as inputs, workers to process these raw materials and clients to buy the resulting outputs. Without all three the company will eventually die.

Safety Needs

Safety for people means things like security, morality, law and order. From a business point of view ‘safety’ means one of two things :

  • • Being profitable. A business can survive without profits by breaking even year after year but that doesn’t take into account the opportunity cost of the capital tied up in the business. Investors want a return on their investment.
  • • Fulfilling its mission. Despite not earning a profit (or in some cases even making a loss), not for profit organisations can feel ‘safe’ if they fulfil the mission their benefactors (e.g. governments, philanthropists) have entrusted them with

Belonging Needs

For people these include family, friendship, affection and relationships. The parallel in business is obvious : businesses want to build close relationships with their suppliers and customers.

Esteem Needs

Things like achievement, status, reputation are as important to people as they are to businesses. Business want to be the preferred supplier, they want to be seen as an industry leader and they want prestige. Not because they want to feel “warm and fuzzy” inside – but because all of this translates to the bottom line.


Innovation, creativity, adaptability/agility and learning are all self explanatory and relate equally well to individuals and to businesses.

Why is all of this important? Before you write a proposal or pitch an idea to the executives, the VERY LEAST you should do, is to find out where your organisation fits into the hierarchy of needs. For example, if you’re pitching the benefits of SOA don’t try and sell something at the “self-actualisation” level (like agility) if your organisation has major problems at a lower level, for example supply chain problems. If you propose something that will satisfy that physiological need you improve the odds of your proposal being approved.