Ted answers hard questions about what an architect is....
I read Ted Newards blog, because he is smarter than I am. You should read his blog too. Here is one of his recent posts.
Before you change the channel thinking "Oh, I hate link posts.", consider that I don't really like posts that are just links that say "hey, I just read this." I do like link posts that link to a post, and then discuss the topic. I am linking because I want to add to the conversation.
This conversation extends the first ArcReady meeting we had about six or nine months ago with Josh Homes (MS Architect Evangelist). That first event was about what an architect is, and what they do. It was a great talk, and dovetails into Ted's post.
To summarize Ted's post: Ted is responding to a reader who had a HORRIFYING interview and sent in an email about his experience. This experience drives the reader to have a crisis of faith when it comes to being an architect. Ted then answers some of the reader's questions.
The first thing this architect did was stick to his guns on HIS answers to interview questions, and not roll over easy and say what he knew the interviewer was asking for. This is awesome. Want to move to Ohio?
When I am interviewing someone, I always make it a conversation, and make it clear that not only am I trying to see if that person is a fit for us, but that we are a fit for them. I want to be brutally up front about who and what we are so the candidate can determine if we are a fit for them. Because if our vectors don't line up, no one will be happy, and that's a waste of time and value to our clients.
If you are looking for a job, and interviewing, you have the responsibility to be who you are in the interview. If you pose, then you are falsely representing yourself. That's not good.
Ted's reader then goes on about three questions. I am pasting them here verbatim to make it easier for me to respond:
- How could their idea of an architect (being the policemen of corporate best practice) be so far removed from someone like myself, who aims to make case by case judgements based on pragmatism and experience?
- Is architecture supposed to be facilitative or restrictive?
- What relevance do architects have today? Are they just overpaid, out of touch developers?
1. Ted's reader says he was a consultant for years, and as such learned a skill that native architects don't usually learn. That skill is 'providing business value'. This problem has many forms. IT isn't aligned with business (if someone says business isn't aligned with IT you should run, run, run), IT isn't agile, no trust with IT, IT is a cost center, etc.
The policeman mentality (and please, I don't mean any disrespect to law enforcement) is when a control freak gets promoted, someone who is narrow minded (they know better than everyone else), they don't have the wisdom to understand context, and don't trust/value the developers and other staff.
If you treat 'best practices' like a rule book, solid walls to constrain you, then you probably don't GROK what you are doing. If you see best practices as dashed lines, guiding you, then you are doing well. You have to understand the experience and reasoning behind a best practice to use it well, and to avoid becoming a mindless zombie to it. Zombies eat brains, and no one wants that.
2. Both. It must facilitate the delivery of business value, while restricting the risks of putting prior and future value at risk by being too divergent. One thing that native guys have learned, that consultants don't too often, is that they must try to stabilize and normalize the entire enterprise environment. They must have vision beyond the one system that is being built. Ten systems with ten wildly divergent environments does raise development and maintenance costs. Architects, in this role, try to avoid the 'spaghetti problem', and using foresight, plan out how best to deliver that value, all while maximizing ROI on prior investments, if possible. In a sense, they sit between development, business, and IT ops. All of which have different needs and goals.
3. I think, by my definition of architect, an architect is super critical today. I think an architect, as defined by the reader's interviewee, is not only worthless, but an anti-architect. An anti-architect slows IT, siphons value from the business, and inhibits conversation.
I don't think there is much room on an XP project for an architect, if that architect's job is to draw out UML diagrams, and tell the developers what to build. The architects role on a software project (versus an enterprise architect, or another type), is to draw the general approach and direction of architecture on the system, and to help the developers flesh that out in an appropriate manner. The developer should run through their detail technical design with the architect on the team. In this way the architect trusts the developer is helping to provide an architecturally cohesive system. The developer also learns a lot from the architect as well.
Comments
The comment that "...there is no such thing as ’Best Practice’ in architecture – everything is contextual." is not true. There are best practices, and good developers/architects/(dbas...) follow them. We just don't "adhere" to them.
A beginning chess player knows nothing about the principles of chess. To become a good player, then need to learn the "best practices" of the game. Don't bring the queen out too early. Castle for king safety. Control the center. But the great player's do more than memorize these principles. They have a deep understanding of their purpose, and thus know when NOT to follow them.
So, if you meet someone who does not follow best practices, as a chess player or an IT architect, they are likely either a fool or a genius. Then the question becomes whether YOU are smart enough to figure out which class they fall into.