Understanding Your Enterprise Architect: A Guide for Managers

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.

3. Run blocker for your EA.

One of your EA’s toughest jobs is moderating personalities while trying to design out redundancy and ineffective processes and systems. Frequent checkpoints are an opportunity for the EA to identify bottlenecks and hurdles. This is key. Do not make your EA be his own blocker if you want him to succeed.

While you probably never wanted to play “bad cop,” this is your new part-time job now that you have an EA. Establish trust with your EA. Let him know it’s safe to come to you to discuss a difficult individual or a festering problem without fear of repercussions or reverberations. Your EA can handle the message, “We know about that system, but we have no budget to replace it in the near future.” He will move on and focus on areas where he can make headway, knowing he relayed the problem area to the people with the power to do something about it.

Yet, any EA worth his salt will harp on politically-charged issues when they affect overall corporate performance, which can lead to political suicide. You don’t want your EA becoming so sensitive to politically-charged issues that it affects the outcome of the work product.

4. Don’t expect your EA to drive the business.

I once had a CEO ask me what I recommended with regard to next-generation architecture. I explained to him that it’s not my job to tell the business what to do. I asked the CEO to explain what he wanted to achieve, by when when he wanted to achieve it and how much money he was willing to put down to make it happen.

I don’t believe he liked that answer too much. Still, the point is important. Your EA is there to create a master plan for the interactions of all your systems and associated resources to meet the business’ goals. EAs are not hired to create solutions in search of a problem.

5. Your EA is not just the über-tech-geek.

In order to be effective, your EA needs to make recommendations that affect systems design, resource allocation, processes and organizational structures. The EA is the master architect of the people, process and technology mantra. If you lock your EA’s role into only being permitted to make recommendations regarding process and technology, you are missing a critical component and eventually it will come back to bite you. For example, citing ways to reduce expenditures through process optimization in billing may require that 40 percent of billing clerks be replaced by an automated system. You need to make your EA feel safe that she can make these recommendations.

I suppose it would be useful to describe what should be in the plan described in my first point. First, it should include an explanation of why the company created this position. Cite examples of past problems that you believe could have been avoided with a good enterprise architecture. (If you can cite examples that are not confidential, this list is also a great tool for interviewing candidates.) Put in a concise definition of the business’ purpose. That is, what does the company do and how does it make money. Define the key business initiatives for the current year and, wherever possible, relate the initiative to expectations of delivery for the EA.

Unfortunately, you cannot know what you don’t know, which is why you are hiring this person in the first place. Thus, a key deliverable should be to create a high-level design of all the current systems and the integration points currently in place. It should include a set of recommendations by the EA that incorporates the business goals. For example, if cutting expenses is a high-priority goal, then the recommendations may be related to modification of hardware infrastructure as well as changes in the current to IT operations size and processes. Remember: your EA is simply a reflection of the goals of the business.

Proper care and feeding of your EA is imperative to his or her success. If you follow my advice, your EA will have a long and prosperous career with your organization. As a result, you will reap the benefits of focusing your IT efforts to reducing end-user frustration and increasing productivity.

JP Morgenthal is a leading independent IT architecture consultant in the Washington, DC region who focuses on enterprise architecture, SOA, BPM and cloud computing. He is an authority on XML, Java, SOA, EAI and EII. He has written three books on integration, the most recent Enterprise Information Integration: A Pragmatic Approach.