The Lighter side of being an Architect

I wasn’t sure what to call this blog entry so maybe it’s mis-titled. As odd as it may sound, this entry stemmed from a conversation that’s going on over in Rory’s side of the web where he praises Carl Franklin on his community efforts. I threw in my own “praise the world” type comments, but there was a link to a site called Design Patterns for .NET. This of course peaked my interest, but some of the comments Rob Daigneau made about what is a software architect triggered something in me noggin.

Everyone and his brother has written what a software architect is (and is not), comparisons abound on how software architecture is like building architecture, blah, blah, blah, blah, blah. I don't know what Rob Daigneau is (other than an Enterprise Architect for Monster.com, and after this post I can probably kiss any hopes of working for them goodbye), but he misses out on what I think is the key elements of what software architecture (and Architects) is about.

It's really not about patterns and technology. Really. Sure, they're an integral part and any good Architect needs those skills but they're just mechanics. Anyone (with the right aptitude) can pick these up (how do I make pretty UML diagrams, what is n-tier, etc.). IMHO the key things architecture is about is:

• Communication
• Abstraction
• Negotiation
• Influence

A good architect excels at these attributes because they have no power, only persuasion to influence, and they need to know how to communicate what they're thinking so everyone understands them. I wanted to present my take on some things that make up a good Architect.

Communication
Everyday the architect on a project is trying to tell someone something. You’re the liaison between the business and the geeks. You’re the instigator of change. You’re the guy who’s trying to demonstrate to the client that before they sink $5 trillion dollars into this IT project the concept is sound and the team can deliver what the business wants. You’re also the guy (or girl) who’s telling the business that you’ve heard what they want and think you know what they said. The rubber hits the road when you tell the story back to them and see if you were listening correctly. Finally, your the guy who’s trying to bring the stone tablets down from the mountain to the nerds who are going to build this monstrosity you’ve architected. Somehow, using a combination of knowledge of the requirements, kung-fu coding skills, and an understanding of your model, they need to create it. Yes, even if you are building your own system (I like Architects who code and I would like to think I’m one of them) you need to know the intent of what you’re building. Drive by coding and architecture on the cuff because you’re stuck down a dark Architectural alley is no way to build a solid system.

Abstraction
We all know there’s abstraction in the domain and I’m not really talking about coding abstractions here or implementing interfaces for unit testing. I’m not even talking about technical abstraction (from an infrastructure perspective). No, this kind of abstraction goes hand in hand with your ability to understand the business requirements asked of you. And your ability to Architect a solution that meets those requirements. Something that does incorporate the technology you need and solve the problem at hand (whatever that problem is). If you’re too close to trees to see the forest, how can you really see the big picture of what needs to be done? I’m also not talking about big design up front (BDUF) or anything. Just simply being able to abstract yourself away from the techno-babble the geeks of the world will get wrapped up in and the little nuances the business wants from a solution perspective. It’s nice they want blue buttons and an user interface that’s “intuitive” but if you’re not solving the problem asked of you and reaching the overall goal with the entire solution, what exactly are you building? A great looking UI that moves data around? Where's the business value in that?

Negotiation
It’s all about compromise. There are so many times you’re going to have to hold your Architecture nose because of the horrible smell you’re about to create because some network junky says you can’t have unsecured traffic over HTTP on port 80. You can come up with an architecture for a system that is technically perfect, but you have to live within the constraints of whatever infrastructure you build it on (or in). Corporate intranets and network security paranoidites are out to lock down and otherwise curb your seemingly elegant solution. For this you need to be able to compromise and find a balance. For this you need to negotiate. Sometimes it with the technicians who refuse to punch a hole in their firewall just so you can get FTP traffic flowing, other times it’s the customer who flatly refuses to back down on the sub-second response they want (without paying for the infrastructure upgrade needed to make it happen). There are negotiations to take place and through your bargaining skills, you’ll find that sweet spot that will make everyone happy.

Influence
There is no power. If you, as an Architect, think you have the power to move things and leap tall requirements in single bound, think again. The customer is always right, and usually holds the dollarinos that feed your family. They’re not going to care that you think a SmartClient n-tier approach to solving their problem is better than a 3–tier application with a web front-end. They just want to do their business. And power over the developers who are building this thing? That’s an entirely different influence you have to master, since they look at you as a techno-dweeb who can barely code your way out of a paper bag. Not even the coolest looking UML or class diagram (even if there such a beast) is going to persuade them that your kung-fu is any better than theirs. Bone up on how to influence people. There are many self-help books out there that are good for this.

Now a few things about this post. I don’t get into the differences between the various architect flavours out there. Software, Solutions, Data, Enterprise. An Architect is an Architect is an Architect. The core skills are there for all of them, the media and technical skills just vary.

Well, maybe I’m the one that’s completely off my rocker here but these are my views of architecture from the software space and it’s my blog and I can rant if I want to, so there. YMMV.