A Trace in the Sand

The Wikipedia community describes Conway’s Law like this; I paraphrase it like this: if the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins. The organizational divides are going to drive the true seams in the system.

The architecture of the system gets cemented in the forms of the teams that develop it. The system decomposition is what typically drives work allocations. Then the organizational lines of communication become reflected in the interfaces, with cleaner, better preserved interfaces along the lines where organizational dissonance increases. In small, co-located teams, short-cuts can be taken to optimize within the team. But each short-cut that introduces a dependency is like rebar in concrete–structurally efficient, but rigid. If the environment changes, demanding new lines to be drawn, the cost becomes clear. The architecture is hard to adapt.

One could say this is part of the innovator’s dilemma. Sustaining innovations, that is, incremental improvements within the cast of the architecture, are what the organization is adapted to be good at. But when a breakthrough innovation demands a new architecture, a new organization (unencumbered by power trees that grew up around the old architecture) tends to be more fleet in bringing the innovation to market.

Another implication of Conway’s Law is that if we have managers deciding on teams (what they’ll do, who will be on them, and how they will relate), and deciding which services will be built, by which teams, we implicitly have managers deciding on the system architecture. They determine system chunks (services or components) and capabilities by deciding who will build what.

Conway’s Law also kicks in if we take an initial guess at the system decomposition (a first-cut conceptual architecture), allocate subsystems to teams, and sally forth–the team boundaries will tend to become the boundaries within the system. Anything else will be a feat of architectural heroics; hard to accomplish, when architectural heroics have to compete with schedule heroics driven by the steady beat of integration clocks. Yet, architecture is where we address cross-cutting concerns, or at least those that needs-must be addressed with a system perspective so that when it comes time to compose the system it will have the properties stakeholders care about, rather than emergent properties that may or may not suffice.

Roles are defined by their responsibilities and associated decisions. Architect is a role. Any person may play one or more roles. That is, the architect role may be shared among a group of people (as in many agile project teams), or one person may hold more than one role (as in many small teams, especially in startups).  This may be overt and declared. And it may be the result of decisions that are actually effected. If management decisions determine the architecture of the system, they are in effect its architects. If developers determine the architectural decisions, they are in effect its architects.

“Duh!” you might well be saying. Yes, a lot of what is absolutely common sense when it is put plainly, is so obtuse in the face of perplexifying reality. Simply witness all the heated arguments and misunderstandings you get around the topic of the role of the architect.

But what does it mean? Architecture needs to happen across the interfaces, and this also means across the system/organization interfaces. It means that system architects (who we call architects) and business/organization architects (who we call managers) should not work as if one has no impact on the other.

Other references:

Why do we need software architecture (how architecture serves organizational and technical purposes)

Who needs carrots anyway? (about the iron triangle and the interface between management and architects)

If you’re interested in Agile and Architecture, here’s an interesting read, including the comments: The Demise of the Gantt Chart in Agile Software Projects, by Tate Stuntz on July 31, 2007. I have to agree with David Christiansen: “I’m not convinced there is such a thing as a methodology or process that can produce good architecture.” People create great architecture, just like it is people that create great software systems. But are there things we can do to create better architectures, and better software systems? Of course I believe there are! That’s where process comes in.

In manufacturing we learned that if we inspect quality in at the end, the cost of quality (a term that refers to the cost of poor quality that leaks through the inspection process, as well as the cost of removing found defects) is much, much higher than if we find potential quality problems at the source, to ensure they aren’t inserted. 

Architecture defects, those that have diffuse impact across the system, are so expensive they are hard to recover from when they are only discovered once the architecture is hard-cast in code. Hard-cast, I say, because though we think software is pliable while we are writing code, the volume of it quickly amasses, and with it sunk cost and sunk time. And we don’t, as an industry, understand sunk cost and sunk time terribly well! It is a huge reset to go back and rework the system to accommodate an architectural change of any significance. Because we perceive software as highly mutable, we think we can recover if we scramble, but our accommodations to the code make it ever more immutable as the structure erodes to the point where it is hard and unpredictable to change.

More expensive still, have to be products that are defective in concept, set to miss the market. Getting the product or application concept right–the value propositions that will deliver customer advantage and delight–is not a feel-our-way-as-we-build kind of thing. It is a strategic matter. Or at least, get the strategy wrong, and all the tweaks in the world are going succeed only by amazing luck and sheer heroics.

And yet, it seems to be asking for suspension of disbelief to ask for time on a project where all that is being produced is models, diagrams, stories, even if this work is toward a minimalist set of strategic decisions. Putting features in front of users, why, that is what creating software is all about. That is where we can see progress.

Still, if progress is moving towards a better sense of what our customers value, across use contexts, and all that decision space complexity, then we can make a lot of progress quickly and cheaply with models (and mock-ups and proof-of-concept/prototypes). And by exploring how those features play out over our posited architecture structures, we can refactor early, cheaply, while all we are changing is models and descriptions.

To help people create great architectures, our process needs to:

• lead us to work in an integrative, collaborative way (without becoming a “committee”)

• explore and visualize value opportunities and value delivery mechanisms, to establish architecturally significant requirements and architecture strategy

• learn quickly through iterative cycles.

Yes, this is an agile process, if we make models recognized citizens of the software world, with full rights to authenticity and budget! In all we do, we have to find a good balance. Our models should not be belabored, certainly not early on, by putting in too much detail or trying to make them look pretty too early in a tool where pretty is hard to do once, let alone with changes.

We also need to open up our “agile” concept of customer. I highly recommend  Hidden in Plain Sight. I’ve also written about delight (key to customer advantage) various places in my architects/architecting/architecture journal notes (e.g., Vitruvius and delight, circle of excellence and (skipping the first paragraph) Zappos demonstrates that IT Does Matter).

What we are trying to do is surface and understand value propositions that users and other stakeholders find compelling. And find and improve the structures (architectural components and mechanisms) that will support the system through the sprints leading up to the first release, and beyond.