The Anti-Architect
I'll come out of the closet for a moment as I become a little more jaded in life and bitter this holiday season. I'm an Anti-Architect. I'm all for software architecture as the alternative is let some guy who read "Teach Yourself SharePoint Programming in 24 Hours" unleash onto an Enterprise solution and then have some high priced consultant come in and clean up the mess (or the guy that created the mess *was* a high priced consultant and now you need an even higher one to fix the problem) but while I'm an Architmatech in some sense of the word, I'm also a developer at heart and a creator in essence. I'm a little bit Country, I'm a little bit Rock and Roll.
I was looking over some of the dated material on Microsoft's Architecture Certification Program and found their role definitions here. One of the issues with the IT world is that MSFT publishes some white paper, document, or scans a napkin and IT managers flock to it like flies on dung, spouting as the Gospel and Word and declaring that everyone follow it blindly. If Microsoft wrote it, it must be right. Right? Maybe. Some stuff they get right, others they're way off base.
Here are my top 10 reasons into what makes an Anti-Architect (for lack of a better term)
- Live, breathe, and eat technology through knowledge and experience every day. Just because you're labelled an "Architect" (big or small "A") get coding! Keep your wits about you with modern development approaches and open the door to new stuff.
- Don't make key technical decisons on a project when you don't know the day to day operations of system internals. Things change and the world doesn't sit around waiting for you to catch up. Keep sharp and be real about what is happening.
- I'm a propenent of minimalism and like to keep things as simple as possible. Playing buzzword bingo with your client just cause unnessary headaches for developers. Put your developer shoes on when talking architecture and think, what would I do in this situation?
- Negotiation is your key asset and skill. Use it wisely and strike a balance between technical complexities and business needs and decisions. You're no good to a team if you're sitting in an ivory tower spouting words of wisdom that favour the nerd in you. Don't be proud of the technological terror you're about to create.
- Perspective is prime and the world is a prism. Looking at things with blinders on just makes limited decisions and paints a team into a corner. Be open to suggestions from everyone and weigh those ideas against the goal. It's like the symbol of Justice (no, not THAT Justice) with the blindfold on. Any idea is possible until it's validated against the constraints that you might face. And even if there are constraints driving you down a path, stop for a moment and do a sanity check to see if the path is really forcing you to make decisions or you're the one paving the road.
- There is grand design and there is reality, and never the twain shall meet. Going back to simplicity and the YAGNI principle, try not to force some design pattern down everyone's throat. Keep repeating to yourself simple; change; stable and guide your decisions against them.
- Don't become the Bus Factor. If you get hit by a bus, can the system continue? Spread the knowledge and wealth and be transparent in decisons. While you might be positioned as the authoritive decison maker, input from the team is invaluable and needed to sustain the life of any software system.
- Design by committee doesn't work, but neither does the dictatorship model. Be the guiding driver behind decisions as you've apparently got the knowledge but don't decide in a vacuum. Key architectural decisions should be vetted with the team so not only you can be aware of scenarios you didn't think of, but the team is involved in the game.
- Filling out documentation for documentation sake is for the birds. My principle is to document what you need at the appropriate time of communication. If you have to present an idea to the team in order to understand it, that's when it might become concrete (whiteboard, Visio, code, etc.). Don't covet the world's knowledge in your head.
- Know your limitations and relegate to your peers when you're out of your league. Not everyone knows everything (unless your name is Scott Hanselman) so making decisions on say a SharePoint installation when you don't know SharePoint is just wrong. I call this the Life Preserver clause. Don't be afraid to call out to the lifeboat and have them toss you help when you need it.
These are some ideas around being what I call an Anti-Architect. Use them as you see fit, YMMV.