Home > Architecture / Engineering > Architectural Decisions and Their Consequences

Architectural Decisions and Their Consequences

April 28, 2010
Following on from previous posts of articles taken from ‘design patterns for .net’

Architectural Decisions and Their Consequences  (by Rob Daigneau – design patterns for .net) – Read for full article, extract below.

Our customers continually challenge us to design and produce systems that are characterized by a plethora of adjectives. We’ve all heard the wish-list so many times, "We need a system that is agile, scalable, highly available, secure …" and so forth. While our hearts are certainly in the right place in our efforts to achieve such things for our customers, oftentimes we can be somewhat naïve concerning our own abilities to attain all goals equally on a given project. The truth is that we can’t have it all, and as architects we must carefully weigh the trade-offs and consequences of choosing to optimize for a given goal. It then follows that the difficulty of evaluating the consequences of our design decisions will only compound as the number of goals increase.

Shared Goals 

When it comes to software systems, every executive, manager, architect, developer, DBA, and customer typically hopes to achieve similar goals. We all want systems that have these attributes…

  • Adaptable: The system is easy to maintain, alter, and reshape when the need arises. This includes the ability to add (i.e. extend), change, or remove functions and logical sub-systems. The system is agile in that it can readily be adapted to reflect changing business requirements. 

  • Available: The system may be accessed and used in the intended manner when the users need or want to use it.
  • Efficient: The system does not place undue stress upon limited resources such as server or workstation memory, disk space, network bandwidth, and database connections, to name a few.
  • Interoperable: Applications or sub-systems easily integrate with other applications or sub-systems to create more complex "super systems". Sub-systems can be "weaved together" (hopefully in a loosely coupled fashion) to create a seamless information system that might even cross organizational boundaries.
  • Manageable: Individual parts of the system are easy to deploy and manage once they have been rolled out.
  • Responsive: The system has high throughput, acceptable response times, and is scalable (i.e. the ability for a system to continue to perform well as the load increases).
  • Robust: The system can recover from or correct run-time errors.
  • Secure: The system only allows individuals to access functions and data that they are authorized to access.

There might be a few more goals that we are asked to achieve as well …

  • Portable: Parts of the system may be moved to other operating systems, programming languages, database management systems, or other supporting technologies.
  • Chameleonic: The information managed by the system can be presented through a variety of means including various web browsers, rich clients, and mobile devices. The system’s presentation approach is smart enough to morph for different types of machines or operating systems, or perhaps can be "branded" for different customers.
  • Localized: The system uses languages, monetary units, and other aspects specific to a given geographic region.

There are, of course, some things that few of us would debate are not amongst the "must-have" characteristics. These include …

  • Accurate: The system accurately implements the business rules and correctly executes the tasks desired by the users.
  • Consistent: Business rules are uniformly implemented and common logic is shared throughout the system. This capability might also encompass the goal to have a user interface that has the same "look and feel" throughout.
  • Valid: The data managed by the system is always in a valid state; data corruption is not allowed.
  • Intuitive: The system is easy to understand and use. It allows people to work the way the want to work.

Is it really possible to achieve all of these things? In a world where time, money, and resources (i.e. developer talent) are unlimited, then the answer might be yes. Unfortunately, that is not the world we operate in.

A Trade-off Model for Architectural Decisions

It is usually beneficial to assess what the impact of a given design decision might be with respect to time (i.e. how long it will take), cost, and complexity. The diagram below attempts to show that a continuum exists between most goals (listed in the prior section) and these competing objectives.



For example, if we seek to achieve a system that is very responsive, then it will usually take longer to deliver upon that goal, it may cost more, and will probably entail a more complex solution. We can, however, seek to find some balance between these goals. In other words, we might decide that in order to achieve certain delivery dates, stay within budgets, and reduce complexity, that it may be acceptable to seek a level of responsiveness that is "good enough" for the business requirements, but not as fast as we might have hoped for if we were not constrained by schedules, budgets, or the capabilities of our teams.

This model does not suggest that there is a necessary trade-off to be considered between all goals and time, cost, or complexity. For example, if we seek to achieve systems that are highly adaptable, then oftentimes we need only consider what the impact might be on delivery time and cost. The rationale here is that highly adaptable systems are supposed to be delivered through designs that are characterized by lower complexity, which in turn allows them to be adaptable in the first place. The paradox here is that sometimes this adaptability does involve the introduction of greater complexity to allow such malleability. The trick is to abstract away this complexity from your developers through the skillful use of design patterns.

It should also be noted that sometimes certain goals can be difficult to achieve in unison. For example, if we seek higher degrees of interoperability between disparate systems, we might need to accept a trade-off in terms of overall system responsiveness.

Many believe that such trade-offs can be mitigated by "throwing bodies at the problem" (i.e. staffing up, adding more resources, etc.). I’ve found that, while it might be possible to use such a technique to both optimize for a given goal and achieve faster delivery times, the cost will still rise, and the level of complexity of the solution remains unaffected. Furthermore, the complexity of managing the increased number people tends to naturally rise in the wake of such a decision.


All architectural decisions involve consequences, some are beneficial, and others are less desirable.  As a parting analogy, consider what you might wish for in your dream house. If you were to present your ideas to an architect, and he provided an estimate in return, would it be possible that you might respond with, "Maybe I don’t need all that"? Technical Architects must have the ability to assess the trade-offs incurred by all design decisions, communicate these consequences effectively to their customers, and help everyone find the right balance between what are oftentimes competing goals.

This exploration is continued in Architectural Decisions and Their Consequences – Part II.


%d bloggers like this: