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.