What is an Architect?

Welcome to the first in a (hopefully) long and fruitful series of discussions about the role of an architect in the world of software development. I’ll be sharing insights from RDA architects and hopefully spark some conversation around what it means to be an architect. The focus will be on the role of an architect and how a person can do a better job in that role. We’ll distill down our experiences into a set of principles that should be useful to someone, somewhere. To be better architects, first we need to understand what an architect is.


When friends and family ask what I do, my normal response is “write software.” Software Developer, that’s something people can grasp. A person who sits at a desk any types inscrutable instructions into a little box for hours on end until a sufficient number of instructions have been entered to cause the box to do something useful. Oh, and they’re the person you call when your Internet stops working. Point being, it’s a well defined role. Rarely do I say “I’m a Software Architect.” Why? Because it’s hard to explain. It leads to a series of uncomfortable questions: “Do you manage anyone?” Well, no. “Do you write the software?” Well, sometimes. “Do you work with the users?” Occasionally. “OK, explain to me again what it is you do?” Never mind, just go look it up on WikiPedia.


An architect has one very specific job on a project: to create a technical solution that solves the business problem while complementing the company’s overall technology strategy. That simple run-on sentence belies the complexity of the task. Designing a technical solution means being able to put something together at a very high level but then being able to dive into the details of each component of the solution. It means being able to make technology choices that will best solve the problems at hand and leave room for solving future unknown problems. It means being able to communicate the choices and their repercussions to both a business and a technical audience. It means a lot of things but, in the end, it means solving the business problem.


OK, now it’s time for Architecture Principle #1. This is where I summarize all the preceding ramblings into one pithy little sentence that’s easy to remember.



The architect is the conduit between the business problem and the technical solution.


The principal above is important because it means that, as an architect, you need to understand and live in two very different worlds: the world of the business user and the world of the Software Developer. Going forward, we’ll be discussing the experiences, best practices, and gotchas that can hurt and help in both those worlds. Always, the focus will be on how the role of the architect helps to solve the business problem at hand. When I grow up, I want to be a real architect.


Don’t like my one sentence definition? Leave a comment! I may even borrow your idea.