The Principles of Pragmatic Software Architecture

What's pragmatic software architecture about? What makes it pragmatic? These are a few questions I'll try to address in this post.

A lot has been written in terms of pragmatic architecture. The principles presented here try to take more of a strategic approach to defining pragmatic architecture. Instead of diving into specific practices, a set of three core principles is presented that set up a frame, or a perspective, in which all further principles and practices can be analyzed.

I'll try to explain the three key principles of pragmatic software architecture here.

Principle 1: KISS

The KISS principle is well known among project managers and alike. For those of you who are not familiar with it, it stands for Keep It Simple Silly (with variants such as Keep It Simple Stupid, Keep It Sweet and Simple etc.). Keyword here is simplicity.

Simplicity is at the core of pragmatic software architecture. Simplicity ultimately means lower risk. Lower risk means higher chance of success.

How do we achieve simplicity in a rather complex world of different technologies, programming paradigms and languages, diverse, often conflicting and ever so dynamic requirements?

The answer, unfortunately, is anything but simple :)

At the root of it lies a strategy or a set of strategies for reducing complexity. An example that comes to mind is the much abused "divide and conquer" strategy. Reduce a seemingly unsolvable problem into a set of orthogonal and easier to solve problems.

The KISS principle should be applied across all aspects of software architecture development, from key scenarios to design and evaluation. But the most impact is achieved in the early stages of the cycle since complexity has a tendency to explode if not addressed early.

Principle 2: SMART

Again, a rather well known principle, mostly with managers but also with software developers and architects. SMART stands for Specific, Measurable, Achievable, Realistic and Timely.

The SMART principle is commonly tied to goals. In this context the architecture artifacts themselves are viewed as the end goal. So how do we then keep the architecture SMART?

To understand that let's briefly look at different components of SMART.

Specific is about making sure the end goal is well defined, without unknowns or ambiguities. In pragmatic architecture terms, we could say that specificness applies to the key quality attributes as well as requirements that the architecture is trying to address.

Measurable is about clearly defining how to measure the success. And in architecture we have a lot of different ways to measure the success, some of the most commonly used are quality attribute based such as ATAM from SEI.

A stands for achievable, but is often substituted for accountable. Both can apply equally well. An architecture should not try to accomplish the impossible. Quite to the contrary, it should be the art of possible. Accountability is really more about ownership. The lack of a sense of ownership is one of the most common causes of failure.

Realistic is all about making reasonable assumptions. Pragmatic architecture must not go out of the bounds of reason. Architectures are often based on visions, and even more often include assumptions about its environment, its users, its use over time etc. It is essential that these are based on hard evidence, rather than pie in the sky expectations.

Timely is about keeping things time constrained. Real world resources are not infinite, and since time translates so well to dollars, it is natural that pragmatic architecture should aim to balance out the desires and real world constraints.

Principle 3: AGILE

Yes, agile is not a principle, it's a methodology, some call it a philosophy. But in the context of pragmatic software architecture I'll treat it as a principle.

Agile is all about being easily adaptable to change. Any kind of change.

So what are some of the most common changes that have the most impact to architecture?

One of the most common is change in requirements. Here's why agile principles go so well with pragmatic architecture. The ability of the agile development process to produce results early and adapt to change so well is synonymous with pragmatic architecture. And while the architecture artifacts are rarely as tangible as development artifacts, they too can be developed in an agile manner, following an agile process such as SCRUM for instance. It's important to note here that agile would not be as effective without SMART as measuring the quality of architecture artifacts early on is as important as producing those artifacts.

But what about change in technology? While not as probable of a risk as the aforementioned (throughout the course of one project), at the enterprise architecture level it has far more impact. This is why enterprise architecture methods need to constantly re-evaluate architectures against technology constraints, and adapt to the change in the environment. Naturally, pragmatic architecture should keep technology constraints in mind during architecture development. Again, this is closely related to the SMART principle as measuring how well an architecture aligns with technology can provide crucial insight into some hidden drawbacks of a seemingly solid architecture.

Conclusion

I tried to outline the three core principles of pragmatic architecture here.

These can now be translated into a whole set of practices to follow during architecture development. The core principles themselves don't guarantee success. Simply following these principles does not necessarily mean an architecture is solid or even pragmatic. But realizing that you are not following them can surely point out obvious issues with the approach and help to mitigate very serious risks to the success of the project.