Coherency Design

A colleague and I were looking at an issue we call "coherency design" – a focus on ensuring that different stakeholders maintain a common vision of a product's value proposition, and that the different stakeholders' design solutions function together in a cohesive way. I shared the essay with a group of colleagues. The original essay and the unedited feedback are presented here.

Original Essay:

Who sits at a product design table? The product manager is usually there, software architects, system architects, maybe sales, maybe QA. Together, these designers anticipate the issues that may come up during development, implicitly reducing risk.

Why is the software architect there? That’s clear: the software architect ensures that the product can be built. The systems architect? Also clear -- the new software has to work across the entire network. We wouldn’t want to build something and then have it fail because of unanticipated network complexity.

An important function of the product design table is to expose unanticipated issues that could impede the value proposition. Why aren’t the shipping personnel there? Huh? Shipping problems don’t impede the value proposition. Unless the object being produced weighs 20 tons. Then shipping probably does need to be considered.

It is inherently risky not to have the proper people at the product design table.  Why? Because fundamental choices in one aspect of product design affect other aspects, often without intention or recognition.

One of the most under-represented functions at the product design table is the work-modeler. This person understands how others will use the tool being built and its context. Take a drill, for instance. A drill used in construction, one used by a jeweler, by an astronaut and one used in orthopedic surgery all need different operational characteristics because of the context in which they are used, and how the operators think about their problem.

The construction worker, jeweler, astronaut and doctor all have different thoughts regarding how pressure is applied, where the residue goes, impact of sparks from the motor, and presence of gravity. Each work model shapes designers differently. The designer of the shell of the orthopedic drill may choose to completely encase the motor so that sparks don’t impinge on the sterile operating field. This decision impacts the motor designer who will likely worry about heat build up. If the two don’t vet their designs with each other, the value proposition will be at risk.

This story is important because in software product design the work model, data model, and software architecture are strongly mutually dependent. One cannot be designed without the others, and each has impacts on what the other can be. However, the work model is rarely, if ever, planned for, and its validity is usually ascertained through feedback from the market after the product is released.

Some might argue this isn’t a problem – we’ll just rework the software. But if the problem is fundamental, and the basic software architecture and data models are incompatible with the needed work model, then change is costly – no one wants to go re-architect their software. At this point, the band-aids and patches are applied, and the growth of the product becomes quirky.

Our solution is to not only be purposeful in designing the work model for software, but also to analyze the system in question to ensure that all germane design areas are represented at the product design table, and to ensure that all present understand the work model and all component design solutions, the interactions between the different design solutions, and the likely resultant behavior of the system as a whole before any investment in construction is made.

The result of our work is a coherent system design.

Response 1:

Response 2:

Response 3:

Response 4:

Response 5:

 

Response 6:

Response 7:


phone: 617-697-7527 — e-mail: ben@dubrovsky.name — ©2007, 2008, 2009 Ben Dubrovsky