Principles of Architecture - Anticipate Reality

My title at work is System Architect. Actually, it's something like System Architect / Engineering Lead, but I have my suspicions that it was suggested by our business card printing company who may, or may not, get paid by the letter. That's a story for another time.

What I'm driving at is that many times, architects are thought of as different from developers. It's true that the path to software architecture is either rooted in, or tightly entwined with, software development, but it tends to be some kind of a specialization. The reason I bring this up is because, as architects, we run the risk of separation from actual, real world, implementation concerns. By removing ourselves from the nitty gritty implementation details (a phrase I've been lazy enough to toss around in certain circumstances, admittedly) we have the potential to forget or otherwise disregard the venerable minefield that is the production environment and even the real world.

Using tools like diagrams, white boards with the nice non-smelly dry erase markers, pens and paper, and even more direct methods such as defining interfaces, we're still far removed from the underbelly. We're removed from reality both conceptually and (almost) physically; the implementation - the realization of a given architecture, big or small - is not our own. In other words, we're not subject to our own dog food. And, if you're not careful, you might end up designing for the utopian world of your favorite modeling tools. The professional term for that is screwed.

By not pushing yourself back into the role of implementor either by contributing to code directly or working closely with those dealing with your precious architecture, you are robbing yourself as well as sabotaging the rest of the team, not to mention the project. If you work in an organization where this isn't feasible you can still place yourself in the shoes of the developer, the testers, tech writers, product managers, all the way up to the end users. The impact of your design decisions are greater than just the common set of technical concerns. You are bound by the goals of the project. Your design must not only be simple, elegant, and technically correct, but it must deal with the idiosyncracies of the business, production woes, maintenance and operation teams, and so on. In fact, I'm a little sad I even used the word elegant.

I spend quite a bit of time writing code at work. I do this for a few reasons. For starters, we're just in need of extra hands; we're working on some very cool projects on tight time lines and I'm always a developer regardless of title. Possibly even more important than simply generating code, though, is the need to get things right, in terms of design. By working with the rest of the team, dealing with implementation questions and concerns, all day, every day, I'm forced to constantly reconsider what is working and what isn't. Developers are the first to trip over corner cases in the design or find awkward situations that are difficult to detect in a pure design phase. In an agile environment, the constant attention to high quality and correctness means - in terms of design - following a design through to the end, through all its transformations and anticipating real world situations.