Hiring enterprise architects: How to find great manufacturing candidates

Hiring an enterprise architect is difficult. Anyone being considered for such an important position needs a wealth of knowledge and experience in the field. Yet, knowing what's required and having adequate work experience are only part of the equation. There's also the question of fit.

Determining if there is indeed a fit can be tricky, particularly if the work involves a high degree of creativity. One person can be highly effective in one team and a drag on another. It's akin to a theater ensemble. Some actors gel just right. Others degrade into continuous conflict and the quality of the production suffers.

Making a determination about fit and creative compatibility goes beyond reviewing a resume or having the candidate respond to questions during an in-person interview. At some point, candidates need to demonstrate their abilities. In the performing arts, this type of demonstration is called an audition. For enterprise architecture, it's a scenario.

Understanding the behavioral-based interview

In the first article in this series, I described behavioral-based interviews, in which a candidate for an enterprise architecture position is presented with a predefined scenario and asked to create an architecture that satisfies its needs and conditions. The exercise's goal is to gain direct experience with how the candidate performs.

Any scenario can lend itself to a wide variety of solutions. Thus, evaluating the response is not about seeing if the candidate provides the "right" answer. The goal is to see if the candidate can create a solution that makes sense both technically and in terms of business drivers.

Some companies allow candidates to take their time and work on the scenario from home. Other companies ask the architect to respond to the scenario in a few hours on site. How much time gets devoted to the process depends on the company. Obviously, the more time you can give candidates to do the scenario, the better your insight into their skills and thinking process.

[ You might also enjoy 5 enterprise architect interview questions to ask ] 

This article provides a scenario intended for enterprise architects in the manufacturing sector. The scenario is followed by some commentary about how to evaluate the candidate's response. Remember, this is not about getting the right or wrong answer. It's about gaining insight into the candidate's skills as well as their creative and thinking process.

The interview scenario: Manufacturing

A small contract baking company named BakeCo is about to be acquired by a food service conglomerate, AlphaFoods. BakeCo manufactures baked goods for supermarkets and specialty stores sold as private-label products. BakeCo's annual sales are around $50 million. It employs 250 employees, and most employees are engaged in direct manufacturing activities.

One of the conditions of the acquisition is that BakeCo modernizes its IT systems to reduce the integration costs into AlphaFoods' systems after the purchase takes place.

Presently, BakeCo's IT systems are a hodgepodge of technologies. Invoicing, accounts payable, and accounts receivable are managed on QuickBooks. An independent payroll service handles payroll. Inventory is managed with a custom system written in Visual Basic using a SQL Server database to store data. Purchase orders are still created using paper forms. The forms are then scanned and stored in a network drive. The company's purchasing agent logs into each supplier's website to order supplies using the purchase order number printed on the paper PO as a reference. The recipes used for making a customer's products are written in Word documents and stored on a network drive. Also, there are a variety of Excel spreadsheets created by employees to fulfill specific tasks. Some of these tasks are critical to the company's ability to operate.

Image

The acquiring company, AlphaFoods, accepted the hodgepodge nature of BakeCo's systems. Its fundamental requirement is that BakeCo's systems need to be exposed via a set of REST APIs that AlphaFoods' systems can access.

Your assignment is to design the REST APIs that will expose BakeCo's systems. Also, you need to define the architecture that will realize your API design. Your plans need to include the physical implementation of the architecture along with the associated costs and implementation timeline.

Evaluating the candidate's response

The essential purpose of this scenario is to determine how a candidate imagines an architecture that enables a small company to unify its business systems in a way that allows it to expose the new system to another system as a REST interface in a secure manner. And this work needs to be done with particular attention to budgetary constraints.

BakeCo is a small company with US$ 50 million in sales. This is not a company with vast financial resources. Thus, the architect needs to know from the start how much money is available to do a system transformation. The budget can be set as an assumption. If so, the interesting thing to note in the interview process will be the logic the architect uses to arrive at the assumption. All future work should proceed in terms of that budget.

Another point to note is that BakeCo has a lot of legacy applications that are using older technologies. The candidate must address this reality head-on, in part by demonstrating an understanding of all the older technologies at an acceptably detailed level. Also, the candidate should be able to distinguish which of the older technologies can be converted using existing tools and products and which will require custom work to facilitate the transformation. In addition, they should be able to articulate the risks that go with any approach and provide a mitigation plan for the identified risks.

Then there is the problem of encapsulating the company's system in an organized, secure manner to expose it via REST. There are a variety of ways to do this. The candidate's approach must be comprehensive with special attention given to performance and security while also demonstrating the capability for the new system to scale up or down to satisfy present and future demand.

Lastly, the candidate needs to be able to present a viable timeline for implementing the new plan. Also, they need to be able to describe the personnel that will be required to maintain the system—both in terms of skill and cost. A variety of designs can satisfy the conditions in the scenario. The important thing is that all the key points, in terms of technology and the business, are addressed.

[ New research from HBR Analytic Services—IT talent strategy: New tactics for a new era ]

Putting it all together

To use another analogy, you can talk about playing the guitar all day long, but at some point, you've got to pick the instrument up and prove you know how to play it. This is as true for hiring an enterprise architect as it is for hiring a musician. At some point in the interview process, the candidate needs to actually do enterprise architecture. Otherwise, you're running the risk of hiring someone who is all talk, no matter how good their resume looks or how good their references are. As they say, the proof is in the pudding.

Hopefully, you'll find that having candidates create solutions for a predefined scenario is a useful technique to add to your company's hiring process. There's little downside to taking a scenario-based approach. To not have candidates demonstrate their abilities is an option you accept at your own peril.

Future articles in this series will present scenarios for enterprise architects in the healthcare and telco industries. If you have expertise in another industry to share with our readers, please consider writing an article about it for Enable Architect.