Infovark

So what are you guys actually doing?

Gordon and I have heard this question a lot lately. Friends, family, and former coworkers have all asked us. We’ve been cagey so far, mainly because we weren’t sure we could bring all our ideas together and make them work. But we reached a major milestone last weekend: Our core API now passes all of our unit tests. Now that we’ve got a solid foundation in place, we can see how the rest of the structure fits together. So it’s time to start talking about what infovark is all about.

In one way or another, Gordon and I have worked on enterprise software systems throughout our careers. We’ve built them, implemented them, sold them, trained folks to use them, and provided technical support for them. And if there’s one thing we’re both sure of, it’s that “enterprise software” today is an unmanageable mess. There are a lot of reasons for this, from battleship gray syndrome to dysfunctional procurement to poor change management techniques. Also, good intentions aside, the analysts and vendors don’t always help the equation either. So we’re throwing the old approaches away and starting again.

The main problem with enterprise software is that it’s targeted at an ill-defined customer: the enterprise. The enterprise is not a single thing; it’s a collection of things. It’s the people, policies, practices, strategies and culture that together comprise an organization. Most business software is targeted at the policies, practices, and strategies, but there’s really only one item in this list that matters: the people. Everything else is an emergent property that arises from the interaction of people.

In my time as a management consultant, I was “the flowchart guy”. My job was to produce elaborate wall-spanning diagrams of the procedures and processes that our clients followed, so that we could see points that could be improved. I sweated over these diagrams; I interviewed people, watched them work, and took pages and pages of notes. I developed a detailed knowledge of how all the pieces fit together. After several weeks of drafting and revisions, I’d present these works of art to our customers.

Most of the time, the charts that I made were reviewed with surprise. “Oh, that’s how it all works!” was one of the typical comments. Then I’d begin pointing out areas where improvements could be made. I was usually disappointed with the outcome of those meetings, because the most common result was to roll up the detailed diagram I had so labored over and file it away, never to be seen again. Business carried on as usual.

Years later, I’ve come to realize two things about those diagrams.

1. Our clients didn’t need my flowcharts in order to operate a successful business. The procedure manuals weren’t guides that workers referenced in order to do their daily tasks; they were merely descriptions and distillations of corporate know-how, written long after employees had figured out what needed to be done. The companies managed to function even though many had no idea how their internal processes actually worked.
2. Flowcharts bear the same relation to an enterprise as the Platonic ideal of The Circle does to a wheel. It’s an abstract model that never truly exists in the real world. An actual wheel is very rarely a perfect circle, and in some cases a perfect circle would be less effective. In the case of the wheels on your car, you get better traction if the tires flatten out on the bottom, to put more of the wheel in contact with the road.

Traditional enterprise software typically looks at the structure, policies, rules and norms of a business and codifies them into software. It tries to build a functioning real-world system from abstract principles. At best, this approach creates a short-lived tool that works only as long as those practices remain the same. But in many cases, the practices change all the time because the business environment changes all the time and the people that comprise the organization change all the time. It’s like the old proverb: you can never set your foot in the same river twice. Even if an enterprise solution could be precisely tailored to meet your businesses needs today, tomorrow is a new day.

Incidentally, this explains why most enterprise software has eight zillion configuration options. It also explains why you need a team of experts to implement an enterprise system. You’ve got to take that idealized flowchart and make it real. You’ve got to tweak the settings so that it matches up with the way the business actually operates. And here’s the dirty secret of enterprise software: you’ve got to keep tweaking it. You can’t just bring in a team of experts to set up the system initially; you’ve got to make sure the system continues to align with the way you do business. That means you’ll be reconfiguring the system all the time. When you buy one of these systems, you’re buying it for the long haul, and you can expect significant and ongoing maintenance, training and configuration costs. And that’s a best-case scenario. A worst-case scenario is that the system actually stands in the way of getting the job done. It will limit the flexibility of your knowledge workers to try out new approaches. When your business needs to change, you’ll be stuck with a rigid program designed for the way your business operated at a single point in time, several years ago.

So if we can’t design enterprise software to capture those ineffable emergent properties like “best practices” or “corporate culture,” how can we design these systems? We have to go to the source: the people that comprise the organization.

If you watch a bunch of kids on the playground at recess, you’ll notice patterns and order emerge. Groups will form, ideas will be shared, norms and rules established. These things happen naturally. The same is true of enterprises, businesses, organizations and associations. If you want to get enterprise software to work properly, you’ve got to focus on the interactions of the individuals involved. If you want your employees to share information more effectively, find out what would motivate Bob to share his weekly sales figures with Mary. Construct the system from the ground up.

We’re doing this at infovark by building an information handling tool that solves key issues for today’s knowledge worker. As a consequence, it encourages practices that benefit the corporate community as a whole. What we hope will emerge from this approach is a transparent, open culture of communication and collaboration.

I still haven’t gotten around to discussing the specifics, have I? We’ll get to them in future posts, I promise.

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…