What Characteristics Should an Architect Possess?

I vividly remember a conversation I had with a Chief Information Officer (CIO) during a one-on-one meeting. We were talking about the state of architecture and where we both thought it would evolve. In the midst of this conversation the CIO said, “We need cloud architects.”
This was at a time when cloud computing was just beginning and while it was garnering a lot of buzz, the definition of cloud was somewhat nebulous. The company had not yet waded into the pool of cloud and there were many questions from a business and technology perspective that needed to become clearer. That was at least my impression. Since the CIO had made this statement, I probed to understand what he meant. I simply asked, “What does a cloud architect do?”
“I don’t know but I know we need a lot of them.” He replied. I was then challenged to go and find cloud architects.
I would love to say this was a unique conversation that happened just this once, but it has played out in different forms and across multiple industries. This occurs partly because the discipline of IT architecture is not well defined in many companies. As such, there is inconsistency with the role an architect plays within a project or a engagement.
A look at job listings or contemporary writings about architecture paint a broad stroke of what is expected of an architect. Even the title has gone through metamorphism. It used to be there was a single title for IT architect whereas now you will find Application Architect, Technical Architect, Business Architect, Solutions Architect, and Enterprise Architect to name just a few. The skill sets being asked for are as numerous as there are companies looking for candidates.
So, the question becomes, what characteristics should an architect candidate possess? Each time I meet with others in the industry the conversation at some point turns to finding good candidates or how do we create a feeder program to develop architects in house to fulfill the needs for architects.
Most time the responses center around technical platforms either current or future that the company needs help with. When approached this way job descriptions begin to read like a buzz word souffle. A dash of this technology, a sprinkle of that infrastructure, and a pinch of that methodology. Bake at high stress and heat being careful not to overcook and cause burnout. In some cases, these descriptions include a photograph that is designed to look appetizing but in reality, was posed by a product stylist with the real product being inedible.
Often times these job descriptions are a result of listening to the hiring or influencing manager as they read off the laundry list of things their organization needs to get done or a wish list of skills that they would like to have in their back pocket in case a customer approaches them with a new opportunity.
I won’t argue that many successful architects do have technical backgrounds born out of the fact that a lot of these individuals have organically grown out of the development or engineering disciplines. Having this technical background helps them to relate to the technology side. This is only part of their job duties and I would argue it is or should be empathized less.
We need to begin focusing on what I believe is a more important skill set for an architect to possess and grow. That is, the soft skills or human side of the equation. An architect needs to have exceptional communications skills. They need to be able to listen to technology partners and business proponents and bridge the gap between these to diverse dialects. They need to be able to cut through the technical jargon and describe the objectives in common terms that maintain the technology message without sounding like stereo instructions. From the other perspective they need to be able to listen to the business stakeholders and help them articulate their needs in terms that the technology teams can formulate into functional requirements.
Architects should be the information technology equivalent to diplomats. Their job function is to bring sometimes warring factions together to negotiate a cease fire so each group will feel they are being heard and understood and that both parties can agree on the goals and deliverables and more importantly the success criteria the project will be measured against. In many cases this is a much different skill set than what is on the job description.
An architect should have the ability to facilitate discussions and set ground rules for what needs to be accomplished. They need to give each group time to explain their challenges and opportunities. The architect needs to be able to read a room and understand who the players are and more importantly who the proper participants are for making decisions.
Architects need to be empowered to broker deals between the interested parties to make sure that everyone has a clear understanding in common terms of what the project or engagement will deliver. Architects need not be the smartest people in the room. They need to be the most empathetic people who have the best interests of all parties in mind.
Architects must be able to read a room. By that I mean they need to have excellent observation skills to understand not only what is being said but more importantly what is not being said. Often times during a meeting there is an underlying message that everyone is skirting around but needs to come out to ensure the project will be a success. Reading a room also helps an architect understand who the real power brokers are for gaining consensus. These don’t always correspond to project or organizational chart roles.
Notice there was very little mention of technical skillsets in the above paragraphs. Based on personal experience, good architects have one thing in common; they are passionate about creating valuable and lasting solutions.
Technologies are in a constant state of change. During an architect’s career they are probably asked to help with technology and business decisions that have a multitude of technical components most vastly different from the technologies they knew when they started their architecture jobs. That’s not a bad thing, in fact it strengthens my viewpoint.
Most architects are driven by continuous learning and enjoy trying to understand new technology. For most of the senior level architects who have had a longer track record in the architecture job family you can hand them an assignment that may include technologies they are not completely familiar with and those architects will do research and learning so they are prepared to have technical discussions with the appropriate parties.
An architectural engagement’s success hinges more on whether the architect can build consensus between the business and the technology sides of the house than it is around understanding the nuances of a specific piece of hardware or software.
There are of course roadblocks to this skillset paradigm shift. The first of those is an internal reflection by the organization or company to sit down and accurately describe the role of architecture. In many cases architecture has simply grown organically out of another discipline without proper definition.
Going back to the CIO who stated we needed a lot of cloud architects; we had several subsequent discussions of what we both felt was the right emphasis for architecture. We developed a mission statement for what the company needed from architects and architecture. We then communicated this new mission with the various customers and stakeholders until we had buy-in from all parties of what the boundaries of architecture should be. With this new agreed upon charter we established metrics for measuring architecture success and defined guardrails to make sure architecture was not overstepping their boundaries while delivering value.
We ended up not hiring any cloud architects at that time instead using the funds that had been allocated for additional headcount to create an education plan for making our architects more effective and designing a blueprint for developing better architects that can successfully lead an effort.