Crossing the mythical line or bridging the gaping chasm?

The line between software development and software architecture is a tricky one. Some people will tell you that it doesn't exist and that architecture is simply an extension of the design process undertaken by developers. Others will make out it's a massive gaping chasm that can only be crossed by lofty developers who believe you must always abstract your abstractions and not get bogged down by those pesky implementation details. As always, there's a pragmatic balance somewhere in the middle, but it does raise the interesting question of how you move from one to the other.

Some of the key factors that are often used to differentiate software architecture from software design and development include an increase in scale, an increase in the level of abstraction and an increase in the significance of making the right design decisions. Software architecture is all about having a holistic view and seeing the bigger picture to understand how the software system works as a whole.

While this may help to differentiate software development and software architecture, it doesn't necessary help to understand how somebody moves from development into architecture. Furthermore, it also doesn't help in identifying who will make a good software architect and how you go about finding them if you're hiring.

Experience is a good gauge but you need to look deeper

There are a number of different qualities that you can look for in a software architect and their past experience is often a good gauge of their ability to undertake the role. Since the role of a software architect is varied though, you need to look deeper to understand the level of involvement, influence, leadership and responsibility that has been demonstrated across a number of different areas. In conjunction with our breakdown of the software architecture role, each of the following aspects can and should be evaluated independently.

Architecture definition

The architecture definition process seems fairly straightforward. All you have to do is figure out what the requirements are and design a system that satisfies them. But in reality it's not that simple and the software architecture role undertaken can vary wildly. For example, it could include challenging complex non-functional requirements versus simply assuming their existence. Designing a software system from scratch versus extending an existing one. Choosing and evaluating technology for a new system versus adding technology to an existing system. Proving that your architecture will work versus hoping for the best. And working with external stakeholders versus simply documenting how the system works for the internal team.

Architecture delivery

It's the same story with the architecture delivery elements too. For example, there's a difference between being continually engaged and evolving your architecture versus choosing to hand it off to an "implementation team". Taking responsibility for your solution versus assuming that it's not your problem. Coaching your team in architecture and design versus helping people with their coding problems. Assuring quality and selecting standards versus being reviewed against them or doing nothing. Being involved in the hands-on elements of the delivery process versus watching from the sidelines.

The line is blurred

Regardless of whether you view the line between software development and architecture as mythical or a gaping chasm, people's level of experience across the software architecture role varies considerably. Furthermore, the line between software development and software architecture is blurred somewhat too. Most developers don't wake up on a Monday morning and declare themselves to be a software architect. I certainly didn't and my route into software architecture was very much an evolutionary process. Having said that, there's a high probability that those same developers are *already* undertaking parts of the software architecture role, irrespective of their job title.

There's a big difference between contributing to the architecture of a software system and being responsible for defining it yourself; with a continuum of skills, knowledge and experience needed across the different areas that make up the software architecture role. Crossing the line between software developer and software architect is up to us. As individuals we need to understand the level of our own experience and where we need to focus our efforts to increase it.