What is Architecturally Significant?

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?”

  • I think this is another way of picking away at the issue that I know we’ve both been talking about for some time, and that’s about the relationship between projects, processes, service delivery and the concept of “product management”.
    Fundamentally in my mind the thing that should inform the “flavour” of the partitioning scheme at the domain level should be an understanding of business strategy and priorities – within a domain is the chief priority quick delivery, long-term flexibility, long-term cost of ownership? Does strategy dictate that business processes and activities are highly structured, constrained, fixed or as flexible as possible? Sometimes it might be that a development-biased partitioning scheme is just fine. Other times, though, the implications of long-term sustainability of flexibility should trump everything else.

  • I going to agree with Neil here – partitioning at the domain level should be driven by the business strategy. This means how this is done is going to vary from shop to shop.

    Organizations that need quick delivery is going to drive a different type of partitioning than organizations that have long release cycles. For example, if the same team is responsible for the complete life cycle of a product it’s going to be hard to have quick delivery no matter how well the actual architecture is implemented. Some smaller shops are forced into this mode with usually bad results. In my experience this is where technical debt usually starts to occur.

Leave a Reply


This blog represents my own personal views, and not those of my employer or any third party. Any use of the material in articles, whitepapers, blogs, etc. must be attributed to me alone without any reference to my employer. Use of my employers name is NOT authorized.