A Trace in the Sand

I love my Trek bicycle, but with Shimano gears and brakes, and Bontrager frame, wheels, tires, and pedals, the ineffable Trek quality cannot be pinned down to any Trek-branded component. The success factor here: modularity with clear interfaces, and clear design requirements pushed down to the modules so that excellence at the level of the overall system is achieved through the composition of excellent pieces.

Bicycles have been around a long time, and there is a dominant design. That allows innovation to be focused on the components and subsystems, with less frequent revolution in the overall decomposition. Together these 3rd party pieces fitting into a standard decomposition nonetheless yield a system that is unique and differentiated. Modular components driven to excellence in of themselves, plus a clear sense of the differentiating system qualities, yields a distinctive product. Flawless. So well-designed I can say wthout reservation, I love this product.

It is the architect’s responsibility to create the architecture (with collaborative input from component designers): to make decisions about the system identity and integrity, and decisions about components and their scope and responsibilities, and address cross-cutting concerns and system properties. The architecture provides the context to push excellence, innovation and quality to the level of the components.

In the software world, in the pressure of the moment we allow ourselves to accommodate the architecture. Every compromise to the modularity of the system increases the future cost of change. But we live in the present. We have to get out of this singular mindset, and part of the way out is to have an architect with the clear and well-known charter to preserve the structure of the system—to defend modularity and ensure that the modular pieces do indeed work together to deliver the functions and properties required.

Feature set teams or storyline teams (or whatever else you call them in your group) tend to work across the layers in a system. This work partitioning helps drive out features that users can respond to and give feedback on, so they can be improved. Great! But it also makes it important to empower an architect to defend and preserve the architecture, and yes, evolve the architecture when, on balance, that is the best route.  

Objects, then components, now services, are all hyped because they promise to address the build-from-parts need in our software world, at ever greater levels of granularity. But solving our problem isn’t simply a matter of picking a programming paradigm that supports (larger-grained) parts. We have to become good at designing parts—parts that really fit our system; really fit our need.

I acknowledge that I am fundamentally, completely, biased here, but I can see no other course than through getting better at architecture, and better at protecting and preserving our architecture, and better at investing in evolving and regenerating our architecture. And better at investing in what it takes to completely revolutionize our architecture, even though that means we have to do so with a whole new set of people, which is counter-intuitive (see Rechtin’s book Why Eagles Can’t Swim, 2000).