Architect Role and SkillsWhat Others Have to Say about the Architect RoleThe Hard Skills are the Soft Skills, posted by Rob Daigneau on his Design Patterns for .Net site on October 20, 2005 "I was recently asked what I considered to be the three most important characteristics of a good software architect. I had to think long and hard. "How can I possibly boil it down to three essential attributes?", I pondered. I recalled some of the things that I wrote about in the articles What Does it Mean to be a Software Architect? - Part I and What Does it Mean to be a Software Architect ? - Part II. Finally I reluctantly answered stating that I thought architects should have a good understanding of the business problem domain including its general strategies and tactics, the fundamentals of abstraction and modeling both business and technical concepts, and how to assess the trade-offs involved when recommending an approach. Later in the day, after having reflected upon the question at length, I realized that I had missed a critical category. Software Architects must also be adept at the soft skills if they are to be effective in their position. Social skills are essential to success in this career path, and they are much harder for most of us techies to learn than are the hard skills like producing well written software." The Lighter side of being an Architect, posted by Bill Simser on his Fear and Loathing blog on July 13, 2006 "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:
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." When Can You Call Yourself an Architect?, posted on Simon Brown's Pragmatic Architect blog on June 7, 2006 "My first take on this was experience and confidence. I think the key thing that differentiates an architect from a lead developer is experience. That is, experience across many systems and many different types of solutions. Where confidence comes into play is that you need to feel confident in your experience to feel comfortable [calling] yourself an architect." The above post prompted this comment: "Since my post about first experiences of being an architect, as opposed to a lead developer, I've tended to think of the difference in terms of code (the clue's in the job titles!). Therefore I'd probably say you can't call yourself an architect until you've done a project without writing a line of code*! I found it fascinating to see how my thinking changed when I couldn't defer the research or design to the construction phase of the project. If you can't code your way out of trouble anymore you try to spot it in advance." Comment by Kevin Seal on Simon's Pragmatic Architect blog On the Definition of an Architect, by Mike, posted on Michael Platt's blog on March 30, 2006. "I found quite a good definition of what a software architect has to do in the audio commentary of one of the Lord of the Rings movies. Peter Jackson described how the script always changed just days or hours before shooting and he compared the script writers to someone who 'ferociously lays down tracks in front of a running train.' Software architects must ensure that their train (software project) goes in the right direction by laying down the tracks, that it stays on the rails and that it arrives at the destination in time. Passengers (programmers, managers, ...) have to feel comfortable and safe. The train should run smoothly, even in hard weather." Overly Long Guide to Being a Software Architect, by David Ing, posted on David's From 9 till 2 blog on August 5, 2005. "By the way, if you think the word 'architect' is a meaningless nonsense job [title] used by golf playing over-confident 40-somethings then I can save you some time and confidently say there isn't much in here you're going to like. Cheerio. For those that are left, it is probably wise to start off with what I mean by the term 'a software architect'. Well, the answer is unfortunately quite oblique. It really is up to you. You may work on your own, you may work in a team the size of the Ben Hur extras but you may still be an 'architect'. The best I can do is say that it's all to do with the breadth of responsibility you have for the solution. Another more evasive but satisfying way (well, for me anyway, who has to type all this rubbish in) to answer would be for you to take a look down the list below and see if most of the items means something to you and your job. If they do, then chances are you may call yourself a 'software architect' if you so desired. Alternatively you could also call yourself 'Supreme Commander of the Lesser Dominion of Greater Officetania' if you like too; I'm happy either way. Here are my top 11 bits of advice for aspiring and/or perspiring architects: (warning, this is a little long, so I'd grab a drink/snack and comfortable shoes now): ..." These tips are well done, so now you really have to go to David's blog post for the rest! You will notice that David's post reinforces what we have been saying about the architect role since 1999 on this web site, and in our training classes for more than a decade. Phantom Java Architect There is an extensive discussion on "hiring the phantom Java architect" on TheServerSide, prompted by Joe Ottinger's May 2005 post. It is interesting in the diversity of the views, and some of the posts are evidence that this transition in our field is causing some anxiety and hurt and there are bad experiences as well as good experiences around to learn from. Here is a post that complements the other posts we've highlighted by quoting them on this page: "Because you cant actually force people to do anything - especially not developers. posted on The Server Side Architect discussion by Nick on May 10, 2005 Architect As Guide, by Tom Pierce, posted on his blog titled Clearing My Head, March 30, 2006 "...it dawned on me that it would be nice if the industry placed more emphasis and value on software architecture practiced in the 'guide' style. The guide style of architecture is good for the development team because if they are less skilled, the architect can help them improve their skills, understand the system, and make better decisions. It's good for the architect because if he/she helps the other members of the development team make better decisions, the architect will be able to make a big impact through leverage. ... To me, that's one of the best things about being a part of or leading a team. Working together and solving the problem. But, the industry doesn't seem to value the guide style of architecture. Clients want up-front technical documentation and the comfort that someone 'in the know' is leading the software development effort and making good decisions. You certainly can't blame them for that. If I were a client, I'd sure ... want it. It leaves me feeling like I need to be both. I want to be the guide style architect, but I need to be the up-front, decision making architect too. It seems to me if you are around for the entire project, you can start off the up-front guy and transition yourself into the guide guy..." Back to the Phantom Java Architect Here is another useful post from the discussion on The Server Side, articulating why the architect is not just a person with technical smarts and credibility among developers: "If the architect's job is to have supreme technical knowledge of the application being implemented, whose job is it to understand the application and business process as a whole? Whose job is it to understand how the application and business process fits in with other applications and business processes across the enterprise (or across customers)? by Erik Engbrecht on The Server Side Architect discussion May 11, 2005 Do Architects Lay Bricks, posted by Simon Munro on April 28, 2006 "To me, a bigger problem than defining the term ‘Architecture’ is coming up with a better term for the technical hero on the team who is ultimately responsible for the way the the system looks, feels, smells and behaves (all within time and budget of course); more colloquially known as the Architect. When I am in an ‘Architectural’ role I find myself designing, coding, helping developers, investigating technologies, understanding the requirements, helping with testing and deployments, providing estimates, ..., interviewing resources, optimising SQL statements, and so on. It looks like those functions go beyond architectural functions and cross many disciplines in software development. I generally know the detail of how a particular business function has been implemented (even if I didn’t implement it) and can advise developers wanting to add functionality. Sounds like a bit more than 'architecture'. " Further Reading The following essays, articles, and blog postings also shed insight on the role of the architect and skills needed to succeed in the role:
Blog posts on the architect role:
Architect Salary Data
Copyright © 2006-2020 by Bredemeyer Consulting |