In a somewhat comedic turn of events at recent meeting with a new client, a string of a half-dozen staffers introduced themselves as "architects" of some sort, applying varying adjectives to indicate their preferred form of architecture, but ultimately doing nothing to describe what they actually did as it related to the matter under discussion.
"Architect" seems to be what "consultant" was a few years ago: a fancy-sounding word that leaves actual job responsibilities ill-defined at best. Given this, I won't be completely surprised when my next waiter or waitress introduces themselves as my "meal architect." So, is the term actually useful?
An archetype for an effective architect
Determining the focus of the person proclaiming architecture as their discipline is key to understanding what makes an effective architect. At a micro level, many people claiming to be "architects" are simply strong technicians who formerly had titles like database administrator or developer. Self-proclaimed "architects" at this level generally have skills with specific technologies and their deployment and optimization. A database architect might be able to expound on the nuances of MySQL, but be lost in an Oracle environment. While these skills are relevant and in demand, they generally fail to take the larger view that a true architect brings to the table, and putting a micro-level architect into a role where he or she must consider a more holistic view can be dangerous.
A building architect may not be a master plumber and electrician, but he or she knows how these systems integrate within the building, and how they must be designed to address concerns about how the building will be occupied and used, building code restrictions, and ideally an elegant and cost-effective solution to combining these interrelated systems. So, too, should a true enterprise architect understand enough about critical systems to integrate them effectively, but also the business context for the technical platform and how to deliver it cost-effectively and elegantly.
With IT becoming increasingly complex, even those who can legitimately call themselves architects generally fall into two camps: business and technical architects.
A business architect can articulate the key components of a technical solution, and the capabilities enabled by each. For example, this level of architect could tell you that an enterprise marketing platform requires a campaign execution engine, customer data processing, analytics, and several other components. Returning to our building analogy, he or she is focused primarily on the use and functionality of the building, rather than the intimate details of what's behind the walls.
More technically focused architects fill the role of determining the technical systems that occupy each of the components identified by the business architect. For our hypothetical enterprise marketing platform, someone in this category could articulate the pros and cons of the IBM marketing cloud versus the Adobe marketing cloud, and key technical considerations that might drive up costs due to integration challenges.
Finding the right architect for the job
Clearly, there's a need for the three types of architects broadly described; however, when all three of them bill themselves as "Enterprise Architects" or some variation, how do you find the right skillset for the job?
In addition to your standard interviewing procedures, perform a panel interview or two with a peer from the business and technical side of your company. Present a hypothetical platform, ideally mirroring something your company recently or is currently implementing, and ask the candidate to describe how he or she would architect a solution, and the key areas that they would consider as they developed a solution.
If the candidate even deserves the word architect in their title, they'll ask about how the solution will be used, focused on the micro-level technology, a broader platform-wide technology view, or the business capabilities required of the solution, giving you a quick indication of what level they're operating at. While 10-15 minutes of an interview are unlikely to generate a complete solution, you should be able to get a sense of whether the candidate is considering major elements of the solution, and see if their recommendations broadly match what you are ultimately building, or have well-reasoned differences.
While the world has rarely been changed for the better or worse by a poorly considered job title, putting someone who lacks the right skills into a role that demands a competent designer of technical solutions is a recipe for failure. With a word as unhelpful as "architect" frequently being bandied about, it's critical for IT leaders to determine whether the architects they're hiring and placing on sensitive projects are truly up to the task.
Why data science is just grade school math and writing
Rise of the CISO: Why the C suite needs a security chief
4 lessons on how to develop a new business department
Trouble hiring a project manager? Five possible reasons why
Patrick Gray works for a global Fortune 500 consulting and IT services company and is the author of Breakthrough IT: Supercharging Organizational Value through Technology as well as the companion e-book The Breakthrough CIO's Companion. He has spent over a decade providing strategy consulting services to Fortune 500 and 1000 companies. Patrick can be reached at firstname.lastname@example.org, and you can follow his blog at www.itbswatch.com. All opinions are his and may not represent those of his employer.