On lightweighting in enterprises

This time I can’t blame Sig alone, I have to include Malcolm and Dom and Don Marti, and their comments and posts over the past six months. Last night I meandered back to Don’s seminal post of many months ago, on Lightweighting, which I covered here.

Seeing the comments on my post last night, and thinking further about it, I felt it was important to try and understand exactly why lightweighting and opensource and agile programming and social software all have such roll-water-uphill problems in enterprises. They seem to share similar problem characteristics. Again, there’s a lot of rich literature on the subject, so I shall concentrate on just one small perspective.

The power of perception.

When you tell someone that their phone is now also a camera, they have no problem accepting it. They can pick it up and play with it and see that it has a Ronseal about it, “it does exactly what it says on the tin”. It is real to them. [An aside. I am definitely growing old. I cannot for the life of me figure out why someone would want a television display embedded into the facade of their refrigerator. Shades of reading Powerpoint on BlackBerry there….]

When you tell someone that their satellite TV is also a DVD rental shop and a video recorder, they have no problem accepting it. They can fight over the controls and delete unwatched recorded programmes accidentally to their hearts’ content. It is real to them.

When you tell someone that their PC is also a music player and a TV, they have no problem accepting it. Despite all the problems of DRM by accident and by design, they remain relaxed about the experience. In fact, given the traditional reluctance in households to learn anything about setting and operating VCRs in the past, they probably feel some familiarity in experiencing the failures. The experience is real to them. [An aside: I have been singularly uninterested in live TV on a computer, only in replays, and only of snippets and clips.]

I could elucidate more examples, but I think these are enough to underpin my simple point. It’s all about perception.

The examples all include some level of process redesign and innovation, some level of lightweighting, but they come packaged with hardware. And the hardware is real, people can touch and feel it. So the experience is real to them.

When it comes to software, particularly enterprise software, the touch-and-feel aspect is harder. True, we are seeing a move towards the purchase of appliances, where the hardware and software are integrated. But the appliances tend to get embedded in the “infrastructure’. And infrastructure hates lightweighting.

So how do people perceive value in software? Four ways:

  • Lots of new hardware
  • Big project/licence expenses
  • Large teams
  • High pain of adoption

Notice I carefully don’t state “People perceive value in software by seeing the measurable business value generated by usage of the software”. This-Page-Left-Intentionally-Blank.

Software becomes real to enterprise people through one or more of these things. When it comes to opensource, to process lightweighting, to social software and to agile programming, we have a problem. And if anything, the continuance of the laws of Moore and Metcalfe and Gilder exacerbate this problem. [An aside: is that why Bloatware is so successful? I wonder]

The problem is that the software isn’t perceived as real unless one or more of those perception triggers are set off. And we don’t want to set them off.

So what’s the solution? I have this uneasy feeling it’s going to be about hardware, especially when you look at the iPod phenomenon.

I think we are going to see all these things embed in enterprises over time: lightweight processes, opensource software, social software and agile development methods. But it may take a new generation of hardware and of platforms before that happens.

People buy the overall experience, like they buy cars. When we have desktop platforms which use opensource software as their basis, that come with agile programming and social software as standard, that support the lightweighting of processes seamlessly, it is then that we will have lift-off.

Our challenge then may become isolated to the design and architecture of these hardware-plus-firmware-plus-enabling-software platforms, concentrating on the user interface and look-and-feel and simplicity and convenience and usability and interoperability. Customers want to be able to touch and feel what they buy, and perceive value through the pain of acquisition. People like us want to reduce the pain of acquisition and adoption, but we’re taking away some of the ways customers perceive value as a result, and making our jobs harder.

I am reminded of Christensen’s Innovator’s Dilemma discussions with respect to Britannica and Encarta:

People did not replace Britannica with Encarta, far from it. They replaced Britannica with a home PC, spending a similar amount of money to assuage their guilt, but getting Encarta wrapped in. The PC was real to them. Encarta was a useful by-product, a Trojan Horsed entrant to their home.
So if we want to embed lightweight in enterprise, we may need some heavyweight Trojan Horses.

19 thoughts on “On lightweighting in enterprises”

  1. Oh this is such an important insight! As prospective providers of software built on an open source platform, and delivered as a service via the “lightweight” Internet, I now realize that our struggle for customer adoption is more than proving the value proposition – it is a struggle to change perception of what software is!! And I also resonate with the observation that hardware is the key. On that note, I begin seeing Amazon’s S3 and EC2 in a new angle – of providing the much needed infrastructural “weight” to emerging web-enterprise service companies like us. Ah these are exciting times indeed!

  2. I think you are spot on with respect to what Amazon are doing. Glad my post sparked something off in you; it’s not what I write, it’s what you read into it that matters.

  3. As an outsider I’d suggest the solution would be to change the “enterprise people” who would appear to derive their ego-juice from revelling in overcomplexity and the concomitant gatekeeping role that this grants them.

  4. Do people still use Britannica or Encarta now? I’ve had the CDs for some time now, but last time I reinstalled my Windows PC (bit-rot!) I never got round to reinstalling them, and can’t say I’ve missed them. Google + Wikipedia generally come up with the goods, in an even lighter weight version that comes free with the internet. Life is just too short to go through that installation hassle, especially when you know the software is going to try to stick its files in the C:\ directory, try to reinstall Acrobat Reader V3.0 on top of the latest version, mess around with your multimedia settings, ….

    Having said that. I might be tempted on occasion to use a zero-install CD. Such as a browser-based CD encylopedia. Or a Virtual Machine image. Or a Portable App http://portableapps.com/ on USB or CD. Or in enterprise space, a live CD or VM image of the entire application which you can use on any suitable hardware.

    So my crystal ball gazing says the integrated appliance view is just a short-ish measure which will prop up the perceived value, but which will in turn be replaced by a lower-cost zero-install software bundle. And the more successful bundles will support pre-selected options (“any colour you like”) and will be cheap enough that you replace every couple of years.

    So the car analogy changes; the hardware is more nearly reduced to the choice of fuel type (petrol or diesel or hydrogen); the software bundle, its design and feel, correspond to the valued item that you buy. And perceived value is perhaps greater if you have it in your hands, but the trend is to web-delivered, mass-market, nearly free. Lightweight indeed.

  5. Andrew, that’s why the Amazon S2 and S3 routes get interesting. Like yesterday’s ASP became today’s zero install web service, yesterday’s appliance may mean today’s web-service-startup scaling up on day zero with the “infrastructure” of a Google or an Amazon.

  6. “So if we want to embed lightweight in enterprise, we may need some heavyweight Trojan Horses.” – you got a point there… must repackage my “30 megs” onto a mammoth server-box or something..

    On the other hand, what if it does not come cloaked in the same wrap, does not pretend to be the same, just being something not to take too seriously, under the radar – and let time work until it actually replaces the Encyclopedia Britannica?

    Once-upon-the-time, E-mail was not introduced by decree from the top management (they didn’t even know what it was), and never claimed to replace other communication methods of the day. Ditto with the forerunner of blogs, newsgroups, nicely under the radar of top management again while blowing apart old powerstructures among the users…

  7. I agree with you, Sig, but I wonder whether I’ve been looking at the wrong thing. Maybe Exchange and Outlook really got embedded when they were seen as part of Office, even if they weren’t, and Office embedded because it was seen as part of Windows, which was seen as part of the PC.

    In earlier replies to comments I touch on the Amazon and Google plays in this area. Maybe the Trojan Horse is when “the desktop” is a thin layer in the enterprise, with lightweight process applications using opensource stacks and an infrastructure provided by the new players.

    The challenge is to avoid the interlocking of the layers when we seek to do this.

  8. JP, the one thing I wish to draw attention to is that list of yours about how people perceive value in software (and I must admit that this has not come up in any of the eight responses on record as I write this). Correct me if I am wrong, but it seems to me that those items all reflect the VENDOR’s perception of value. What I am getting at is that, except for “pain of adoption,” this is no consideration begin given to the CUSTOMER’s perception of value.

    Now, in all fairness, I think that this is a problem that has plagued the IT industry for as long as there have been customers. The history of the industry is richly populated with jokes and/or horror stories (sometimes both) stemming from the underlying fact that the vendor never really “got” the customer’s idea of value, usually because existing processes of “requirements analysis” could never address questions of value in ways that the vendor could then translate into design specifications. In that respect I think that your thesis about perceiving value “through the pain of acquisition” is an attempt to retrofit the “mystery” of the customer’s idea of value to the unfortunate legacy of requirements analysis.

    I agree with those who argue that the only way out of this legacy is to begin engaging with the customer BEFORE acquisition enters the picture. Where major enterprise projects are involved, this is often a matter of intense ethnography; and, unfortunately, most vendors are not interested in that kind of up-front investment. For the broader base of consumers, I see such engagement as necessary for any market research that will yield useful results; but I suspect that my voice is still out there in the wilderness! I do know that, in the latter case, problems inevitably start with faulty assumptions made by the vendor when the product is still in its infancy. I like to call those the wouldn’t-it-be-cool-if problems! If vendors were more aware of the customer’s sense of “cool” than they were of their own, I do not think we would have to debate a concept like “pain of acquisition!”

  9. Stephen, I was speaking from an enterprise perspective rather than a vendor one. That’s why the Stockholmers could exist, for example.

    On the other hand, if you abstract it to the right level, the biggest IT vendor in the world, probably by orders of magnitude, is the in-house IT department.

    So you have degrees of vendor and supply chain participant and “strategic partner” and outsourcer and bodyshopper and agency and all that jazz.

    The behaviours I characterised are based on a quarter of a century of watching enterprise decision-making in action, not from a vendor perspective. Though I must admit I have seen many enterprises where this decision-making is actually carried out by the dominant vendor and bypasses the “IT department”. But these are less common now.

    I’m not so sure about your analysis of the pain of acquisition. I think it is a function of how change happens in an environment, the pushback is from people who resist changing the processes.

    And that creates one of the worst nightmares possible in enterprise software. Where you buy an off-the-shelf (-ish, anyway) product and then mangle it beyond recognition during the implementation process. What you land up with is neither fish nor fowl. It does not have the economies of scale of being an external cookie-cutter, and it does not have the deep domain knowledge and (hoped-for) lower maintenance costs of the in-house development.

    This tension between build and buy used to be fun to watch, and even made economic sense occasionally. Now what we tend to have is illegitimate offspring from that coming together.

  10. Hmmm-
    * Lots of new hardware
    * Big project/licence expenses
    * Large teams
    * High pain of adoption

    JP,
    I agree with your list of enterprise perception triggers. There may be a meta-reason that connects all of the above – empire-building.

    IT depts are frequently out to protect next year’s budgets and the above perception-triggers help them to do that. And also to create a perhaps-false sense of security about the IT dept’s utility to the org.

    Let’s face it, if you lightweight, almost anybody can set up basic enterprise IT requirements.

    It’s easy to organise a secure Linux or mixed Lin/WIN Lan, and use only free office-ware and Mozilla/ T-Bird etc. There is very little pain of adoption, negligible cost and little need for licensing. Your broadband service provider and webhost etc, will help you configure the messier bits of the system and if you push for it, you can easily outsource maintenance.

    But then, where is the raison d’etre for the IT dept?

    It may not be articulated but this will be a significant barrier I suspect to enterprise lightweighting.

    In a lightweighted environment, the IT dept has to carve out a new role and reluctance to do that is perhaps where the rub may lie.

    In a different way, I’ve come across corporations, which have replaced the internal e-mail system, by and large with a twiki.

    This seems to work brilliantly whereever I’ve seen it in operation -it cuts down on the garbage ccs while ensuring that everyone is in the loop and contributing, strategising, etc, on key projects.

    But the concept of an office Twiki causes shock and horror in a paranoid enterprise because a paranoid office tends to ratchet up the fear factor by working through selective e-mail lists.

    So, it is resisted strongly by the senior (non-IT) executive in the classic Indian workplace because limiting others’ access to information (and to Sethji) is considered a key factor for advancement.

    The perception problem is caused precisely by the fact that its an open, transparent system and enterprises are by definition, not.

    There. that’s my two-paise (hilarious given that I’ve been unemployed for 10 years!).

    Devangshu

  11. Hi JP,
    came across the blog in ZDNet and felt the need to contribute to this particular article. The enterprise lightweighting is happening without a doubt, where we are on the evolutionary scale of it across the many varied enterprise types or whether the dinosaurs are about to be obliterated by the google/amazon play remains to be seen. The two companies I have been in recently (Investment Bank and Telco) are about 5 years apart in terms of their development (the IB 5 years ahead, just in case!).
    I struggled for a long time to figure out what the main difference for the lag, initially I thought it was the skillsets and attitudes of the developers, but after digging deeper I found the same core mentality when people are given the freedom.
    The main factor I found was within the community that comprised Vendors, Buyers, System Integrators and sometimes customers. There isn’t the same requirement to trade and open up the communication channels so that through sharing the industry matures, leaves the detritus behind and everyone benefits.
    But the times they are achanging, dramatically and many of the points you raise are resonating as the industry wakes up to the behemoths beating at our door.
    Which leads me nicely on to the other factor the “active/lazy/dumb/smart” categorisation of people within a company. Found it courtesy of a powerpoint by Christian Mayaud http://www.mayaud.com/PPTFCTE.htm (page number 101). This now replaces the “hero or villain” pub game. What categorises the best mix at the minute in the lightweight enterprise is a few “Active Smarts” with many “Lazy Smarts” (the people that find the easiest way to get something done), what I think many enterprises have at present is too many active dumbs (the worst by far) and a majority of lazy dumbs. And I have to add that this is across IT and business at present.
    Anyways, has been a great read.

    Rory

  12. JP, I agree that the in-house IT deparment is, at the right level of abstraction, the biggest IT “vendor” in the world. However, I am less concerned over whether a “dominant vendor bypasses the ‘IT department'” and more concerned about whether or not that IT deparment thinks about the “customer satisfaction” of “the rest of the house.” The problem of the IT deparment that either does not know or does not care about the core values of the rest of the organization has been around at least as long as there have been IT departments: The first time I saw the problem well articulated was by Robert Townsend in UP THE ORGANIZATION (1970). My own work history oscillated between laboratories doing contract research for the government and corporate laboratories. In both of the corporate settings in which I worked, there was a serious disconnect of value between the IT community and the business operations of the organization. My analysis of the pain of acquisition is based primarily on my experiences at those two organizations. I would be happy to extend that analysis further on my own blog and then furnish you with the pointers as I progress!

  13. Hmmm…so the best way to sell enterprise software is to make it big, impenetrable, requiring an oil tanker to get it going (and be just as agile) with features you’ll never use and a nose-bleed price tag.

    You forgot one thing JP – hyperblowy PowerPoint demo by sharp suited sales team where expectations are set in the stratosphere.

    That explains the success of certain ERP vendors don’t you think?

  14. Hi Rory, glad to see you’re about and active. Will read the link you’ve posted, thanks.
    Stephen, look forward to the pointers as the conversation on your blog develops.

    Dennis, you know exactly what I mean :-) I would only add a small proviso:

    “make it SEEM to be big, impenetrable, etc etc”.

    It doesn’t HAVE to be any of those things. That way we all win :-)

  15. So true and this is especially painful for those on the product development side of an organization. Those building great new things want our great new thing spread far and wide and tend to adopt social technologies for this purpose as they are the latest tool in the bag for today.

    Often the instinct to control and restrict is not merely an IT phenonmena, many times in an organization two groups will unite (say Marketing and IT) in order to deepen the control and restriction.

    My team undertook a project to create a community site for our product that allowed us to communicate with our customers, our customers to communicate with each other and opened access to everything we were doing. Its quite a successful product and this portal has been amazingly well received and was implemented in a matter of weeks rather then months or years, is self-maintaining for the most part and creates a critical mass that I see throughout our global customer base as I travel around to evangelize and meet with customers and partners. This was done outside of the IT/Marketing organizations as our customers were DEMANDING openness and we wanted to provide it. You can’t argue with success and our philosophy was that we would be rogue, allow our community to make it a success and thus give it a lease on life. This is exactly what happened.

    The Marketing/IT response? That its a great stopgap move but they are working on the new sales portal (based on SAP and currently 1.5 years behind schedule) that will enable partners to login and see relevant marketing content. That this new portal will be the most fantastic thing ever and consume all other content and community sites. When it gets here and the budget is allocated. In the meanwhile planning for the eventual arrival of budget and delivery has been ongoing for over a year.

    They miss the c0ncept from the cocoon of information ownership and misperception of what value really is as defined in your posting. This portal will fail for all of the reasons we are familiar with.

    So therein lies the trap, with this eventual failure comes an instinct on their side to board our vessel and ride out the storm. The spirit of openness and sharing dictates that we allow them to board, shower them with hospitality and teach them our way.

    But their directive is to board, control and restrict. In fact they are already doing this, using their Silo based control over content to enforce ‘standards’ and complaining about random buzzwords, buzzwords that compel the Marketing and IT juggernauts to move into ‘panic restriction mode’.

    After thinking long and hard I’ve decided to let them come aboard and have confidence that my shipmates can whether the chaos that these new guests bring along, also safe in knowing that for us another ship is always easy to be had and taking solace in the fact that the ship does not represent our knowledge and thus that information does -not- go down with the ship.

  16. I once went to a talk given by Jared Spool, mainly because we grew up in the same community, but he had a lot of interesting things to say about user interface design. (There is an interview by InfoDesign with him
    here.) The concept I remember most vividly was his description of “affordances”, which are cues that help people to know how to use something. Because a cellphone camera has a visible lens, people know which end to point. The visible lens probably isn’t strictly necessary from a functional viewpoint. Jared’s example of this is how at one time the door handle for his refrigerator was put on the “wrong” side. Guests couldn’t figure out how to open the refrigerator, and his child delighted in showing them how, but pulling on the edge of the door opposite the hinges.

    I think that most software doesn’t help people using it, and a lot of current GUI design is based upon conventions that once people know, they use, but this is basic mechanics. The web browswer was an excellent example of a software tool that is incredibly usable, because it feels “natural” to use. Learning time for me was basic compentency in seconds, mastery over a course of a few trials. Typical office software, some of the more user friendly software out there is much harder to learn how to use.

    Typical enterprise software is even worse. It isn’t obvious to people, it tends to be bloated, pulling in duplicate functions that other software can also do, but cannot because of artificial boundaries between data and systems. Things that people find useful: e-mail, world wide web, chat, blogs, wikis – are simple, single purpose applications that most computer literate people know how to use.

Let me know what you think

This site uses Akismet to reduce spam. Learn how your comment data is processed.