Software Architect. At least that's what is says on my last business card. Senior .NET Architect if you looked at the web site. It seems that this is becoming one of the hottest job title buzzwords, especially within the Microsoft community; but what does it actually mean?
It's certainly up there in that realm of questions that have about as many answers as there are respondents; although, I believe that's changing as more focus is placed on this much needed position within organizations.
I was gazing up into the beautiful blue sky pondering this very question this morning (OK, it's actually morning-ish...well, alright, technically it's in the afternoon, but my internal clock was reset by a bout of the flu) when it occurred to me that software architects are the people who make a living by working at the very intersection of business and technology.
A software architect is one who has mastered enough of both the business and technical domains to stand in the gap (in many cases, what seems to be a very great divide) between those who are responsible for running the business and those who perform the magical technical incantations behind the scenes so that the information of the business is handled effectively.
I realize there are others who are close to this gap. The product manager for a product being developed either by an independent software vendor (ISV) or a consulting company must stand in this same space, but they seem to stand more to one side. On the other side, you have LOB managers or business analysts who think more from the business perspective, but who are trained in the proper linguistics and special arts required when speaking and negotiating with representatives from the technical crowd.
Though there are others who work in or close to this gap, architects are distinct in at least one aspect of their job responsibility. Unlike the business stakeholders, product managers and business analysts who speak to one side or the other of the gap, the software architect is unique in his/her responsibility for providing guidance and establishing specific means of governance in both directions.
An architect must learn to communicate with the key business stakeholders and in so doing must learn to value key business issues related to technological decisions, issues like ROI and cost/benefit or risk/benefit ratios. The architect needs to either know the enterprise architecture (EA), either through documenting the EA themselves or through communicating with other architects in the organization who are responsible for managing the EA.
From the technical perspective, the architect must have enough experience with a wide variety of technologies to allow them to quickly sift through the never ending stream of new technology and make important technical and business decisions such as whether to build or to buy, or maybe to extend an existing open source project.
And that’s just from the technical and business perspectives. There’s also the expectation that the architect has enough experience as a manager to know how to motivate other managers--on the business side to manage necessary changes in expectations or in process improvement, and on the technical side to encourage product and project managers to create a fun and productive environment for the technical staff.
Of course, one size does not fit all. I like the way Microsoft categorized the different kinds of architect you might find in a variety of organizations.
- Enterprise Architects are typically employed by a large organization and focus on the EA. A CTO would function as an enterprise architect.
- Solutions Architects are typically consultants hired to function as an architect for an organization.
- Infrastructure Architects are typically employed by large organizations to oversee the business and technical issues related to operations.
- Product or Depth Architects – are typically responsible for the implementation of a specific product within an organization. They are often consultants who represent a consulting company or an ISV.
If you’re like me and you’re interested in growing your skills on both the business and technology side, here are a few resources I would recommend.
- Every book or resource on design patterns and best practices you can get your hands on. For design patterns, I highly recommend Head First Design Patterns (Head First)
. - Good books or training material on managing software development projects. I highly recommend studying and using some flavor of the MSF Process. I just finished reading The Mythical Man-Month.
- Start a business of your own. This is a different kind of resource, but one that's invaluable to those of us who don't have an MBA. There's nothing like experiencing the challenges of being a business owner to help you understand how important good business decisions are for your customers.
- Subscribe to Microsoft's free (at least it's free as of writing this in July of 2007) publication for architects: The Architecture Journal.
- Create a user account at Microsoft's new site for architects and those aspiring to become one. It's called Skyscrapr.
- Hone your communication skills by taking courses on communication, reading books and giving presentations whenever you can. If you haven't already, join your local Toastmasters. Excellent oral and written communication skills are essential for a software architect.
I'm interested to hear from you! What resources have you found to be useful in your quest to grow as an architect?