IT Architecture is the evolution of a career, in that it takes years of experience designing, building, and rolling out systems that match a set of criteria. The hardest part as I have detailed in previous posts is not the technology however, but matching the technology to the requirements. Knowing which questions to ask at the right time, so that you can flush out more from your clients and customers than just a set of screen shots, or a bullet point list of hardware requirements. The Architect must take a broader outlook then this, always having in the back of their mind what other factors could be impacting the solution, or strategy that have not been communicated.
I recently posted this question on LinkedIn and got a few key responses I wanted to highlight here.
IT architects are visionaries, coaches, team leaders, business-to-technical liaisons, computer scientists, and industry experts. – OpenGroup.com
I believe that a crucial role of a Solution Architect is to act as the link between business stakeholders and technology experts. You need to exchange ideas effectively with both groups and need significant technical and business understanding for this to be possible, without necessariy being an expert in either area yourself. Typically, architects come from a business background and acquire technical knowledge or come from a techincal background and acquire business understanding. In my experience, the latter case is more common and architects are therefore more likely to lean to the technical. – Paul Harris – CRM and Integration Consultant
In short, the Architect is the only guy in the room who has decent street cred with the Development and Marketing folks. He’s diplomatic and savvy when it matters, and can think very critically about architecture and applying technology where it counts. AD Kent – Managing Partner at DocuConsulting
As all three quotes explain, the Architect is the link between business and technology, which means that he or she has to be able to communicate and build relationships with both sides. For instance, if the Architect is in a meeting with the CFO of an organization, project and operational cost are important. It is important to communicate how the given project or strategy will cut costs to the organization. If you don’t know hard numbers, be prepared to at least communicate in terms of hours spent in the current environment to generate output, and how a new architecture, system, or solution, will cut that down over time. Many CFO’s can calculate simple math in their head, and when they hear “reduction in hours to produce” they know your talking in terms of savings to the company. The better your statistics are, the more inclined they are to support your initiative.
This conversation is completely different than the one you would have with engineers and developers. When communicating with these folks, you must similarly direct your conversation to something that matters to them. Performance, Design, Quality, Extensibility, Importance to the organization, are all characteristics of an Architectural knowledge base. It’s also important as the Open Group states, to coach, mentor, and encourage your teams as part of the production endeavor.
So in short, the answer to the overriding question is yes. The Architect must be someone who can operate with many different hats and gain the respect of peers, those reporting to them, management, and even sales and marketing. This is often a result of many years of experience in all facets of business technology, and a general understanding of what each component of the business requires to be successful.
