I spoke briefly yesterday with a colleague who is busy setting up a team whose focus will be developing architectural competences within the company. During our conversation, I expressed my view that architecture is a basic core competence for a software developer. I hope I managed to make it clear to him that I do regard architectural concerns as a valid and valuable field of enterprise within the development of software systems, but just in case, and for the record, I'll try to write down what I believe to be the truth about this subject.

Firstly, let's talk about the problem, which is that in the world of computer software, architecture has become rather a loaded term, and is perhaps abused by various interest groups to suit their own ends. This isn't new: for as long as I can remember there has been a sort of job title inflation in our business. These days, it's not enough to be a programmer any more, although once we might have regarded all sorts of capabilities as being implied by the term. (Perhaps programmer just means lowly coder, as though there ever was such a thing. Surely, there are competent programmers and those who are less so.) Then we had to be analyst-programmers (APs), and perhaps the invention of that title meant that programmer didn't imply analyst any more. At some point, people seemed to get the point that unless a programmer was an analyst too, you shouldn't hire him, and the whole AP thing dropped out of fashion.

Nowadays, you have to say software developer, which apparently implies analyst, while maybe 'programmer' didn't. Strangely though, it doesn't seem to imply that you need to understand architecture. That's kind of funny, because the technical career path sort of goes, junior developer, developer, senior developer, architect... Did you notice that? You suddenly transmute from programmer to architect - funny, eh? I can see why this might be. After all - once you are a senior, where do you go from there. Where's your career development path?

In the world of bricks and mortar, no-one calls a bricklayer an architect, but the person who designed the house you live in is almost certainly an architect. In general, the architect is responsible for taking the customer's requirements and transforming them into a concrete (!) building or other such developement. This means discussing the customer's needs, understanding the available materials, techniques, etc., creating a design, and overseeing the construction to ensure correct construction in line with that design. The notion of architecture also implies an overview, and a sense of aesthetics applied to the construction as a whole in the context of its environment.

A bricklayer by contrast, is more of a craftsman. Bricklayers understand things like bonds and cement and gravity and straight edges and so forth. They have technique, but people don't see them as designers, even though they are probably responsible for design in the small. Of course, a computer programmer is a craftsman too; he must wield his programming languages in an artful way, and choose among possible implementations of a larger design.

That's about where the analogy breaks down though. Learning a few programming languages and being able to write in them probably fits the job description of a junior programmer.  Most of the work of a journeyman programmer is far more involved. He talks to end-users, customers or product managers. He understands the requirements and produces designs which reflect the available techniques. This includes far more than simply coding. If we take the example of a programmer working on a typical web application, he may very well produce and implement designs which require knowledge of relational databases and how to produce an abstraction layer to access them, (including perhaps the use of object-relational mapping tools). Then there's probably an application server, transaction management and issues regarding state (or the lack of it). Then there's presumably a web server to deal with, and more choices about statefulness, including session management, and perhaps the need to cluster. Onwards to the network layers, where he'll need to understand TCP/IP, firewalls, proxies of various kinds, DNS, HTTP, encryption and certificate infrastructures, Web services, REST..... We're getting somewhere near the browser now, so there'll be AJAX, Comet, HTML, XHTML, Javascript and CSS browser hacks.

Well I'm sure you get the picture. My putative programmer probably not only has to understand this all on paper, but needs to know how to put all the pieces together with his own bare hands, and we haven't even started on development techniques and methodologies from waterfall to agile, version control, continuous integration, project management, design patterns and how to tell snake-oil from cargo-cult lunacy and both of them from the real deal.

And now after all that, when he finally takes the career step to pick up a business card that says "architect" on it, we shouldn't be surprised that he begins with at least some small clue about what's going on. The strange thing is that when I baldly state my view that architecture is a core skill for programmers, well you wouldn't believe the number of times I get contradicted.

Without a solid understanding of architectural concerns, you are not a programmer. Any real architect understands this, but unfortunately, I've seen far too often the kind of conversation that goes like this:

Programmer: Let's discuss the architecture.

Architect: I'm the architect, why would there be a discussion?

Over the years I have known several software architects who could and did write code to express their ideas and prove their concepts. For these people, a discussion of architecture with a programmer was not a threat, because when the programmer inevitably asked "How does it work?", they would be able to demonstrate,.

Unfortunately, the other kind of "architect" in this scenario usually doesn't have the ability or the inclination to express his proposed architecture in working code. Unless you have the ability to express your proposed architecture in working code, it is supremely unlikely to work. I'd go further than that and say that the best way for an architect to convey his design to a programmer is exactly that; working code. This may be just a basic proof of concept, but unless the architect has written the proof of concept code, he hasn't  done his part of the job yet, and if he has written it, why shouldn't it be a deliverable? You may laugh, but I've observed so-called architects in the wild, and seen technologies selected from a brochure without so much as a trial run, and foisted on programmers, who then had to get everything to work.

You learn software architecture by being a programmer. Becoming the architect doesn't absolve you from maintaining the ability to get it and keep it working. Far from it.

Before anyone goes running off with any strange ideas, let me be very clear. I don't have any problem with software architects. (Some aspects of my work are fairly accurately described by the term.) What I'm railing against is the way that the job title has been assumed by large numbers of people who seem to think that this puts them above the need for achieving technical consensus about what will work and what constitutes good practice.

Am I talking about you? Ask yourself this simple question: Is architecture a core skill for a software developer?