What is Software Architecture?

Maybe the answer to that question is obvious to everyone but me. Could be. But my experience in industry leads me to believe that while the answer may be obvious to many, it is not the same answer that is obvious. In other words, there is no universal answer to the question. Different people have different views on what Software Architecture is, and that’s totally okay. My goal here is to capture what Software Architecture is from my perspective, to clarify where I’m coming from. It is just one of many perspectives, and I’m not claiming it is better or more appropriate than any other — ultimately every organization makes of Software Architecture what it needs to. But here is my take on it:

Software Architecture is the process of constraining the solution space

Pithy perhaps, but what exactly does that mean?

Well, suppose you were to come up with a software engineering problem and give that problem to ten different engineers to solve. What would happen? You’d probably get back twelve different solutions (there are always a few propeller-heads in any group that can’t limit themselves to just one answer). If you chose good engineers all twelve solutions would likely be valid, but different.

That’s totally understandable — in software engineering, there is never a single solution to any problem. Every engineer has a different perspective, a slightly different understanding of the problem you’ve given them, and different ideas on how to arrive at a solution. There are no universals.

And therein lies the problem.

For any software engineering project, there is a large solution space of possible “working” solutions. The overall quality of the solutions in that space vary — some are great, and some are barely passable. As you progress through your development project, the many, many decisions that your engineers make steer you towards some point in the solution space. Ultimately, you want to arrive at a point that represents the best possible solution attainable given the time and resources you have at your disposal.

But how do you “steer” your project through that solution space towards the best solution you can reach? There are plenty of potential potholes that you need to worry about — like engineers choosing a quick and easy path that leads to a less good solution rather than a harder path that leads to a better one. Or different engineers heading off in different directions that eventually require extra work to reconcile. Or engineers forgetting that this stuff actually costs money to run when you put it into production. How do you manage the journey through the solution space?

One possible approach is to constrain the solution space. If you can cleave off undesirable parts of the solution space, you will increase your odds of ending up with a solution you like. You will also tend to herd your engineers towards a more internally consistent solution. Constraining the solution space is not a panacea and does not guarantee success, but it does help to steer you towards the goal.

And that brings us back to my definition of Software Architecture:

Software Architecture is the process of constraining the solution space

So what I’m suggesting is that Software Architecture process, if done well, serves to constrain the solution space for your development project and guide you towards a more successful outcome.

And as an aside, yes, I am suggesting that Software Architecture is a process. There are certainly artifacts generated during the Software Architecture process, which I would be inclined to call software architecture documents. Those artifacts are important, but I would suggest that the process is the essential part.

The key inputs to the Software Architecture process are the business requirements that are driving the development project, which should, in turn, define the set of criteria used to evaluate the “goodness” of any given point in the solution space. Of course business requirements are not always clear or complete, nor it is always clear how they should be translated into criteria over the solution space. Perhaps the most important part of a Software Architect’s job is to bridge that gap and understand where the “good” parts of the solution space are.

The Software Architecture process should ideally be ongoing, throughout the life of the development project. You could try to lay out a set of constraints at the start of the project and run with that, but frankly nobody has enough foresight to predict all of the possible decision points that you will encounter and come up with an a priori solution. The process should be proactive to the extent possible, and reactive when necessary.

I realize that not everyone will be fond of the Software Architecture process as I have defined it (or Software Architecture no matter how you define it). Some may view it as an impediment that slows down project execution, or as unnecessary overhead that can perhaps be avoided by using small project teams or agile methods. And that view is indeed valid if your goal is to complete your project as quickly as possible, rushing pell-mell towards the first attainable solution. The goal of Software Architecture as I have defined it is not to enable you to go as fast as possible, but rather to attain a better balance of cost (time) and quality.

Can you get by without Software Architecture? Yep. If you completely ignore the Software Architecture process and dive into the solution space unconstrained, you can certainly still build a good working solution.

Is it extra cost and overhead? Certainly, it takes people, time, and effort — it isn’t free. But you can view its cost as an investment that has an expected return.

And that, I think, is the best way to answer to the question, “Should I worry about Software Architecture?”: view it as an investment, and base your decision on that.