Design for consumers, not suppliers

By Andrew Clifford

Designing systems to meet the needs of your consumers is critical to keeping systems simple and effective. Sometimes this means ignoring the advice of your suppliers.

I'm building a Java-based web application. It works very well. But there are plenty of places where I just haven't designed it "right".

My design isn't really object-oriented. I have basically procedural code, dressed up as objects so it runs on Java. And I haven't taken advantage of the excellent frameworks available to build the application, work with databases, and deal with multiple user interface technologies. Anyone who knows anything about Java would wince.

This is not entirely the result of foolish inexperience. Each one of these has been a conscious design choice. Why?

Whenever you are producing anything, you are part of a supply chain. There are consumers of your products. In IT, this includes users; those who will integrate your systems into something larger; and support staff. And there are your suppliers. In IT, these are the suppliers of components and tools that you use to build your system.

I really admire the people who supply the programming languages, application servers and databases that I use. But I think there's a problem if we assume that the standards that they apply when they build the tools are appropriate for the rest of us when we use them.

My suppliers build sophisticated system software, and require sophisticated object oriented designs. Their components and tools have to apply across a wide range of uses. For example, they have to support many different types of user interface technology.

Most business-oriented software doesn't need this sort of sophistication and flexibility. A typical COBOL program, the traditional mainstay of business computing, is written using fewer than 20 verbs. Compare this with the 3000+ standard classes currently available in Java.

Business-oriented software obviously still needs to meet the needs of its consumers. Sometimes this means designing things "wrong", by the standards of your tool suppliers.

Our system has a relatively complicated database structure. Support staff are not best served by overlaying this with an object-oriented design. A relatively simple procedural design meets their needs better.

Our system helps manage quality in the long term, and so the system has to be supportable in the long term. We can only use products that fit within official Java standards. Reluctantly this means we can't use some of the excellent Java frameworks, because they are not yet part of the Java standard.

We want our system to have the widest possible reach on the web. So we put effort into making everything available in a plain web pages, with a stylesheet to make it look pretty. We didn't want the complexity of different code for different clients, even if it is produced automatically by a sophisticated framework.

Each of these design decisions is debatable. But my point is that there are times when we need to ignore supplier-defined best practice. If we want simple and effective systems, we should be less apologetic about our lack of sophistication, and worry more about meeting the needs of our consumers.

Subscription