They’re both hard to explain to the non-technical crowd. Sounds simple, doesn’t it? Well, it is. But that simple fact is behind surprisingly large problems we see today in marketing and selling software.
Tivo is the most widely understood example I can point to here; doubtless there are thousands of others. But the little device that records TV is case study for this affliction. I’m a Tivo user, and I’ve completely given up trying to explain to a non-Tivo users how great they are. I can discuss the benefits of a Tivo to anyone who’ll listen, but at the end of the day they’re just so many words. Wishlist TV viewing, TV on my own schedule, a library of TV that I actually want to watch – all of this puts me immediately at risk for the glazed over eyes and senseless nodding that says “I stopped listening a while ago and can’t wait for you to stop talking.” The closest thing Tivo has to a “killer” feature – one that that people grok straight off – is instant replay. Beyond that, I just tell people who ask to see if anyone they know has one. Seeing is believing.
That singular problem – the basic inadequacy of language to distill technical features and functions into an easily understood package that gets people excited – is very common to the technical world. But it’s a particular problem, in my view, for purveyors of Service Oriented Architecture technologies.
Vendors are still leading with a technical sell (try searching any of the big vendors sites and see what the first few links are) – quite understandable given that: a.) SOAs involve significant architectural shifts and b.) because the business buyers that I speak with still have little if any idea what an SOA is and more importantly why they should care about it. If one believes – and I do – that SOAs are a potentially game changing technical approach, why are business people so indifferent? I’d argue that it’s because technologists have not done a good job of explaining what an SOA means, in business terms.
Instead, pro-SOA arguments often begin with varying combinations of grandiose promises like “improved productivity and efficiency,” “greater adaptability and flexibility,” “reduced overhead and redundancy.” All of which can be true. But if there’s one thing that my experience as an SI and analyst has taught me, it’s that a business person rarely – if ever – will take a technologist’s word for it. They’ve been around for years, hearing similar sounding arguments about the technology flavor of the month, and in the end they often don’t get what they asked for, when they asked for it. So if they won’t take it on faith that an SOA will prove to be a revelation to their business, it would seem to be in vendors’ best interests to explain simply – but in substantial detail – what an SOA means to their business, or failing that, industry. Why should they should care. Why this is different than similar sounding promises they’ve heard before. Etc.
We’ve taken a stab at this approach with our free Compliance Oriented Architecture publication. We do of course have all the requisite SOA technical jargon analyst-speak in there (no analyst publication is complete without it) but it goes beyond simple technical arguments for an architectural approach. We’ve described what we see as component services (and invited others to add what we missed for the benefit of everyone) for a particular business problem – compliance, in this case. In simple terms, we’re trying to make an argument for SOAs that technologists will appreciate, but that business people can identify with as well.
The jury’s still out on how successfully we’ve done that – although initial feedback has been very good – but irrespective of the architecture we’ve put forward, I think SOAs will have a difficult time getting mainstream traction until we as technologists can better explain to the business person why they should listen.
Anyone disagree?
UPDATE: Grammar.
