Thursday, March 12, 2009

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.

4 comments:

Shunya said...

Thanks for this post. I believe every pseudo architect should read this. At my workplace there are people claiming to be architects but they lack practical aspects of implementation which you have mentioned in your post.

E. Sammer said...

@Shunya:

Thanks so much for your comments! I don't quite know how to fix the case where architects remove themselves from implementation. It's sad when it happens and it ultimately hurts the project. Hang in there and good luck!

Constantine Vasilyev said...

You are making a very good point. Can't agree more. In my opinion, one of the main reasons for such artificial and dangerous separation between "architects" and actual development is caused by the "corporate ladder". Realistically, I believe that any good developer must be an "architect" - to a certain degree, and any good architect must be extremely hands-on and capable of visualizing implementation details whenever necessary. The problem is that companies don't just have a position of a "Really Good Software Engineer." Companies distinguish between developers and architects, and it is very much reflected in salaries. So, companies really shoot themselves in the foot by often creating environments where the most political or smooth talking but not best SEs move from being a "developer" or "Sr. SE" to an "Architect" position. I have voiced these concerns many times, including in my blog, but it's really a very common problem that will not go away anytime soon, I'm afraid.

E. Sammer said...

@Constantine:

Thanks for your comments. It's scary to think that a software architect would become so detached as to not write code or even see the implementation details. I tend to think you're right though; it is sadly common, especially in larger organizations where roles are increasingly more specialized.

Thanks!