The Perfect Store: Inside eBay

February 25, 2008

Author: Adam Cohen
ISBN: 0316164933


Books about the history of the major players in the Internet and technology space are a light read and most even manage to be mildly entertaining. The things you learn are not likely to help you at your local quiz night but there’s often one or two things you can take away. In the case of Ebay, two things stand out.
1. The power of community.
Ebay was part of the original dot com boom and is seen by most as a Web 1.0 company. Now we have Web 2.0 – which is basically used to describe the growing popularity of social networking sites and sites hosting user generated content. Ebay survived the dot com meltdown, and maybe it’s because it saw the future.Ebay made it’s “community” a key part of its business – often consulting them on major business decisions (and on occasions backing down on decisions made without consultation). For many people Ebay was not an auction site – it was their social network and their entertainment. Ebay recognised this and actively encouraged it. In return people willingly donated their time to help run the business. This meant that Ebay didn’t have to hire paid employees to do the work and it also meant that people formed strong bonds with Ebay, making them unlikely to switch to a rival site.Clearly it pays to build a community spirit around your company or its products and services.

2. The ‘Network Effect’. Throughout its short history Ebay faced a number of challenges from larger rivals with deeper pockets. It managed to fend off these competitors by virtue of the ‘network effect’. The network effect is a phenomenon whereby the value of a service increases as more people use it. In online auctions, sellers want to use the site with the largest number of buyers and buyers want to go to the site with the most sellers. More buyers mean better sales prices and more sellers means more products to choose from. It’s as simple as that. And is the reason why Ebay is likely to remain the leader in online auctions for a while yet. Ebay had to build its network but it did so when there was little competition. Today, competitors have the daunting task of building their network by convincing Ebay users to switch.

It’s important to note that ‘community’ and ‘network effect’ are not the same thing. Ebay is not alone in capitalising on the network effect, other Internet companies such as Skype and Paypal also understand the value of a large network. But these companies do not have a ‘community’ as such and it’s these two concepts working in tandem that have given Ebay its lead in the online auction space.


What Is “Best Practice” Anyway?

February 22, 2008

IT is changing at a phenomenal rate and at times we struggle to make sense of the vast array of tools, technologies, architectures, patterns, methodologies that are at our disposal. Sometimes we just want to be told the ‘right answer’. Product vendors, standards organisations and various consultancies are only too happy to assist. Enter the best practice guide. Sometimes it is easier to let someone else do the thinking – but those that fall into the trap of blindly following ‘best practice’ without critical analysis could be doing their clients a major disservice.


“Imitation is the sincerest form of collective stupidity.”
– Bill Munro, Marketing Director, PepsiCoWe often hear the term ‘best practice’ but has anyone actually paused to think what it actually means? Most people would say that ‘best practice’ means using technology, techniques and methodologies that have been proven by an industry to produce desirable results. Or words to that effect.I’m a huge believer in the concept of best practice. Knowledge sharing is vital and we need a collective body of knowledge which everyone can contribute to and use. That said, I think we need to scrutinise the concept of ‘best practice’ a little closer.Although he probably never used the term ‘best practice’, the father of the concept was probably Frederick Winslow Taylor, who revolutionalised industrial production in the early 1900’s. He said that there is “always one method…which is better than any of the rest.”That may be true if you’re running a assembly line producing widgets – theoretically you could take all the variables out of the equation and create a standardised and repeatable process. But the same cannot be said of the modern business and IT world. There will always be variables such as:

  • the skills and experience of people involved
  • the organisation itself (culture, politics, role of IT etc)
  • the infrastructure you have to work with
  • resources (in particular time and money)
  • and many more

When reading a best practice guide it’s important to understand the context within which it applies – no best practice can ever be universally applicable to all situations. At the very least you need to understand:

  • who is giving the advice
  • why did they write it
  • what real world situations has it been tested on
  • who is the intended audience

Anyone that blindly follows ‘best practice’ without understanding these basic things could potentially being doing their clients a disservice. For example:

Looking back instead of forward.
Best practice is honed and developed over a period of time and so it follows that it is backward looking. On some projects you want to minimise risk and stick to what the industry knows. In some situations though you need to blaze a trail. Just because something isn’t best practice doesn’t mean that it is inferior or inadvisable.

Over-egging the pudding.
Many might think that the terms ‘best practice’ and ‘fit for purpose’ are at opposite ends of the ‘quality’ spectrum but sometimes real ‘best practice’ for a given situation is whatever achieves the desired outcome for least cost and in the shortest possible time. Hold the trimmings!

Failing to properly assess alternatives.
Many times I’ve seen situations where ‘experts’ hide behind ‘best practice’. The answer to everything is always ‘that’s best practice’. It’s a way of shifting responsibility. If it works out – then great. If it fails in a particular situation its not their fault. They recommended ‘best practice’ – its used everywhere and if it failed in one organisations it must mean there’s something wrong with the organisation not with the approach. Rubbish. All they have is a hammer and as the saying goes, they see every problem as a nail.

Failing to understand the BEST in ‘best practice’.
What do we mean by the word ‘best’ anyway? Do we mean the quickest time to market? Cheapest? Latest technology? Best performing solution? Easiest to maintain? Least moving parts? Most secure? Easiest to maintain? Most future-proofed? What exactly?

Having said all that, I’d like to make it clear that I’m not advocating completely ignoring best practice guides and always going it alone – potentially reinventing the wheel or repeating mistakes others have made. The point I’m making is that you need to critically assess the advice – use as much “best practice” as you can and rely on your skills and experience for the rest.

One final point, if you do deviate from best practice it pays to be clear in your mind (or even document) the reasons for that deviation. Could you justify the deviation to group of your peers? Sometimes there is a temptation to ‘just get on with it’ and do it your way rather than taking the time to understand what someone else has done. That is NOT a valid reason for deviate from best practice.


SOA Is Not EA 2.0

February 19, 2008

If you’re looking for insightful comments or ideas then give this post a miss.

Part of the attraction of having a blog is you can have the occasional rant. It would be naïve to think that anyone reads (much less cares about) these rants – but putting things in writing is a cleansing experience that everyone should indulge in every once in a while. So here goes…


I hate the term “Web 2.0”. I couldn’t think of a more meaningless moniker. The Internet is not versioned. It’s not twice as good as it used to be. Not twice as big. And living in Australia I can tell you it’s not twice as fast. Sure, a range of new uses and applications have sprung up but it’s still the same Internet.Not sure where the term originated but I assumed it came from newly minted ‘new media’ business school graduates. Since I’m not in the “assumptions” business I thought I’d try and find out for sure. Seconds into my quest I came across a site that wa explaining how to create web site template for a Web 2.0 sites. After I stopped shaking my head I decided that in this instance I’ll go with my assumption and call it a day.For reasons I cannot comprehend there seems to be a “SOA vs. EA” mentality developing. With SOA billed as the relevant fresh young upstart and EA the old, stale has-been. It’s as though SOA is trying to crown itself “EA 2.0”. OK, maybe a little farfetched. But not much.

Thinking about it, there are some similarities between the Web 2.0 phenomenon and the SOA movement:

  • SOA has brought ‘architecture’ to the masses – much like Web 2.0 gave millions of people new reasons to use the Internet.
  • The huge publicity/hype of SOA and Web 2.0
  • Both SOA and Web 2.0 are nothing new – they are a new take on an old concept.
  • Depending on who you ask Web 2.0 may also be called Bubble 2.0. The SOA trend is displaying bubble-esque characteristics and it’s only a matter of time before it hits the “trough of disillusionment”

These are just a few off the top of my head – you may be able to think of more.

I don’t know where this “SOA vs. EA” idea came from but everyone in the enterprise architecture field needs to nip this argument in the bud. There is nothing to be gained from us arguing amongst ourselves in front of ‘The Business” about who is right. Surely we’re smarter than that.

SOA and EA are not competing concepts. They are complimentary – each one feeds into the other. SOA is not “next generation EA”. It doesn’t replace EA anymore than Web 2.0 will replace the original ‘Internet’. SOA is a subset of EA. It’s that simple.

Hopefully in time people will stop talking about SOA and get back to talking about “architecture”. For me, that day cant come soon enough. I wouldn’t mind if “Web 2.0” disappeared from the lexicon either.


The Project Portfolio Approach to SOA ROI

February 18, 2008

Erich Roch proposed an interesting approach to calculating SOA ROI, which he called the ‘portfolio based ROI calculation’. This approach “analyzes a set of candidate projects for ROI project by project and adds up the cumulative value of SOA across these projects.”I think approach is a great idea and I’d be keen to hear from anyone that has used this approach in practice – especially if you can help answer some of the questions below.


I recently read an excellent post by Erich Roch entitled SOA Costs and ROI. He proposed a very interesting method of calculating ROI which he called the “Portfolio Based ROI Calculation”. Actually he proposed a few interesting methods (so please read the whole post) but this one grabbed by attention.In a nutshell this approach:

“analyzes a set of candidate projects for ROI project by project and adds up the cumulative value of SOA across these projects. Part of IT’s strategic plan is often a project portfolio that has cleared corporate ROI hurdles and been approved by the organization. These projects are ideal candidates to analyze SOA ROI potential.”

Intuitively, this seems like a great approach to calculating ROI but I think a few questions need answering.

1.Is this approach still feasible if a portfolio of projects DOES NOT exist?
In my mind, the ideal scenario for employing this approach is when a portfolio of approved projects already exists. This is because:

  • Someone has already done the ‘leg work’ in terms of analysis, planning and costing. All that is left to do is evaluate how the use of SOA will improve the project ROI. This should be relatively easy to do. And quick.
  • You will in effect be proposing to take existing projects which are already attractive to the business (since they were approved) and demonstrate how they can be improved even more. More benefits. Same (or less) cost. Better ROI. This is as close to a ‘free lunch’ as you’re ever likely to get.

However, I think this approach loses its appeal when a portfolio does not exist. Sure we can create one, as Erich suggests, but creating an entire project portfolio just to calculate ROI seems like a lot of unnecessary work. It probably makes more sense to look at the key business drivers and strategic plans and propose ONE project that has an acceptable ROI, and concentrate on planning/costing that one.

2. Is this approach just for the “big boys”?
The vast majority of organisations only have one or two projects in the pipeline – probably not enough to calculate a compelling ROI. Strategic plans or roadmaps will exist but the candidate projects listed in these probably won’t be costed until just prior to them starting. So this approach probably only applies to very large organisations – who probably have a portfolio of fully planned/costed projects large enough to make a meaningful ROI calculation.

3. How are you going to convince project sponsors to alter their already approved plans?
If you want to revisit/alter projects have been approved and have “cleared corporate ROI hurdles” it may be difficult to answer the question foremost on the minds of project sponsors: “what’s in it for me?”. The project funding is available and the sponsor has publicly committed themselves to delivering the specified project outcomes by the completion date. They might be reluctant to tinker with something they have already committed to and the organisation is happy with.

4. How do you reconcile the uneven distribution of costs/benefits of the projects within the portfolio?
By taking a portfolio view you will be faced with an unequal distribution of costs/benefits for each project within the portfolio. For example, one project might benefit greatly from adopting an SOA approach and another one might suffer slightly. The cumulative effect to the organisation will be positive but how do you convince the sponsor of the second project to ‘suffer slightly’?

5. In practice how would you go about plugging the gaps in the portfolio?
Erich says:

“In addition, given key business drivers, there are often gaps in the project portfolio where a business need is not or can not be addressed due to technology barriers. These barriers may be eliminated using SOA. Such new projects that address strategic goals can be calculated for ROI based on corporate metrics and added to the SOA project portfolio for a total ROI calculation.”

So you might have a situation like this:

Project Gap

Depending on how big the gap is, you could have a situation where a project devised solely to fill the gap is not worthwhile. However, there may be a potential project that fills the gap and offers excellent ROI – but it may overlap other projects:

Project Gap Filled


As the diagram shows, the overlap might be minor in one project but significant in another. Either way, you would again have to alter existing/approved projects.


Trying to Sell SOA To The Business? Don’t Bother.

February 15, 2008

There is absolutely no point selling SOA to the business. They just don’t care. But if you think SOA is a good fit for your organisation there is a simple way to bring SOA in: sell a solution to a business problem that happens to use SOA as the solution’s architecture.


I.T. people are not salespeople. They are hopeless at writing persuasive proposals, worse at delivering compelling presentations and most haven’t even heard of the 30 second “elevator pitch”. I.T. people don’t speak the same language that business people speak, be it words or numbers. If you observe the often comical ways in which I.T. people try and sell SOA to the business you’ll see what I mean.There’s only one thing I.T folk need to know about selling SOA to the business:

Don’t bother. They don’t care.

Aside from the fact that I.T. has a credibility problem when it comes to promoting the latest and greatest idea, business people only care about things that are ‘visible’ to them. SOA is an architecture. It’s a mindset. It’s a design principle. It’s a lot of different things to a lot of different people. But it’s also an abstract concept – you can’t see it or touch it and it doesn’t ‘do’ anything. It means nothing to business people. SOA is a lot like Total Quality Management (TQM) and 6 Sigma of yesteryear. You can’t see or touch ‘quality’ – but in time you can see the results of implementing a quality programme.

So, if you think SOA is a good fit and you want to “do SOA”, how can you go about introducing it into your organisation? Here is five tips.

Tip 1: DO NOT sell the hype.
The “everyone is doing it so we should too” argument is absolutely the wrong way to go. Firstly, this statement is blatantly false – everyone is talking about it but very few are actually doing it, and even fewer are doing it in large scale production environments. Secondly, when things go wrong, it won’t be “everyone” that will be asked for a ‘please explain’ – it will be YOU.

By all means share industry success stories – but don’t ever commit to achieving the same results. Remember that for every publicly available success story there will be many privately hidden disaster stories.

Tip 2: DO NOT sell the technology.
You’d think this goes without saying, but my experience tells me otherwise. If your argument is “if you look beyond the hype, SOA technology is actually very cool” then you’re still missing the point. Techies may think its cool. No one in the business will. To business people ‘SOA’ is just another TLA (three letter acronym). Forget the jargon. Forget the technology. It only confuses people.

Even if business people did listen and understand the technology aspects of SOA, be aware that one man’s “cool” is another man’s “risky, bleeding edge, here today gone tomorrow fad.” Don’t expect everyone to instantly share your enthusiasm.

Tip 3: DO NOT sell features or benefits.
On the face of it this may sound a bit controversial but let me explain.

Proponents of SOA point out the many benefits that an organisation could gain by implementing SOA. The key word in that sentence is could. SOA allows you to do many things but so what? A salesman might point out all the great features of a new television set – but all those features are irrelevant if I’m looking for something to keep my food cold.

Going to the business and trumpeting all the great things we can achieve with SOA is like saying: “I’ve got this great gadget! It does this, this, this and that. Are any of those things of any use to you?” This is the proverbial solution in search of a problem. We’ve got to do better than that.

The business is not interested in all the great things you can do – they’re only interested in what you can do for them. You need to go beyond providing a checklist of features and benefits – you need to apply them to solving real problems in the business.

Tip 4: DO sell business outcomes.
Don’t expect business people to make the jump from features/benefits to business outcomes. That’s the job of the person writing the proposal. Let me illustrate.

The Solutions Architect in an organisation wants to propose a project for integrating the warehouse management and order processing systems. He’s done a proof of concept and has worked through the major technical issues. He’s ready to take it to the business. In his proposal he explains that he’s done a proof of concept. He explains that the project is relatively low risk and that it can be done relatively quickly and cheaply.

Then he pats himself on the back and waits for the inevitable approval. After all, why would anyone knock back a low risk, cheap and quick project? But the proposal is rejected. Like most I.T. people the Solutions Architect is not a good salesman. He expected the person reading the proposal to understand the implications of integrating the two systems. They didn’t. No matter how low risk, cheap and quick a project is, it will never be approved if the person reading the proposal is scratching their head trying to work out what’s in it for them.

A better proposal might say something like: “integrating the two systems will allow us to have a real-time view of our stock situation, which should prevent stock outs and reduce the number of customer complaints”. You need to stress the business outcomes: less stock outs and reduced complaints.

Tip 5: DO NOT mention SOA or bend over backwards to accommodate it.
When proposing your solution resist the urge to put the ‘SOA’ label on it. The business pays Architects to provide solutions using industry best practice – so do it. Whether the solution is SOA or something else – there’s no value in trying to label it.

It is well known that I.T. people like to tinker with the latest technology. Given the hype surrounding SOA, the business might think (not unreasonably) that you proposed SOA because it’s the “in thing” and you want to be a part of it. It’s that well worn phrase again: the business might think all you have is a hammer and you see all their problems as nails.

Finally, don’t get too carried away – SOA is not the solution to all problems. If you bend and contort your solution to try and make some tenuous link between the problem and SOA – savvy business people will see through you. And if they don’t – sooner or later you will have to explain why you chose to fix a leaking tap by replacing the entire plumbing – instead of spending few cents on a new washer.

So there’s five tips for getting a foot in the SOA door. Of course – the same tips apply irrespective of whether your proposed solution is SOA or something else.


I.T. Has to be About the Bottom Line

February 12, 2008

During my years in the IT industry I have seen very little progress towards the goal of I.T. and business alignment. Despite the fact that both sides accept the ever-increasing need for it, each side continues to accuse the other of not “getting it”.

The I.T. industry as a whole is getting better at doing what it does but still it struggles to improve its reputation in the business community. I started thinking about why that is. The answer turned out to be relatively simple. With a few exceptions, I.T. continually fails to live up to its potential of being a source of competitive advantage and having a positive impact on the bottom line.

As an industry we have positioned ourselves in a no-win situation. We can continue to do things better, cheaper and faster – but it will never be good, cheap or fast enough. We will always be a ‘cost of doing business’. Unless we reposition ourselves.

My premise is simple – true ‘business-I.T. alignment’ will not be possible until I.T. has a positive impact on the bottom line. And I don’t mean a ‘smaller negative impact’. I mean a positive impact.

Nobody ever talks about alignment between sales and marketing for example. Although they are distinct functions they are so closely aligned that people often talk about them as being one and the same. The reason for this close relationship is simple: they depend on each other. They cooperate to each ones mutual benefit. The ultimate benefit being money – profits, pay packets and bonuses.

A similar relationship doesn’t exist between business and I.T. Sure, both sides need each other but the relationship can’t be characterised as symbiotic – as it is in the case of sales and marketing.

The irony is that I.T will only have a positive impact on the bottom line if it aligns itself with the business, but at the same time this alignment won’t happen until I.T. has a positive impact on the bottom line. The classic catch 22. But we have to start somewhere. Small wins and incremental steps will build momentum.

After all, when all is said and done…

I.T. has to be about the bottom line.