Harnessing the Power of Architectural Design Principles

This article first appeared in IEEE Software magazine. IEEE Software offers solid, peer-reviewed information about today's strategic technology issues. To meet the challenges of running reliable, flexible enterprises, IT managers and technical leads rely on IT Pro for state-of-the-art solutions.

People often talk about a system's "architectural design principles" (or just "architecture principles"). But without a clear definition of "principle", it's not always obvious what this means. By defining the role and benefits of architectural design principles, we can capitalize on a very useful technique.

In this column, I define architectural design principles, explore what good principles look like, and describe when using principles in architectural practice might be valuable.

Defining Principles

I'm deliberately not making a hard distinction between design and architecture because I don't think it adds anything useful in this context. For the purposes of this discussion, I'm talking about design principles that apply equally well at both more detailed and more abstract levels.

The Oxford English Dictionary states that a principle is "a fundamental truth or proposition serving as the foundation for belief or action", and that a design is a "plan or drawing produced to show the look and function or workings of a building, garment, or other object before it is built or made". So, we can reasonably define a software design principle as

a fundamental truth or proposition serving as the foundation for action with regard to deciding on a software system's workings.

The key point is that a principle is a clear statement of intent that guides our design work.
Other definitions of design principles have been proposed. In the book Architecture Principles¹, Danny Greefhorst and Erik Proper created probably the most comprehensive definition:

a declarative statement that normatively prescribes a property of the design of an artefact, which is necessary to ensure that the artefact meets its essential requirements.

Although this definition is a little abstract, it clarifies the design principle's role as ensuring that some aspect of your architecture meets some aspect of its requirements.

But enough about abstract definitions. What does a real architecture principle look like? Figure 1 shows a simple principle based on a real example from the banking domain. In short, this principle

• provides a clear name that hints at how we're meant to respond;
• offers a brief, clear description;
• makes the driver behind the principle clear;
• defines its domain of applicability (messaging for certain data types for applications classified in certain ways-other people needn't worry about this principle); and
• explains why this principle is important so that we can decide when to apply it.

[Click on the image to enlarge it]

FIGURE 1. An architecture principle based on a real example from the banking domain.

This input into the design process is useful because it emphasizes the organization's priorities, explaining when and why the principle is important.

The Benefits of Architecture Principles

Architecture principles epitomize architecture's function: to clearly define the necessary constraints on a system's design without prescriptively defining all the design details. In a previous column, I said that architecture deals with the "gaps" between things². Thus, architecture principles help establish boundaries and priorities without micromanaging how everyone performs their work. A good set of architecture principles offers the following key benefits.

Context for Design Decisions

Principles can clarify priorities and constraints, helping people make consistent, informed design decisions. In fact, I've found they can make abstract ideas such as business goals more accessible and help designers make technical decisions that support them. I'll return to this idea in more depth in a future column.

Justification for Decisions, Cost, and Time

As designers, we often face situations in which the right plan costs more or takes longer than we'd like, but it's difficult to explain clearly and succinctly why it's the right plan. A set of clear principles can provide a basis for that explanation. For example, the principle that all systems must be suitable for high-availability deployment might justify building multinode operation capabilities into all systems, even if this isn't the cheapest option for the immediate future.

Enhanced Collaboration, Communication, and Shared Values

Like many architecture artifacts, principles must be developed by groups, not individuals. This ensures that they're validated early and that the group feels collective ownership of them. Moreover, this helps people collaborate and build shared values, fostering a mutual understanding of what is and isn't important.

Defining Good Architecture Principles

The practical problem with principles is that they're hard to define well. It's easy to produce lists of selfevident statements or rambling statements of intent that no one can apply because they're long on philosophy and short on actionable specifics. It's difficult to produce a set of principles that people find valuable.

My long-time collaborator Nick Rozanski has identified a good architecture principle's essential criteria³, which are summarized in Table 1. These characteristics take effort to achieve but result in principles that are much more likely to be valuable and provide significant, actionable guidance.

[Click on the image to enlarge it]

When to Violate a Principle

Principles exist to guide the design process and aid consistency. But architecture principles will occasionally be brokensometimes because people don't realize they exist (perhaps there are too many of them) and sometimes because people ignore them (in which case, you must find out why).

Breaking a principle comes with a cost, often a long-term one. So when someone violates a principle, it must be for a justifiable reason. When this occurs, you must check whether the benefits of breaking the principle outweigh the costs.

Broken design principles can also provide valuable information for architects. First, the rationale for breaking the principle highlights some important aspect of the system design. Second, a principle that's justifiably and routinely broken signals a mismatch between assumptions and reality and must be changed. Finally, knowing where in the system the design principles are being violated will help you deal with these nonstandard aspects as the system evolves.

Although people often talk about their systems' architectural principles, they're often hard-pressed to name them and explain their rationale. A little time spent during a system's life cycle, particularly early in its development, to identify, debate, capture, and communicate a coherent set of design principles can be very valuable. It's not an easy process, but the end result helps align theory and practice.

References

1. D. Greefhorst and E. Proper, Architecture Principles: The Cornerstones of Enterprise Architecture, Springer, 2011.
2. E. Woods, "Architecting in the Gaps: A Metaphor for Architecture Work", IEEE Software, vol. 32, no. 4, 2015, pp. 3335.
3. N. Rozanski and E. Woods, Software Systems Architecture, 2nd ed., Addison- Wesley, 2011.

About the Author

Eoin Woods is the chief technology officer at Endava. Contact him at eoin.woods@endava.com.

This article first appeared in IEEE Software magazine. IEEE Software offers solid, peer-reviewed information about today's strategic technology issues. To meet the challenges of running reliable, flexible enterprises, IT managers and technical leads rely on IT Pro for state-of-the-art solutions.