Photo by jared on Flickr used under Creative Commons
I’m convinced that innovation on the consumer side of the web is great for enterprise software.
I’m similarly convinced that innovation on the consumer side of the web is terrible for enterprise software.
Reading Marc Benioff’s post “The Facebook Imperative” on TechCrunch last week reminded me of these mutually-exclusive conclusions.
On the one hand, as Benioff points out, the consumer web has driven new methods for delivering software, i.e. the xSP model to make enterprise software more like Amazon.
Well before that, the browser was facilitating collaboration and distributed work within the walls of companies, as intranets and networked software applied the concepts of the WWW to their businesses.
And now, Facebook is completing the old question “why can’t enterprise software be more like blank?”
Obviously, the consumer web has driven major innovation into enterprise software.
It has also simultaneously driven complexity and cost.
What do I mean by that?
Imagine you have a piece of software that does one unit of work, and this unit of work is critical to your business. Along comes Facebook, and suddenly, everyone wants to add a social on top of this unit of work.
It’s a good idea because people do that unit of work, and sometimes they cannot all be in the same room. So, adding a social layer will help collaboration.
By deciding to add social, you’ll now need to determine how to do it. Usually, the decision is between build or buy. Assuming you bought the software initially, it makes sense to see if the vendor has an upgrade that will add social.
If they do, you can go with the upgrade, but that will require an implementation team and careful planning because you cannot disrupt the working software because it’s critical to your business.
Plus, once the upgrade is ready, you’ll need to retrain your users because it’s a good bet that the addition of a new feature has changed how the software works.
If your original vendor doesn’t have the social layer you want, you’ll need to find a vendor that has what you want, and you’ll want that vendor to support some level of integration with the existing unit of work because the social layer will only add value on top of your existing software.
Many companies turn to analysts at this point because analysts know who offers what and have compared vendors to each other. They’ve done the legwork already.
Whether it’s produced by the analyst or the company, a request for proposal (RFP) typically follows. The RFP goes out to vendors who reply with their capabilities.
Software companies want to earn business, natch. So, once new items begin to appear on RFPs, e.g. social, they will need to answer, which leads to the development of features.
On the development side, you can’t avoid complexity by streamlining and removing features, or if you do, you do so at your peril. Facebook can redesign and remove features with impunity because their users don’t pay to use the service.
Enterprise software is obviously for-pay, and as much as you might like to be like 37 Signals, you really can’t expect to keep customers if you remove features they use.
What choice is there? If you don’t add new features, you won’t win business. If you don’t win business, you go out of business.
Once a vendor is selected, the implementation begins and typically follows the same path as an upgrade. It might take a bit longer due to integration testing with your existing software and new training for users.
Pretty involved process. Compare that to switching social networks or joining a new social network in the consumer world.
So, making enterprise software more like Facebook drives complexity, by adding features, and cost, by requiring new software.
Just like making enterprise software like Amazon did and making it more like the Internet and more like a PC did before that.
So, you can see the juxtaposition of good and bad here. That’s why I always say that software is hard.
The key is balancing innovation with complexity.
Thoughts?
Twitter Comment
Software is Hard [link to post]
– Posted using Chat Catcher
Oh, Jake, if only it were as easy as you describe it. Let me explain. (To reduce confusion, I'll take the examples that I normally encounter when responding to RFPs and recast them in social terms.)
In reality, by the time you get to the RFP creation process, you have a number of stakeholders creating the RFP – and they don't always agree. Perhaps there is, as you suggest, some decision-maker who wants to introduce Facebook-like features into the software. At the same time, there's another decision-maker who believes that users should have a level of control over the UI, kind of like MySpace. At the same time, a third decision-maker thinks that the ability to broadcast short messages is key, kind of like Twitter. Meanwhile, a fourth decision-maker, noting the importance of location, decides that it's very important that people be able to “check-in” and specify a location, kind of like that Foursquare thing.
As you can guess, the resulting RFP is, to put it kindly, unwieldy. There are contradictory requirements – one says that messages should be limited to 140 characters, another that message should be unlimited in length. One requirement says that the software must comply with a particular state privacy act for minors, while another says that geolocations must always be logged at all hours of the day.
The example that I provided is not too far-fetched. I have run into cases in which a customer wants to have the best system around, and the best way to do that is to take the best features of several different systems and combine them into a single system. (And there are often multiple stakeholders, thus increasing the complexity of the final RFP.) However, since no one offers a system that meets all of the customer's criteria, all potential bidders will have to commit to some level of development. And there are cases in which the resulting feature set has some inherent contradictions, but if you take exception to some of the requirements, there is always the danger that your competitor will claim 100% compliance and win the business.
And there's always the buzzword danger. My first job out of college was with a provider of general purpose software for the THEOS operating system – word processor, spreadsheet, etc. I remember running into a potential customer at a trade show that loudly insisted that the software had to be integrated. Why? Because Lotus 1-2-3 was the rage at the time. It didn't appear that the customer had a use case for how the integrated software would be used, but that feature was still essential. While there are obviously organizations that think about how a feature would be used before incorporating it, I'm sure that there are also organizations that are designing internal messaging software with a 140-character limit just because you-know-who does it this way.
Twitter Comment
Software is Hard [link to post]
– Posted using Chat Catcher
To be clear, I've streamlined the example for ease-of-use and sanitized it to avoid judgement, but as you say, the process of buying software is rife with politics, in-fighting and checklist-driven development.
Even so, my easy example is still pretty complex 🙂
Yep, replaced salesforce.com with integrated vendor provided webbed CRM middle of last year. Sorry Marc, sorry Oracle, you're both losers in this space.
Still dealing with user retraining, though, partly 'cause I haven't migrated the core ERP to web yet. But at least those users will be trained when I do. (Actual problem is web version uses completely different security which means a whole lot of administrivia work where management rightly doesn't want to propagate errors from old system, ERP code runs unchanged in thin client or web as long as you don't customize incompatible features. I sometimes still run things in character mode 'cause I'm a server-kinda guy, one or more fewer layers of problems). I don't really see how social can help core functions – IM, email, voice don't need tight integration, just availability. Ability to spit out a message has been there for years, as has b2b (though actually implementing b2b is one of the sillier old-timey tasks I've done in a long time – but I sure can't see replacing it with a wall – “hey, gimme some product” “hey gimme some money!”,”hey look at this link, amazon is cheepa!”,”yo mama is cheapa!”).
And the RFP's that lead to new stovepipes – well, are they core functions? Sometimes. And sometimes they fail miserably. I just can't believe how clueless some developers are out there, on top of what John described. Other times (like a store portal implementation I've been watching evolve and helping interface), they're sorta OK because they work, but in so many ways basic transactional logic is plain done stupid. Sorry, I'm a longtime db geek, and it just pains me to see it. And hurts a little more when I have to fix the data, where if they just did it right…
Wait a minute, you said switching social networks… http://www.wikihow.com/Permanently-Delete-a-Fac… doesn't sound so easy to me…
Yes, deleting your Facebook account isn't easy, as compared to something like, falling off a log, but compared to an enterprise software implementation?
Your story (and John's) remind me how clueless most of the mainstream tech blogging is about the fun of enterprise software. Granted, it's not sexy and not as many people care, but it's interesting.
Yes, deleting your Facebook account isn't easy, as compared to something like, falling off a log, but compared to an enterprise software implementation?
Your story (and John's) remind me how clueless most of the mainstream tech blogging is about the fun of enterprise software. Granted, it's not sexy and not as many people care, but it's interesting.