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)
In a recent post, Gordon talked about deploying Enterprise 2.0 tools in an emergent way. But what about the software itself? What characteristics make software emergent?
Emergence can mean several different things. The classic definition is that something has emergent properties when simple interactions lead to complex results. It usually carries with it the notion of repeated interactions. While you generally hear it used in a positive sense, as in “the sum is greater than the parts”, in can also lead to negative effects, as the designers of the Tacoma Narrows bridge discovered. Emergent doesn’t necessarily mean unpredictable, however. Many fractals have emergent repeating patterns but can be fully described by simple mathematical or geometric operations.
As a buzzword, emergence is often paired with social media. (Probably because geeks have a hard time with the idea of limited social interactions leading to complex group behavior.) But it’s true that sometimes a team can accomplish more than individuals acting alone. And it’s also true that rational individuals can get swept up in a mob, or fall for an investment bubble. Or that a short document listing founding principles can lead to a complex, multi-layered government system.
Writing software that exhibits emergent qualities is both very easy and very hard. It’s easy because there’s not much to program: Put your handful of rules in place and ship the product. But it’s also very hard, because once your audience starts working with the software, they may discover things you never intended.
Companies making computer games often release patches to tweak game mechanics, balancing the game so that no opponent has a greater advantage. Supporting a massively multiplayer online game requires constant monitoring to keep the experience just right. I think those of us writing emergent software for the enterprise could learn a thing or two from these games. If you’re interested in being an emergent software vendor, you can’t think like a manufacturer of shrink-wrapped boxes. The old programming joke becomes reality: The software isn’t done until the last user dies. You are an important part of your user community.
It also provides added incentive to avoid feature creep or featuritis. After all, if simple interactions can lead to complex behavior, where will complex interactions take us? Adding unnecessary features can add clutter to the interface, confuse users, introduce bugs, and ultimately cause unintended errors. All of which will drive your customers to adopt a smaller, cleaner product that does just what they need.
Most of all, writing emergent software requires a new attitude. The traditional way of thinking about software programs is that they are the means by which a user instructs a computer what to do. It’s a common trap that software companies fall into because that’s the way their programmers interact with computers. But the goal of your customers is not to tell the computer how to do things, but simply to get things done. The fewer instructions a user has to give the computer to get the job done, the more responsive and intuitive the program will feel.
To write emergent software, you have to shift your focus from the user interacting with the machine to people interacting with other people.
Jim McGee has a well worth reading post about emergence and its importance in enterprise 2.0. He contends that:
“In some respects, “emergence” is a fancy organizational development word for “messy.” The more our systems must deal with the complexities of the real world, the messier they must be to accommodate that messiness.”
There’s definitely some truth to this. Part of the appeal of these “2.0″ technologies comes from the fact that they are easier to adopt and less rigid. The innate flexibility of tools like del.icio.us and flickr is an important part of their acceptance and appeal. Billy Cripe also weighs in with his idea of where to find the ROI in Enterprise 2.0:
“Don’t be a hammer looking for a nail. Someone “implementing Enterprise 2.0″ is either too high up to understand what problem is being solved by a particular approach or simply wants to impress with the latest buzzwords.“
Both of these points got me thinking about how best to define emergence and Enterprise 2.0. In order to fully understand this notion of emergence within the enterprise, I thought it might be worth taking a look at a few different models of “Enterprise Software” and how this concept of emergence affects their ability to actually improve the way that an organization functions. As an example, let’s take the following enterprise:
Figure 1: An enterprise of people with no necks.
This typical organizational hierarchy consists of various layers of management and knowledge workers performing tasks. Some of those tasks require software that is only used by specialist teams. For example, an ERP accounting system like SAP or Great Plains requires training and subject matter expertise to use effectively. Systems like these are a critical part of the modern enterprise, but they aren’t emergent, nor are they designed to be emergent. There’s not much, if anything, that additional flexibility, or ‘messiness’ can bring to this aspect of an enterprise. (If del.icio.us only allowed me to bookmark my favorite financial transactions, I doubt it would have the same appeal…)
Figure 2: Adoption of an ERP tool within an enterprise.
So we probably aren’t going to see things like Great Plains, or SAP Financials implement a bunch of Web 2.0 features (unless they get really caught up in fad-thinking).
However, not all enterprise software works like this. There is a class of enterprise software that requires that it be adopted by the whole organization. Because of my background, I think automatically about Enterprise Content Management, but the same is true for groupware like Notes or Outlook, and to a lesser extent, for collaborative systems like eRoom or SharePoint.
Let’s use the ECM example. In any organization, people have systems for managing content. Most of them suck, because they are messy, ill defined, inconsistent, and often made up on the spot. So far, the only approach to solving this has been to implement a new, improved, well defined content management system. Of course, this only really becomes effective if you can implement it across the whole enterprise – otherwise you’ve just added yet another method of managing content to a messy, disorganized enterprise. So the goal for something like ECM is this:
Figure 3: The Ultimate Goal of ECM (that’s what the E is for)
Anyone who’s tried to deploy an ECM system to an enterprise knows that this is no easy feat. In fact, I can’t think of a single enterprise where this is true. (Although I’m willing to entertain the possibility that one may exist. Maybe some of the ECM Bloggers like James and Laurence can set me straight.) In my experience, most efforts at deploying ECM within an organization end up looking like this:
Figure 4: What lots of “Enterprise” Rollouts really look like.
How did we get here? The system was sold to someone in middle management with purchasing authority, who encouraged his direct reports to use it, and maybe they did, and maybe a couple of other teams somewhere along the line jumped on board, and maybe Harold from Accounting moved teams to HR, so he uses the ECM system properly, even though his colleagues still plonk everything onto a share drive… and so on. You get the picture.
This is precisely the problem that Enterprise 2.0 can solve.
The traditional approach is to build something autocratic, and deployed from the top down, that works along vertical reporting lines. Working this way, silos of information are preserved. and communication is kept within the traditional areas.
The emergent approach is work from the bottom up, in a manner than allows the system to spread virally along horizontal functional lines. By making the system less restrictive, and easy to use the system is more likely to become the solution of choice for knowledge workers. And as they communicate better, they share information and increase their awareness.
Figure 5: An Emergent system, on the path to Enterprise 2.0 domination
It’s very elegantly explained by Euan Semple, discussing the quickest way to ‘do Enterprise 2.0′:
“Do Nothing! And then your bright, thoughtful and energetic staff will do it for you. Trouble is they will do it outside your firewall on bulletin boards, instant message exchanges personal blogs and probably on islands in Second Life and you will have lost the ability to understand it, influence it, and integrate it into how you do business.”
So, in an enterprise context, does ‘emergent’ have to mean ‘messy’?
I don’t think so. For a system to be emergent, the emphasis needs to be on how quickly the users will adopt the system rather than on its structure. That explains why a hallmark of these Web 2.0 technologies is that they are accessible and less restrictive.
I don’t think this notion necessarily precludes systems that offer a traditional structured approach to enterprise information, but it does mean that if your notion of “best practices” don’t ‘t fit perfectly with your users are actually doing, you will find that your enterprise solution won’t emerge very far at all…