Understanding Your Enterprise Architect: A Guide for Managers
An enterprise architect can help your company make connections throughout your organization's technical and business communities. But only if you understand how to set the stage for effectiveness--and that begins before the EA's first day of work.
Tue, February 03, 2009
CIO — You've spent months considering the right person for your open requisition for an enterprise architect (EA). You've had the job candidate meet with representatives from the business and IT, you've extended a job offer, he's accepted it—and now your new enterprise architect will be joining your company. Since the EA is typically a senior role, this is a highly-visible hire and you want the EA to be successful for the company's sake and for your own. Thus, the next step is critical.
Here's a guide that will lead to success and happiness for all involved in this new venture:
1. Establish clear goals and expectations before day one.
Before your EA shows up for his first day of work, talk with the business leaders and IT leaders to learn the organization's expectations of this individual. Does the business expect this person to fix broken processes and remove the bureaucracy? Is the application development team already questioning you on the EA's authority over their implementations? If you get a sense of exaggerated or conflict-ridden expectations, you can bet that your EA, if he's good at what he does, will see this by the end of the first day. Then you have a third party's expectations to manage.
I recommend that you discuss the EA's deliverables with key individuals in the organization. Let him know what you, as the EA's manager, expect from your new hire. If those key individuals have issues with your plan, let their concern circulate through the proper channels. This is not an exercise in political correctness. You are embarking on a critical hire that will most likely impact these individuals' jobs. It's important that your EA knows that these goals have been vetted and that everyone with a gripe has had the opportunity to be heard. If the issue is of real concern to anyone but the person raising the red flag, you will get ample opportunity to explain your point of view, hear alternative views and come to an agreement prior to your EA's start.
When you meet with your EA on the first day, present him with the final plan. By now, it has the acceptance of the organization.
2. Introduce the EA to the key players at a single meeting, no later than day two.
Chances are, your EA has been around the block a few times and has considerable experience. He doesn't need to spend the first days dallying about his office (cube? heaven forbid!) "getting adjusted." An EA who has reached this level is aggressive on problem solving and will want to land running.
Do not squash this enthusiasm. It will raise all sorts of flags in the eyes of your EA and bring about buyer's remorse. Harness the EA's enthusiasm, but channel it appropriately. Establish a meeting of all the key players and the new EA no later than the second day. Make sure that the expectations for the relationship with key players are stated right up front. For example, "Jim, Stella is responsible for managing all telecommunications systems in the company. We expect you to work with her to design improvements in customer service operations."
Do not send the EA on wild goose chases to find key individuals for themselves. Moreover, do not place them in the position of figuring where their role ends and another's starts. Enterprise architecture has many tentacles and will touch many areas of the business. Hence, it's easy for the EA to step on someone's toes and not even realize it. This tends to create the antibody-effect working against the EA.


