Bernard Wheeler's Weblog

Are we all missing an easy win here?

What's the clearest distinction between managers and leaders? This has been a topic of debate for many years, involving many people more learned than I in this subject area. However, having been in the workplace for over 20 years, I think I'm qualified to make some observations based on personal experience.

A piece of that experience that brought one of the key differences into stark relief for me was the recent CEC 2005 internal Sun conference, held in San Francisco at the end of February. This is where thousands of Sun 'technical' staff are brought together (pre-sales, proserve, tech support, engineering, technical marketing). It's an incredibly valuable part of Sun's cultural physiology, enabling people to a) feel that their value is noticed, b) get a broad picture of the “shape” of Sun and its internal emphasis on hardware vs. software vs. other innovation in the quest to solve customer problems, and c) listen to and exchange ideas, experiences, etc. with other like-minded enthusiasts.

One of the features of these conferences is that we get keynotes from various SVPs that are driving the key big sections of Sun. We also get “State of the Union” sessions from the people that are spearheading each person's particular technical community (the only time such a separation into "communities" is made). It was this collection of sessions that made the clearest distinction between managers and leaders only too visible.

That distinction? Inspiration.

As you'd expect (and I'd be worried if it weren't the case), Jonathan, Scott and Greg P all passed the test. They (individually and collectively) inspired a) faith in their ability to spearhead where Sun's going, b) confidence that we've got the right vision for where we're headed and c) enthusiasm to continue “doing the right stuff” because we're making great progress towards that vision.

However, some (but not all) of the other people in “leadership” positions (SVPs) would have scored poorly in an 'Inspiration Quotient' test. Now let me make two things clear:

1. I am in no way questioning anyone's ability to manage efficiently , to delegate, carry authority, or any such quality. I'm only talking about answering the question “Was I inspired by that?”

2. Sun is in no way unique in this profile. Most of the companies I have worked for would have a similar scorecard. (But that doesn't make it right.)

It's not just at conferences when this is visible: in a company such as Sun, where computing technology is a large part of its DNA, we get quite a lot of e-communications from the various leadership levels on a regular basis. And whilst they're typically concise and informative, “inspirational” is not a word that would normally spring to mind.

And this is where I think Sun (together with all those other companies) is missing a HUGE easy win.

Let's face reality: Sun (and a lot of the industry) is still in recovery mode following the burst of the dot-com bubble - but at least we're still here recovering. In my opinion it is exactly at this time when an inspired workforce can have a massive advantage over one that's ambivalent.

And they say that success is “1% inspiration, 99% perspiration”. My experience is that without the 1%, you're highly unlikely to get the full 99%. The question is: who's ensuring that the inspiration happens?

For Scott and Jonathan it happens as a matter of course – and to my mind it's no coincidence that they have their current roles. Others may have to focus a bit more to make it happen, but it's worth the extra work. What I'd like to see is for the next 6 months every communication out from VP level (at least SVP) and higher are checked before sending for their 'inspiration quotient' – the answer to the question “would this inspire me if I read/heard/saw it?”. If it fails, that communication needs to be re-thought and re-presented.

But why stop at VPs? (Well, they should all be doing it, because they're getting paid to perform leadership roles.) People in customer-facing roles (especially sales and pre-sales) would also do well to check whether they're inspiring their customers. You'll probably find that there's quite a link between the level to which they're inspired and how happy they are.

And why stop at 6 months? Well, we needn't stop then. But 6 months of just ensuring that inspiration is being spread daily, weekly, should see a marked difference. And if not, what's been lost – how much will it have cost? Less than a free puppy, that's for sure.

So if you ever catch yourself wondering whether you're doing the best that you can for your company (or your family for that matter), go inspire someone. You'll probably find it working on yourself too.

SOA = BOA ?
We all know the potential for something of value to be lost beneath hype, hype-backlash, bandwagon-hijacking, "not invented here" syndrome and the like. This applies as much here in the UK as anywhere else world-wide and I have a growing concern that some of the key points of potential value for SOA are starting to get obscured under some of these effects.

First things first: what do I mean by SOA. Well, the best analogy I've seen (and to my mind it is superb) was put forward by a fellow Sun employee, Thomas Limanek (who, as it happens, contributed to some of the ebXML specs).

Tom's analogy in a nutshell and extended here by my own whim is this (and apologies to Tom for any misrepresentations):

• the traditional relationship between business and IT is like having a personal chef: you (the business) can dictate what you want to eat, or take menu recommendations, but your chef (the IT department) only buys supplies according to the pre-agreed menu. You play no part in how the food is bought, cooked, etc., but you pay the whole cost for the chef, cooking fuel, food and all the waste from each meal. In addition, if you suddenly change your mind about what you want to eat, there's unlikely to be an alternative meal ready in a short time - apart from re-cooked leftovers.
  
  
• using commodity-off-the-shelf (COTS) software is more like eating in a restaurant: there's typically less flexibility available to you in the actual make-up of the dishes and the more customisation you want, the more it'll cost. But you share the costs of the chef, facilities, etc. among other restaurant-goers - reaping some benefits from the 'economies of scale' of the restaurant. Furthermore, if you change your mind about what you want just before ordering (e.g. pizza vs. pasta), there's probably a reasonable alternative that can be available in an acceptable amount of time. But if you want to include a totally different culture or flavour (e.g. vegetable tempura as a starter), you may have to visit more than one 'restaurant' and figure out for yourself the logistics of how the 'meal' as a whole is going to be achieved. Also, there's nothing to stop the restaurant from suddenly hiking up their prices, radically changing their menu, or being bought out by a bigger chain who then 'trashes' your preferred meal.
  
  
• SOA is like eating at a buffet: the chef (either private or shared) prepares a range of dishes from which you build your own meal. The meal you choose does not require the whole ensemble to be put together 'in the kitchen': rather, the chef focuses solely on ensuring that there is an appropriate range of dishes provided in the buffet to keep most people happy for most of the time, based on market demand, season (and other prevailing conditions), consumer feedback/requests/suggestions, etc. And if the cost of any item changes dramatically (or there's an ingredient shortage, "food scare", or some other reason to change a menu choice), you don't have to change your whole meal, just that one piece of it (although granted, it may be the centrepiece of the meal).
  
  

Hence the title of this piece (BOA = 'Buffet Oriented Architecture'). I think this is an excellent analogy, because amongst other things it helps to illustrate that:

1. a main thrust of SOA is business agility (consumer able to make their own selections) as opposed to IT agility (ability to respond to requests more quickly).
   
   
2. IT agility is important too - business won't want to wait as long for just one new component (dish, service) to be produced as they did for the whole 'meal' before - and their impatience will only grow.
   
   
3. there is a responsibility upon IT to offer a palatable and useful range of services, including 'staple items' that will be included in almost every selection.
   
   
4. some of the initial difficulties in migrating to SOA: if you just serve up the same stuff (food, services), but in a different form (buffet vs. a la carte, SOA vs. stove-pipe), the customer will wonder why the heck you bothered with the transformation. They just get the same end result, but they have to put more effort in too.
   
   
5. if you're exposing stuff into a "public space" there are various security, hygiene, monitoring, etc. considerations that you need to consider. Otherwise you'll get someone in off the street carrying a bowl, taking all of the olive, tomato and basil pasta, sneezing on the rest of the buffet and then walking out without paying. And you can't expect the consumers to choose or enforce these as options.
   
   
6. there is a need for appropriate granularity: you want to avoid the smallest portion size being a whole roast chicken.
   
   
7. for the more popular 'dishes', you'll need more capacity not only in production quantity, but also in the ability for people to access them.
   
   
8. if you want people to always have a specific item, you'd better mix it into each menu option you give, pre-load the buffet bowls/plates, or move to a "we serve you" buffet model (a 'halfway-house model, which means that you will need to factor in the hiring of serving staff, their cost, their throughput capabilities, etc.)
   
   
9. each dish can more easily be put under scrutiny - independent of all others - to isolate the efficiencies and difficulties of provision - is the volume such that outsourcing makes sense, does it take an inordinate amount of resource for the popularity and benefit it gives?
   
   
10. you cannot implement this without participation on both sides: if the business just (metaphorically) sits at the table demanding food and refuses to step up to the buffet, you're going to have an unhappy business (and frustrated culinary staff)
    
    

I think I could spend hours extending and exploring this analogy, but I think I've covered enough of the main points for today.

So what do I think is getting obscured? Well, the main issue is that people are routinely confusing business agility and IT agility. Sure, they're coupled, but potentially loosely so: you still need IT agility to create the new services in a timely manner, but if the business decides to change its selection list and create a new 'combo-special', its ability to do so need not be restricted by IT's ability to join all the stuff together - especially if you can achieve serve-yourself as opposed to we-serve-you.

And yes, I know I'm talking about 'utopia' here, but when else other than at the start of a paradigm shift is a better time to consider ultimate possibilities?

Another aspect that gets hidden is the fact that unless something measurably beneficial for the business is planned for and delivered along with the move to SOA, they will be supremely 'underwhelmed' by the achievement. "Same food, different delivery" is not going to cut it on its own.

So is SOA for everyone? Well, if the business is only ever going to order the same menu, you'd better find some pretty good reasons for selling the idea of a buffet rather than the 'served at your table' set-up.

I think that's enough for one day of blogging. And I'm starting to get hungry...