Categories
- Benefits (5)
- Company News (40)
- Enterprise 2.0 (107)
- Information Management (23)
- Keep It Together (8)
- Product Announcements (36)
- Productivity (15)
- Software Development (31)
My wife Alison occasionally asks me to remember stuff for her. Just yesterday, she said, while we were out “Remind me to ring the bank when we get home”.
I nodded amicably.
As a general rule, this probably isn’t the best way for her to retain a piece of information. I’m easily distracted by shiny things, I routinely forget stuff, and as much as I’d like to, I can’t assure her that I’m actually going to retain the information.
Worse still, I’m almost certainly going to give the same response to every request (an amicable nod) regardless of whether I’m actually going to remember it.
If you want information to be retained outside of your head, you should really write it down. Paper records of information are much more reliable than memory for recall. This notion of recording and managing information is central to the way people work. Since we started Infovark, I’ve had to manage more paper than I ever have before.
If you’re a knowledge worker, chances are that managing this information is essentially all you do. You write messages and documents, you go to meetings, you visit customers, you coordinate with coworkers, you take notes, and you use your brain to make decisions based on all of that stuff. It doesn’t matter if you are working in an industry or a more creative pursuit, you’ll still find your share of forms to fill in and documents to submit.
Computers changed the way enterprises work, because information artifacts that were once recorded on paper started to be recorded digitally instead. This saved space, and sometimes time, and often made it easier not to lose things. It also had two other advantages. First, paper can only be in one place at one time. It has to be physically transferred from one location to another, and generally moves at the speed of a truck. It’s far easier to move electronic bits around and they travel at nearly the speed of light. Second, it’s expensive and slow to duplicate information on paper. Making electronic copies happens at much faster rates and is such a trivial operation that computers do it all the time, usually without you knowing about it.
At first, enterprises thought that storing a record on a computer was a thing. It made sense at the time since disk space was at a premium. Our legacy thinking meant that we treated business artifacts as much the same, regardless of the medium (ink-on-paper or bits-in-transistors) that it was stored in. An enormous amount of time and energy was spent on implementing elaborate control systems to conserve disk space, just like we used to fret about running out of space in our file cabinets or bookshelves.
Nowadays, disk space is cheap. A 500 Gigabyte drive costs $99 at the local MicroCenter. As Nick Galemmo notes over on ITtoolbox, the same amount of storage in 1980 would have cost around $250,000,000. So if there’s one thing that we can afford to do with modern computers, it’s store stuff.
One of the defining trends of Enterprise 2.0 systems is that they store stuff. They store stuff regardless of whether it is finished, or a “proper” version, or a snippet of a comment, or a draft. They store the same thing multiple times, often in multiple places. They record silly things like employee blog jokes, and wiki pages that nobody will ever look at again. They capture recklessly.
Reckless capture is the concept that led Google to its position today. It’s what Sharepoint does with all those team meeting spaces. When in doubt, store it anyway.
At first this might seem frivoulous — wasteful, even. But in addition to storage, one other thing that computers could do well is separate signal from noise. And when it comes down to it, what you want from your system is answers, not efficient use of space. You want tools that help you make decisions. Get things done. Connect with people.
A lot of the reasons for the surge in virtualization technology comes from the fact that a lot of servers in server rooms all over the world are underused. They are super powerful, with loud fans and scary blinking lights. They live in their big, cold, antiseptic server rooms. Do you know what they are doing? Most of the time, not very much at all.
So, let’s capture as much of these information artifacts as we can. It’s not going to hurt the bottom line, and it can only help productivity. After all, nobody ever found a useful document lying around on a network share and complained about wasted disk space. Let’s give those massive servers something to do.
That reminds me, I gotta remind Ali about something…
While we’re defining our terms, let’s think about the word “collaborate” for a moment. For the etymology buffs, collaborate has its roots in Latin. “Co-” is a prefix meaning “together” or “jointly.” “Labor” means to work. So to collaborate means literally “to work together.”
It sounds easy enough. People have been working together for thousands of years. It’s an essential skill we’ve developed since humanity’s earliest days in primitive hunter-gatherer societies. You’d think after all that practice, we’d be quite good at it.
Yet you might be tempted to draw the opposite conclusion after looking at all the software tools aimed at fixing collaboration problems. If collaboration is such a simple thing, why is there so much noise in the enterprise market about it? It isn’t because the human race has suddenly become antisocial. It’s because most of our existing computer hardware and software has all the interpersonal skills of an idiot savant.
The vast majority of office productivity software got its start in the PC era, from the early 1980s through the early 1990s. During this period, the predominant office technology paradigm was to have a computer-to-employee ratio of 1:1. Also during this period, linkages between computers were rare while linkages between people were common. Thus was born the concept of sneakernet. Sharing and communicating information was a human task; storing and processing information was a computing task. The PC’s of that time were little more than advanced pocket calculators.
What’s remarkable is that that the mindset has persisted into the Internet Age, where linkages between computers are often more constant than the linkages between people. Our computers are used for much more than information processing and management. They are now tools for communication and self-expression. As such, they can become social objects in their own right. But it will only happen if we in the tech industry can get the interface right. Just as in real life, appearances matter and bad behavior is noted on the permanent record.
The buzz around collaboration technologies means that the software industry has noticed that the thing we do most with our computers is work with other people. The first generation of enterprise software got things wrong by trying to gather the data together while keeping the people apart. The next generation of software may very well do the opposite, by bringing people together while keeping the data separate.
This idea is at the heart of the infovark solution. Everybody has their own ideas, thoughts, documents, and messages. Some of these need to be shared with others. We want to enable that communication in the most natural and seamless way possible, without impinging on other coworkers’ space. We want to find and retrieve only the most relevant items, rather than distracting employees with useless data. We want people to collaborate as they always have, while allowing the computer to track, process and manage the information that results from that collaboration.
Collaboration is not new. It’s at the center of every business enterprise. What’s new is the emergence of software to enhance that collaborative experience.
There’s a change blowing through the dusty confines of enterprise software. Even establishment figures such as Bill Gates and Robert Scoble have begun criticizing it. Then half the tech blogosphere joined in. The alternative appears to be “Enterprise 2.0″, but what does that really mean? It’s time for us to have a go at defining this nebulous and controversial term.
Oh, Please…
Lots of people are uncomfortable with the phrase Enterprise 2.0. (The wikipedians are in a state of constant merge/don’t merge.) For the progressive and hip, appending the “2.0″ to anything somehow makes it fresh and trendy and interesting again. I understand that. To the more pragmatic and cautious among us, however, it sounds like an over-inflated and hype-laden marketing fad. We want to avoid making big promises and then looking stupid later. Should we find another label?
Most of the complaints stem from the fact that both parts of the term are hard to define. I’ve written so much code lately, I immediately thought of it as an array:
String[] TheProblem = "Enterprise 2.0".Split(' ');
TheProblem[0] – Defining “Enterprise”
Dean and I currently use this as our working definition: An enterprise is a group formed to work on a task that is too big for one person to accomplish alone.
To us, it doesn’t matter if you are two people or 20,000; As soon as you find that you need to add a second person to get whatever it is done, your effort just became an enterprise. And no matter the size, a bunch of people gathered together without a job to do is definitely not an enterprise. (It might be a Facebook or Myspace, though.)
Both parts are necessary: You must have multiple people working toward a goal to qualify as an enterprise. If you’ve got those things, you’re the target market for the tools emerging under the Enterprise 2.0 banner.
TheProblem[1] - Defining “2.0″
When television broadcasts first started, people weren’t quite sure what to make of them. The new technology made it possible to beam entertainment into people’s houses, and so the broadcasters turned to existing sources of entertainment — theatre and radio. During The Golden Age of Television (1949-61), the most popular programs were adapted radio plays or live “telecasts” of Shakespeare plays and the ballet. They simply took old media and repackaged it in a new form.
A second wave of innovation occurred as people became more comfortable with television. They began experimenting with the new medium, trying different approaches to producing and delivering the content. Television programming branched out, fueled by advertising and new business models, and changing personal preferences. Existing genres spawned entirely new sub-genres and whole new forms of entertainment appeared.
The Internet has gone through a similar transition, in what Tim O’Reilly famously termed “Web 2.0“. This is the point where the Internet changed from being a publishing medium to an interactive platform. Like it or not, we all add content to the Internet now, not just companies, scientists and scholars. Just as with television, this new medium offers us new and different opportunities. Things like User Generated Content (Happy Birthday, Wikipedia!) are hallmarks of Web 2.0.
Back to our definition: The “2.0″ bit is about leveraging Web 2.0 tools for work. It’s about applying some of the lessons from the public Internet space to the smaller, private confines of organizations. Not all of the Web 2.0 concepts will make the jump to the “small cloud”. Some will be more valuable than others. As with all software, actual mileage may vary.
TheProblem.Join();
So there it is: Enterprise 2.0. If it helps, think of it as “Enterprise Web 2.0″.
As to this notion that Enterprise 2.0 doesn’t exist because there is no market, I call shenanigans. Businesspeople have spent money on trying to improve their organizations in the past. They will continue to do so. If Web 2.0 tools provide value — and we believe they do — they will start to permeate the organization, regardless of what you call them.
And to those who say “It’s just marketing hype“, well, is that so bad? Enterprise Software 1.0 is seen as boring, complex, and hard to use. It has a dreadful reputation among users, consultants and developers alike. Perhaps encouraging people to expect more from their enterprise software will drive us all to meet those expectations.
I can’t resist adding my own thoughts about making Enterprise Software sexy. (Gordon posted his comments yesterday.) But in the grand old tradition of Web Pages that Suck, I’ll do it by talking about the many things that make Enterprise Software drab, dull, and difficult to use.
I call it the battleship gray syndrome. No pictures, no icons, no colors, and no frills: It’s spare, utilitarian, industrial. When someone says enterprise software, I bet you think of something that looks like this:
But why? Why gray? I’ll let you in on a secret: If you’re working with an application done in battleship gray, you’re not working with a finished product. You’re working with a prototype. Perhaps it was a utility written by someone in your internal IT department to scratch a particular corporate itch. Perhaps it was built by an outside consultant for a fixed fee. Maybe it was sold to your CIO, who wanted something serious and functional and cheap. You got ripped off.
The two most important of frameworks for enterprise applications are still Microsoft Visual Basic and Java. Both have a handful of pre-built widgets and controls that developers can use to rig up a working interface quickly. Programmers love this because it’s so easy to get to a working application. When the pointy-haired boss walks by with yet another lame requirement from the luser community, Joe Codemonkey simply drags another radio button out of the toolbox onto the page and writes a little code to wire it up. No sweat.
And no design, either. There’s a reason these pre-built widgets are battleship gray: They’re neutral. When developing a prototype, developers often deliberately make the colors fonts and icons as neutral as possible. This is to get the stakeholders that review the application to focus on the important part of the software from the developer’s point of view: the functionality. Joel on Software has a great article about this called The Iceberg Secret.
The idea is that once the functionality is complete — the hard part as far as the programmer is concerned — there will be time to replace the generic rectangular text buttons with something a little flashier. In practice, this hardly ever happens because all software products run late. So most standard corporateware consists of feature-complete applications with prototype interfaces: The battleship gray syndrome.
There’s also a more cynical reason for the battleship gray syndrome. Because the look and feel of these applications is entirely neutral, it’s really easy for consultants and vendors to repackage them and sell them to a different client. It’s often how these companies recoup the losses they incur creating custom software. If a vendor spent weeks getting exactly the right color red into an interface for Coca-Cola and then had to redo the whole thing in IBM blue, they’d never make any money. It’s far easier to do the whole thing in battleship gray and swap out the logo in the upper-left-hand corner.
Good software developers might protest that it’s easy enough to replace the standard controls that ship with development frameworks with custom elements. But even if diligent developers took the time and effort to build or buy custom interface widgets, corporateware would still look dated. The reason is that style trends evolve much faster on the Internet than on an enterprise intranet. The Internet is a giant clearinghouse of design ideas. We can see what works, what doesn’t work, and most importantly from a developer’s point of view, we have access to the code that created it. Good design elements introduced on the Internet are rewarded by the sincerest form of flattery: they are imitated. By contrast, updates to the look and feel of most enterprise software are glacial by comparison.
Try this experiment: In the next enterprise software RFP your organization puts out to tender, include the requirement, “User interface must be beautiful, elegant, and intuitive.” Watch the enterprise vendors that respond jump through all sorts of hoops to get that requirement removed from the specification. Software vendors hate requirements like this.
Supposing the vendor’s sales guy is desperate for his commission and passes it off to the services team as an implementation issue, the vendor’s project manager will begin furiously down-scoping the requirement. Good project managers are on the lookout for subjective requirements like these. They’ve been burned in the past by customers that refused to accept the final product, so they’ll make sure that the requirements are discrete and measurable. They’ll try their darnedest to re-set expectations. They won’t accept a requirement like that on a fixed-price contract again. No way.
It’s not entirely the vendor’s fault, however; your own organization is partly to blame. Good design takes experimentation, iteration, and talent. That means high salaries and a time-and-materials contract. But you’re on a budget. Sure, the marketing guys can blow millions advertising to customers, but internal systems for employee use will never get that kind of funding. So as soon as you get something working, you accept the product and leave the design and usability bit for next year’s budget… or maybe the year after…
Which brings me to the last point, which is that enterprise software is dealing with a captive audience. Employees must use employer-provided tools, such as they are. In the consumer software market, an individual is always free to try something else. And with today’s Internet applications, the costs of switching are lower than ever before. Remember Friendster? MySpace? Despite the fact that consumers poured hundreds of thousands of man-hours into building up those communities, Facebook drew a huge crowd once it came on the scene.
Scoble fired a torpedo off the bow of enterprise software. He wants to sink the battleship gray syndrome. Judging by the response in the blogosphere, so do a lot of other people.
Our approach is to borrow whatever we can from the design lab of the Internet, applying those tools and techniques to the problems that face the enterprise. Our approach is to sell and market our software in a different way, direct to the knowledge worker. And our approach is to put design and usability at the forefront, rather than leaving it as a “nice-to-have feature” that we’ll implement “if we have time.”
The blogosphere exploded over the weekend with an exciting conversation about enterprise software.
The comments stem from Bill Gates, talking about the future of Microsoft, but the controversy was stirred up by Robert Scoble, who asked his readers how to make business software sexy?
Some of us who actually do this for a living took that to heart. Michael Krigsman attempted to explain the innate differences between enterprise and consumer software, only to be rebuked by Nick Carr:
“By perpetuating a false dichotomy between the friendliness of consumer apps and the seriousness of business apps, all that Krigsman is doing is giving enterprise vendors cover for continuing to produce software that’s difficult and unpleasant to use.”
But my favorite post so far came from SocialText’s Ross Mayfield:
“Enterprise software can do better. In fact it has to, because of broader competition. At least with basic usability. … Step out of the feature matrix. Also recognize that control instincts lead to unusable crap that is a barrier to collaboration. And every enterprise software app is a collaboration app, otherwise it’s infrastructure”
We all know a lot of enterprise software is horrible to use. It’s complicated, frequently counter-intuitive, and often requires extensive training.
Most people who use it daily don’t like it. They certainly don’t love it. Compare and contrast the following Google Searches:
“I love Facebook” vs. “I love Oracle E-Business Suite Financials”
We’ve talked about this a lot in the past, so I’ll try to keep this brief… How can we make enterprise software sexy?
Design it for People to use.
Enterprise Software is currently not designed for people to use — it’s designed to be bought by someone in senior management.
(Which is always good for the software vendors, but not always good for the enterprise, and rarely good for the people who happen to work there.)