Daily motto (not just for architects) - "Aim for success, not perfection" Dr. David M. Burns
Unfortunately our industry in general has no clear definition of an architect. Many companies struggle to define roles and responsibilities of architects and are never successful.
What is an Architect?
Architect Types
According to Mark Richards' experience and fairly thorough industry analysis there are 3 general architect types. The distinctions are best summarized by the diagram below. For example an Enterprise Architect is expected to still be technically knowledgeable but the emphasis of this position is on technical breadth (rather than depth), business domain knowledge, communication and leadership.
Architect Responsibilities
Everyone knows what programmers do and even tech lead's responsibilities are more or less obvious. Saying that architects architect is the easy way out, is a recursive definition and is thus invalid. To begin with the best definition of what architecture is I ever heard is that it's something that is really-really hard to change. For example, the choice of programming language, the architectural design (SOA, event-driven, etc) and to a lesser degree the choice of frameworks and such is architecture. So what does an architect do on a daily basis? Does he sit and ponder these complex decisions (which you don't have to make very often)? An industry survey of actual architect responsibilities and expectations across many known IT companies came up with the following list.- Analyze technology industry and market trends
- "Sell" the architecture process, its outcome, and ongoing results
- Analyze current information technology environment to detect critical deficiencies and recommend solutions for improvement
- Define the principles to guide technology decisions for the enterprise
- Design and direct the governance activities associated with ensuring compliance with the architecture
- Exposure to multiple, diverse technical configurations, technologies, and processing environments
- Exceptional interpersonal skills, including teamwork, facilitation, and negotiation
- Understanding of the political climate of the enterprise and how to navigate the politics
Architect Skills
According to Mark there are several key skill areas for any architect. I will not cover all of them equally because I think some of these are understood much better than others. I will mostly concentrate on the underestimated category of Leadership and Communication.Leadership and Communication
I will bombard you with some quotes here (straight from the presentation) as I think they get the point across quite nicely. I have to add that these leadership skills are important and relevant to almost anyone and are not restricted to architects only.One of the key aspects of architect's job is to talk to business and translate their needs to technical decisions. See if you can translate following typical business requests into technical and architectural decisions
A great example given by Mark was of one famous Lockheed aircraft designer. He was asked by DoD to create a lightweight fighter capable of 2-2.5 Mach speeds. After he asked why, he was told that it needed to be fast to escape a fight if need be. What was designed in the end is a very light and maneuverable aircraft that was not, however, capable of 2 Mach speeds. Nevertheless, clients needs have been achieved and F-16 remains one of the most used fighter aircrafts today.
An interesting opposite example by Ted was about Edwin Armstrong - the creator of FM radio. He unsuccessfully tried to sell idea to RCA and eventually saw no personal gains from his discovery. The point is that it's not enough to come up with a brilliant idea but you also have to be able to "sell" it to business.
However, talking to business and leading technology folks does not mean that architects do everything business says.
To summarize an architect should be able to speak both Business and Tech language and clearly explain to either camp the reasons and trade offs behind all decisions while maintaining a pragmatic and feasible approach to decisions making.
Interestingly, the social aspect of programming was one of the main points of the Keynote by Ted Neward and there was a whole presentation (which I did not attend) about Communication Skills for Knowledge Workers by Neal Ford.
Domain Knowledge
I think that there's mostly a universal agreement that architects need to be able to communicate in domain-speak. Here are a few examples of why it is necessaryTechnical Knowledge
Any, and especially enterprise, architect needs to have technical breadth. But what is breadth? After all you cannot know everything. On the picture below it is the top two portions of the triangle. Although it is hard to know a lot (the top portion of triangle), it is possible to know a lot of what you don't know (the middle portion). That still, however, requires constant reading, attending conferences and mingling with colleagues.
