I came across this post by Michael Platt the other day. It's about the definition of the term "architecture", which is something I've been thinking about a lot recently (due to the fact that I'm writing a class for Pluralsight with the word "architecture" in the title).
Here's the thing: Years ago, I used to have the title "system architect", but I don't think I could have told you what "architecture" means. In fact, I don't think I could have told you clearly what it meant if you asked me last month. The closest I could have gotten was probably "what architects do". And with all respect to Mr. Platt, his definition:
Architecture is the use of abstractions and models to simplify and communicate complex structures and processes to improve understanding and forecasting.
doesn't really do it for me either. Is it really an architect's job exclusively to forecast and communicate? That doesn't sound like a complete or accurate description of what I do when I act as the architect on a project.
It was conversations with my friends Tim and Jeff that really cleared it up for me. They pointed a couple of things out to me. First of all, only software architects talk about "an architecture". Architects that build buildings talk about a design. This really resonates with me - I've always felt uncomfortable with the question "What's your architecture?" - I don't think that's a meaningful thing to ask. Whereas the question "What's your design?" seems far more straightforward and utilitarian.
So that goes straight to the question, "What should a software architect do?" It now seems fairly obvious to me that the answer is "Design software". Hopefully, these designs are based on the users' requirements - sussing out what those requirements are and turning them into a design is what distinguishes a good architect from a bad one. As is having an intimate knowledge of the technologies involved - good software architects should be reasonably good coders the same way good physical architects should know the properties of drywall and steel! Of course, neither can work in a vacuum, and both should rely on practitioners to verify and enhance the design against real-world constraints.
I think there's also another legitimate activity for someone that calls themselves an architect to perform. It involves the distinction between "architecture" and "Enterprise Architecture". The latter term has been so abused as to have nearly lost its meaning, but nevertheless I think it serves as well as any term we have right now as a description of an important activity; namely, that of setting up a framework within which architects can create maximally useful designs. Allow me to elaborate.
In "real world" construction (i.e. the construction of physical buildings), there are both architects and city planners. City planners do things like set up building codes, lay out key pieces of infrastructure, and check for conformance to rules. I believe that "Enterprise architects" should play a similar role in organizations where the resulting consistency is beneficial. We probably need a better name for this role, but Enterprise Architect serves well enough for now.
It seems strange that it has taken me something like ten years to understand this distinction well enough to be able to put it into words. But I feel better for having done so - as I said, I've always felt uncomfortable when people start slinging around the a-word; I guess I've just encountered too many people sporting the title "architect" who were useless, Ivory Tower, overengineering types. But with the analogy to real-world architecture clearer in my head, I can finally easily distinguish between productive and unproductive architectural activities.
I'm sure I'm not the first to arrive here, but based on the massive fog around terms like "architecture", "architect", and "enterprise architecture", I can't imagine I'll be the last, either.
