Despite what you may hear some people say, software architecture is not a “post-technical”
or “non-technical” career. Drawing a handful of boxes, lines and clouds on a whiteboard and handing that off as a “software design” is not what the role is all about.
Deep technology skills
“T” is for technology, and this is exactly what good software architects need to know about.
As software developers, we tend to have knowledge about things like programming language syntax, APIs, frameworks, design patterns, automated unit testing and all of the other low-level technical stuff that we use on a daily basis. And this is the same basic knowledge that software architects need too. Why? Because people in the software architecture role need to understand technology, basically so that they are able to honestly answer the following types of questions:
• Is this solution going to work?
• Is that how we are going to build it?
However, given the learning curve associated with being productive in different program-ming languages, it’s common for software professionals to only know one or two technologies really well. Eventually these people get known for being a “Java developer” or an “Oracle developer”, for example. I’ve been there and done that myself. I’ve also seen it happen in many other organisations. If you’ve ever wondered why there are so many religious battles related to programming languages, you need look no further for how many of these start.
Although we may strive to be open-minded, it’s easy to get siloed into a single technology stack. While there’s nothing particularly wrong with this, you have to be careful that you do keep an open mind. As the saying goes, “if all you have is a hammer, everything will look like a nail”. Gaining experience is an essential part of the learning journey, but that same experience shouldn’t constrain you. As an example, you don’t need a relational database for every software system, but often this is the first thing that gets drawn when a team is sketching out a candidate software architecture.
Broadening the T 35
Breadth of knowledge
And that brings me onto why it’s important for software architects to have a breadth of technology knowledge too. Sure, they may be specialists in Java or Oracle, but the role demands more. For example, the people in the software architecture role should be able to answer the following types of questions too:
• Is the technology that we’ve chosen the most appropriate given the other options available?
• What are the other options for the design and build of this system?
• Is there a common architectural pattern that we should be using?
• Do we understand the trade-offs of the decisions that we’re making?
• Have we catered for the desiredquality attributes?
• How can we prove thatthis architecture will work?
Software architects are generalising specialists
Most of the best software architects I know have come from a software development background. This doesn’t mean that they are the best coders on a team, but they are able to switch between the low-level details and the big picture. They also have a deep technical specialism backed-up with a breadth of knowledge that they’ve gained from years of experience in building software. But they can’t (and don’t) always know everything. Plus it’s rare to find a software system that only uses a single technology stack. Some examples of systems with heterogeneous technology stacks that I’ve seen during my career include:
• A Microsoft .NET desktop client running against a number of Oracle databases.
• A Microsoft ASP.NET website pulling data from an Oracle database via a collection of Java EE web services.
• iOS and Android mobile apps pulling data from RESTful services written in Java.
• A micro-service style architecture, where various services were built using Microsoft .NET or Ruby.
• A Microsoft ASP.NET website pulling data from a Microsoft Dynamics CRM system.
• A Microsoft SharePoint website pulling data from a collection of databases via Microsoft .NET/Windows Communication Foundation services.
• A Java EE web application integrating with SAP.
Broadening the T 36
• etc
Although general design knowledge, techniques, patterns and approaches often apply to a number of different technologies, not understanding how to apply them successfully at a low-level of detail can cause issues. Does this mean that the software architect should be an expert in all of the technologies that are in use on any give software system? No. Instead collaboration is key. Find somebody that does understand the things you don’t and work with them closely. Nothing says that the software architecture role can’t be shared, and often appreciating the gaps in your own knowledge is the first step to creating a more collaborative working environment. Pair programming has benefits, so why not pair architecting?
Software architecture is a technical career
Technology knowledge underpins the software architecture role, requiring a combination of deep technology skills coupled with broader knowledge. If the people designing the software and drawing the architecture diagrams can’t answer the question of whether the architecture will work, they are probably the wrong people to be doing that job. Software architecture is most definitely a technical career but that’s not the end of the story. Goodsoft skillsare vital too.