Enterprise 2.0 meets business reality

This is the second in a series on Enterprise 2.0. In the first post, we looked at what parts of the "2.0" environment were on most CIO's agendas. This post looks at what is highest on a CEO's Agenda with respect to all IT, not just Enterprise 2.0. The reason for talking about this is that a lot is written about how wonderful Enterprise 2.0 systems are conceptually, but much less about how they will work in the actual ecosystems they will find in situ.

We love the Gartner Hype Curves - and you will note Enterprise 2.0 is still at the early hype levels, when, as Gartner puts it, it is in the:

"Peak of Inflated Expectations" (an irrational exuberance)
In this phase, a frenzy of publicity typically generates over-enthusiasm and unrealistic expectations. There may be some successful applications of a technology, but there are typically more failures.

They also point out that at this stage there is far more conferenceware than working software......

But, as a bunch of hard bitten guys who have actually put some of this stuff into companies successfully over the last few years (and have plenty of experience from Enterprise 1.0), humour us and allow us to opine from the digital coalface:

The chart below is recent (August 2007) and gives a fairly common view of a business's IT priorities today (and most days really):



Fashionable though the Long Tail is, its worth paying close attention to the "hit head" here, as that is what is perceived to be the most important, so these are the key hurdles:

- Enabling Business Growth - i.e focus on approaches to increase sales volumes and ARPU

- Integrating IT with the business - i.e. making IT do what the business needs it to do

- Improving IT service delivery - translation: this means making things work, not doing new things that don't

- Developing / Managing flexible technology infrastructure

- Demonstrating business value of IT

All very sensible if you actually have to run a business - so how does this impact the Enterprise 2.0 play (apart from E2.0 being primarily IT based). The last point pretty much says it all - any new initiatives, including E 2.0 plays, need to demonstrate business value - aka have a business case.

The lines above it give a good view of what that case entails - in a nutshell, does the business case (i) help to grow the business, (ii) use technology that is synergistic with what it has already, (iii) does what it says on the tin and (iv) doesn't go down a unique path and drive technology lock in.

So what does that mean when the CIO turns her beady eye on the hopeful Enterprise 2.0 purveyor? There are 3 big hurdles the E 2.0 vendor must jump - the "3I"s as it were.

Impact.

What does this do to drive sales, increase retention, reduce OPEX etc? Now at one level that is probably the easy part, all the Web 2.0 technologies have screenfulls written about their benefits. But there is a level below that question, i.e. what does it do that my current approach won't do well enough - and how much will this make things better by?

This is a bit harder...one has to move from belief to proof, to case studies and the like, or pilots that prove the concept. CIO's have had 40 years of hearing "trust me, it'll work". It didn't and they don't. If your company does not have a reputation for delivery, it means either you'd better be prepared to put in and support some form of (discounted) trial system if you have no reference sites, or you need your references pronto.

Another part of the Impact equation is Return on Investment Risk (ROIR). This has 3 components:

- What is the benefit?
- What will it cost?
- What is the risk if it doesn't work?

The cost (and risk) to an organisation of putting in any complex (ie wide reaching) system comes far more from the opportunity cost of the disruption caused than the actual cost of the software. Anything that minimises the disruption to the staff is greatly welcomed.

For these reason services that are Web Service based are an easier sell, as the CIO can see it up and running and also know that the impact risk on their organisation is minimised - so long as it can jump the next hurdle....

Integration

How does this system deal with the existing data, workflow, system design etc. In other words, know your niche - what systems are you likely to be sitting nearby in the ecosystem - and how do they work? It is extremely naive to think that any organisation will willingly hand over data for yet another silo to be created.

Now, before everyone wails that This Is Not the Point of Web 2.0, its worth going back a bit and asking "what was the point of Enterprise 1.0 and what were the lessons learned". The idea was to have deeply integrated systems, seamlessly operating together, and sharing common data. That it was hard to do, and had to be executed in large ERP and CRM packages was part of the "then" technology and learning, but the desired direction is more, not less integration at a data and infrastructure level. The point is that a Point Application that wants to create a nice little separate data base (potentially not even stored on the enterprise's architecture) is a harder sell at CIO level - deja view as it were.

To be sure, it is possible to sell point solutions at a divisional level, even better if they are Web Services (or SaaS if you prefer), but this is not the desired direction in any major enterprise play and is likely to bring any vendor into conflict with IT policy. By the way, they are not "out to get you" as some of the literature on CIO unreasonableness would suggest, but like parents contemplating a puppy for christmas, they know from bitter experience who gets to walk the dog every day.

What they will also want to know is "Is this a technical one way street with no future proofing?". Open Source is a major step forward, as are use of standards at all levels, and far better data import/export tools. In fact, the whole point of the ASP/SOA/SaaS/Next TLA movement is to try and make the data independent of the application, so if your stuff stinks they (the Enterprise) can haul their data off it and onto another one without missing a heartbeat. That is the endgame of Integration.

Assuming that integration is a surmountable problem, the next hurdle is good old....

Implementation

Can you deliver? Who is going to pick it up at 3am on a Sunday morning when it goes pear shaped? Is this secure? How do I reverse my position if your stuff sucks?

These are all Implementation questions.

We can all talk about the sunny uplands of Enterprise 2.0, of joyfully collaborative Wikis and customer-seducing Blogs, of widgets that delight and truly cool mashups - but what any hard bitten organisation wants to see is how the service traverses the rocks and bogs of actually making it work in a 24x7x365 production environment, where real users - busy, ham fisted, non techie types - are thrashing the sh*t out of your software on daily basis.

Guess what - this means user testing, adding robustness, testing for scalability, and so on and so on ad nauseam until you get it right and it won't fall over at 3am on Sunday morning.

Without a doubt, Enterprise 2.0 platforms such as Amazon's Cloud and Grid are a huge step forward over the ASP's of the 2000 era, and Open Source software is inherently a lot more reliable that the proprietary hacks of yesteryear - but this is not where it ends. In our experience the biggest issue we have come across talking to young startups, is their frequent inability to imagine the torture to which a service can be put through in a production environment.

It's no accident that new technologies are typically introduced into organisations "off the critical path" - into HR, front end demand generation etc - because the last thing anybody wants is to bring the Line of Business to a standstill. So to that end, the more stress testing a new application can be put through first, the more robust its initial infrastructure design, the better.

There is a corollary to this - no matter how sexy the Presentation Layer, any hard boiled enterprise crew will immediately want to look under the hood and see how it works. Why do you think Google's office suite had so few serious takers and they have had to build Gears?. Why have so few pure web apps been taken up in corporation sane? Its because people who live in a production environment know that if your app f*cks up it has all sorts of knock on effects - organisations are not just social networks, they are social networks with a purpose - to do stuff.

In Summary

The point of this post on Enterprise 2.0 (if you will excuse the slight rant-ish tinge) is to counterbalance some of the - frankly - over-hype over Enterprise 2.0. In Gartner speak, we are trying to get it off that "Peak of Inflated Expectations" and look at what it must do in reality to be useful and used.

Thus we are trying not to bury Enterprise 2.0 as it were, but not to overpraise it either - more to appraise it sensibly.

There is a very reasonable discussion to be had about using consumer based Web 2.0 tools in the workplace, as they can be much more powerful than the older business based ones - we would argue that this is true today for stuff that can be run behind the firewall (Wikis etc) and for point applications not in the Line of Business delivery (Salesforce.com is a good example here), and we will return to these issues in later posts.

In addition there is much to discuss on the impact of the reduced transaction costs of doing business that Enterprise 2.0 implies, as well as the increasing importance of the "Information Layers". We will also discuss what "Lean Enterprise 2.0" means.

But it needs to be put in context....there have been new "save the world" IT breakthroughs before, this is the next one, and there will be ones after it. Yes, there is a lot of merit in it, but it will sail - or sink - on the same practical issues that all the previous ones have - does it support the business objectives. In other words does it pass these hurdles:

- Impact

- Integration

- Implementation

Post-thought - in essence this is describing the "how" of the requirement to jump the "chasm" - the hard ground to cross between the prototype software that early adopters will use, and the more developed systems that are necessary to make it into the mass market. Consumer use is easy - you load it up, you drop it, no worries. It gets virusus - affects you, not anyone else (we hope) Using something reliably - and supporting it - across a whole network is much harder.

(In fact one of the biggest headaches of company IT support is the sheer amount of virusware, malware and other overall cr*pware that staff pick up when loading all the Cool New Apps on their laptops - Monday morning is always a nail biter in big companies .

Postscript - just seen this interesting article on Web 2.0 in Morgan Stanley.....it echoes a lot of the points made above, and akes the two Good Olde Points from software projects immemorial:

- Top Management support is essential
- large companies have incumbents (the name changes with the decade), its always a toss-up to use new startup or wait for incumbent to do it.