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)

  1. 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.
  2. 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.
  3. 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?
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.

8 Comments

  • Typical whining from a developer who doesn't have a clue about the big picture in providing solution to enterprise information systems. All architects come from a coding background, but most programmers are not architects, nor will they ever become one. If anyone wears blinders its programmers yakking about design patterns, buses, and the always safe decision by committee which is the job security condom for the typical enterprise loser.

  • Heh. "A Real Architect" but someone who shall remain nameless. Sure, all architects come from a coding background (well, in theory, I've met some that didn't) but for the most part the last thing these architects coded was in FORTRAN for some mainframe system. In any case, I might be seen as some whiny developer but I have the track record in building "big picture" solutions for the past 10 years.

  • A reasonable bit of the custom work I have done over the years for clients could fall under various ad-hoc definitions of "software architecture". I think that is a big part of the problem -- most definitions are so loose, that too many things get called "architecture", too many roles get defined as "architect", and too much activity listed as (shudder) "architecting".

    A big picture is always necessary, and sometimes a system is large enough that architect is the right concept to apply. I occasionally fill that role for clients, but much of it is better described as craftsmanship.

    I believe software craftsmanship is writing software that keeps the form and function in balance with the big picture. My goal is always to be proud of my work, and leave the customer better off because of it.

  • Bil you are so right...very few real people can do it all...

  • Generally agreed Bil...

    I've seen way too many "big picture" architects over the years... Ones who cannot even remember if the underlying technology will support their "grand designs". I think the correct term for those are "architecture astronauts"

  • I hope no-one confuses this "Teach Yourself SharePoint Programming in 24 Hours" with a rather better book (!) called "Teach Yourself SharePoint 2007 in 24 Hours".

    I had a certain panic moment imagining the Amazon sales going from low to non-existent.

    Mike

    P.S. Use a For Dummies example next time ....

  • I sometimes use the word architect to describe my role to clients. Other times it's product manager, project manager, entrepreneur, or guy who sees the big picture or vision. But you are right. I know my limitations and while I push the team to consider alternatives, I know my limitations (I am not a developer) and listen to the team for guidance on what is possible and practical. You need to understand that after every sale, comes delivery.

  • I'm absolutely appalled at your inability to see how terribly important it is to have an Architecture Astronaut for every single project.

    /snark

    It's all about finding the appropriate solution for the particular problem at hand. I've seen too many people insist that, for example, Microsoft's Enterprise Library should always be used. Sometimes? Sure. Always? No. Just because you read a white paper about hammers doesn't mean that everything is a nail.

Comments have been disabled for this content.