Todd Biske: Outside the Box

What looks to be a very simple question is actually a very tough one. The answer to this is of particular importance to a domain architecture team (a team whose scope is larger than a single project or solution), but the principles apply even to a solution architect. The solution architect has a slight advantage that they’re typically working with a team that has a single common goal: deliver the solution. Domain architects, however, must balance the delivery focus of project teams with setting the stage for systemic success across a broader portfolio of solutions, be it within a line of business or across the entire enterprise.

To me, architecture is about creating a categorization that establishes boundaries. These boundaries partition the solution into different areas. What’s the most frequent reason for partitioning? To create areas of responsibility. Within a project, your break things down to a sufficient level in order to be able to hand off units of work to individual developers or engineers, who now have responsibility for delivering that work. The biggest challenge is where those units of work overlap. When thinking of the typical Visio diagrams associated with architecture, this type of view is consistent with a boxes and lines view. We’re interested in what the boxes are and what’s on the lines (the interfaces and messages) that connect them.

While this boxes, lines, and responsibility approach works for both project and domain architects, there is one big, significant difference: the timeframe of responsibility. Once a project has been delivered, the development responsibilities typically go away. Your decisions on how partition the project are solely based on getting it delivered. A domain architect, however, is interested the full lifecycle of responsibility for a component. It’s not just the initial development, but it’s the ongoing care and feeding, the onboarding of new consumers, etc. If we don’t partition things to support future change, the pain involved in supporting that change will be high. The desire to partition things to allow for an efficiently managed portfolio may not be the same partitioning that allows for the most efficient development. These needs have to be balanced. In the perfect world, the partitioning for portfolio management could occur outside the context of any project, allowing the “optimal” partitioning to be used as an input by the project architect to balance these needs. In reality, that context doesn’t exist, and we’re doing our best to build it as we go along.

This type of approach can be challenging for domain architects when many people have the perception that the architect is the nuts and bolts person, looking at how things are built, rather than what gets built. That’s because many architects have gotten there by being a senior developer or engineer. I’m not suggesting that the “how” portion isn’t important, especially because the “how” decisions also have a lot to do with partitioning, but the “what” is increasingly important, because that ultimately defines what must be managed for the long term. If those units are difficult to change over time because of poor partitioning from a responsibility and ownership viewpoint, it will be a struggle.

What are your thoughts on what things are architecturally significant?

2 Responses to “What is Architecturally Significant?”