This article is the third in a three-part series that explores architecture as it relates to the design of business software. Read part one, The Best Business Software Is Built through Human-Centered Design, and part two, Designing Business Software Is Like Building a House.
Too often, software is “designed” by professionals who have little information about the users of their products and no experience in prioritizing their needs or designing ways to satisfy them. The result is widespread confusion among those who use business software and intense frustration among the executives who approve its purchase. Well-informed buyers of business software who know exactly what they want nevertheless often find themselves unable to acquire the tools they need, and even executives who enjoy the luxury of being able to customize or build proprietary systems for their organizations commonly discover that a big budget and exacting business specifications won’t necessarily produce a product that people will use.
Assuming that a technologist can successfully select or build the software that is needed—without enlisting the help of someone who has the communications and design skills of an architect— works about as well as asking an engineer to build a house.
If you were to contract with an engineer to build your house, both the process and the result would differ substantially from your experience with an architect. The process probably would begin the same way. In your initial meeting, you’d be asked many questions to define the size, the style, and the functions of the house and to specify its features. Your engineer would leave with pages of information, and soon you’d probably receive a copy of the notes summarizing that meeting in the form of a tidy bulleted list: a two- story residence with four bedrooms and en suite bathrooms; two half baths; a kitchen and breakfast room; a living room; a dining room; a library; a gym; a deck; a two-car garage. Once you approved the inventory of basic features and the budget, you’d be given a schedule for completion. No problem, right? Wrong!
“Assuming that a technologist can successfully select or build the software that is needed—without enlisting the help of someone who has the communications and design skills of an architect— works about as well as asking an engineer to build a house.”
The next step might come many months later with a message notifying you that your house is finished—that it’s been built to code, and all the mechanicals have passed inspection. Everything works perfectly. Now it’s time for you to take a walk-through to learn how to operate the heating and cooling systems, the lighting systems, and the security system.
You’d probably be surprised by what you’d see. Suppose that your two young daughters have each been given a bedroom on the second floor, but they like to share a room, and neither of their bedrooms is large enough for two. Imagine that the dining room seats 12 comfortably, but you often host dinner parties for 20. What if no one had asked whether you have pets, and you’d been given a security system with motion detectors and a kitchen floor with an ebonized finish that shows every speck of dirt tracked in by your three dogs? Picture stepping onto a spacious deck that has no place to plug in an electric grill.
“Many companies struggle with software that doesn’t come close to meeting their needs because of small deficiencies and major misunderstandings caused by guesswork—problems that could have been prevented by asking more questions, by analyzing the answers, and by questioning assumptions.”
Of course, all this can be fixed. You can add an outlet on the deck, refinish the kitchen floor, modify the security system, cut a hole in one wall of the dining room to expand it, and build an extra bedroom on stilts off the second floor. In the meantime, you could make do: Run an extension cord from the kitchen to the deck by threading it out a window, disarm the security system, ask your daughters to squeeze into a tight space, and expand your dinner parties into the living room by setting up card tables. It would be awkward, but you could manage. In fact, you might decide that the inconvenience and expense of shutting down the kitchen to refinish the floor isn’t justified, and it makes more sense to just live with it and tolerate the necessity for constant maintenance. You might not even notice hundreds of smaller defects.
Many companies struggle with software that doesn’t come close to meeting their needs because of small deficiencies and major misunderstandings caused by guesswork—problems that could have been prevented by asking more questions, by analyzing the answers, and by questioning assumptions.
For more insights from Electronic Ink CEO Harold Hambrose, read his best-selling business book, A Wrench in the System: What’s Sabotaging Your Business Software and How You Can Release the Power to Innovate.