Building & Managing the Virtual EA Team

There is no question that, in theory, a successful EA program can have significant positive impact on the enterprise. Why, then, do so many enterprises struggle with achieving success? In many cases it is because too much attention is focused on execution and not enough on the people involved in the program.

As with any endeavor, it is critical to create a workable structure and engage the right participants. In EA, that means building an effective EA team. With many variables to take into account, including organizational size, corporate culture, available skills, executive support, EA maturity and resources, many enterprises struggle with the details of structuring their ideal EA team. It is a challenge because there are so many roles to be played and so many diverse skills required. Ultimately, the EA Program must engage a surprisingly large community.

While there is no single team configuration suitable for every enterprise, there are specific characteristics that every team must possess. A dynamic, layered, virtual structure is one such defining characteristic. While a well-developed, properly structured and skilled EA team can still fail, no EA program can ever reach its maximum potential unless the team is solid. That team must be able to provide the vision, define the work effort, guide contribution, and be instrumental in helping the enterprise follow the architecture. Building and running a strong EA team requires finding answers to the following questions:

• What skills are required on the EA Team?
• How should the team be structured?
• How should the team manage itself and its work activities?

Skills for the EA Team - Diversify!
EA team skills sets are complex and multi-layered. Not only must the team produce EA content, they must be visionaries, coaches, sales people, evangelists, and leaders. In brand new EA teams it is common to see members drawn from the best subject matter experts available, usually engineers with comparatively narrow focus. A common mix includes several solutions architects, a couple of technical architects, and perhaps a data or process architect. Teams with that structure excel at investigating new technologies, selecting non-controversial standards, and providing design guidance to projects. If that is the vision for the EA team, then this skills mix will be adequate. If, on the other hand, the team aspires for more, that skill set will rapidly prove to be insufficient. The minute a new decision on a technology direction becomes controversial or there is a need to fulfill a new business vision requiring larger-scale or long-duration, enterprise-wide directional change, this narrowlyfocused team will find itself unable to perform. A much richer skill set is required.

While detailed domain expertise is important, it is not the most critical skill set required in the EA team. Far more critical are the skills of the enterprise architect - roles performed by the individuals tasked with contributing the enterprise perspective to architectural directions. These individuals operate higher in the abstraction “stack” and are concerned with how the various piece-parts and building blocks of the enterprise relate to each other in order to fulfill the enterprise strategy. In this role, enterprise architects are typically less concerned with the lower level details. Note the use of the term “role” in the prior sentence. In practice, enterprise architect is one of many roles played by an individual. Individuals may also perform several other roles, perhaps including domain subject matter expert.

The enterprise architect role requires individuals to understand the business of the enterprise and to interpret its strategy. They must appreciate innovation and be able to embrace a vision for how the business responds to external trends, while pursuing growth, cost-savings, customer satisfaction, efficiency or any mix of strategic objectives. Most importantly, they must be able to interpret the implications of those strategic directions. The implications become the guiding directives for all subsequent decisions. With this knowledge, they must be able to drive the enterprise in new directions, perhaps change the way decisions are made and modify the way the enterprise operates. In other words, they need to lead.

Of course, leading through EA is decidedly different than the experiences of day-to-day life in the IT trenches. Do not confuse “leading” with “commanding.” With task-oriented work models, project cultures, and firefighting, the typical IT culture is often command-and-control oriented, or conversely, completely reactive. Most IT managers are comfortable addressing narrow objectives and have a hard time with “global enterprise-wide change,” avoiding the larger issues as “beyond their control,” If an EA team tries to command, it will incur tremendous resistance in the face of other more immediate concerns. So, how is the enterprise architect to lead? The answer is: through influence.

Leading through influence adds another nuance to the skill set required of the EA team. Soft skills are fundamental to this challenge and include everything from simple communications skills to negotiation, marketing, selling, bartering, managing up, across and down, and all flavors of politics. Succeeding with influence requires persistence, resistance to perfectionism, a modest amount of rigor, a sense of urgency and priority, and value delivery through results.

With that many diverse requirements, is there any hope of finding an individual that can provide all of those skills? It is unlikely. Instead, choose an EA team that, in the aggregate, provides the diversity of required skills. Complement the soft skills required for the enterprise perspective and the hard skills required to coordinate the delivery of detailed domain-specific content with individuals skilled in project management, maintaining the collection of EA artifacts, modeling, internal consulting and managing a repository of EA information. Such an EA team will be able to meet all challenges and fulfill its possibilities.

The Best EA Teams are Virtual
It will require dozens or even 100 or more individuals to fulfill the diverse skills needed by the EA team in the average enterprise. Is creating a divisional-sized EA team the right answer? Not in most situations. Indeed, the larger the physical team the more difficult it is for the EA team to be successful. Why? If an entire EA team is structured as a single organization there is the perception, if not the reality, that EA dominates from sheer mass. It can appear that EA desires to be the center of power for all decisions, disenfranchising others in the enterprise and becoming isolated from day to day realities. While there may be tactical reasons why this could be a useful approach, particularly for disorganized or dysfunctional organizations requiring a wake-up call, it typically does more long term harm than good. That model does not support a collaborative culture among the contributors and stakeholders. One of the most significant barriers to EA success and evolutionary progress is cultural resistance from executives, from the business and from IT itself. The megateam approach has many downsides.

The good news is that there is a better way. Experience and common sense suggest that an EA team insinuated throughout the organization is more in-touch with organizational and project realities, can contribute unique perspectives, and feels a sense of ownership through participation. The result is an increase in the quality, utility and implementation of the enterprise architecture. The best EA teams in any organization, regardless of size, location or industry, are virtual. The team has members distributed throughout the organizational structure. Each member contributes their own unique skill to the mix. Most of these members have other jobs. The challenge for management is to structure participation in a way that is proportional to the value delivered. Figure 1 reflects a layered EA team model to help visualize this virtual approach.

This conceptual model describes three layers of member participation in the EA function: Core, Extended and EA Community. The skill sets associated with each layer vary, as do the time commitments and the roles and responsibilities. Note that this is a conceptual model that works in most organizations. Smaller enterprises will have individuals occupying many roles, while larger enterprises will have highly specialized individuals within a level. Implementation will also vary based on the stage of EA evolution and the availability of skills.

Core EA Team - The Core EA Team is the anchor for the EA Program, owning and operating the processes, and coordinating creation and maintenance of the deliverables through the Extended EA Team. They are also responsible for the program's ongoing evolution. Led by the Chief Architect, the Core Team is small, normally no more than seven to ten individuals.

It can be as small as one or two members. In many organizations the Core EA team members are full-time. The Core Team should be oriented to the “enterprise” perspective, with individuals focused primarily on broad cross-enterprise and cross-domain concerns. It is beneficial, however, for the Core Team to have representatives with sub-specialties in the major crossenterprise domains of interest to the current phase of EA development. Some example sub-specialties are business, information, technical or solutions/services architectures.

Extended EA Team - The Extended EA Team is the primary contributor of EA content. These subject-matter experts spend the majority of their time in operations, infrastructure, applications development, information management and in business units. Only a small percentage of time is in their EA role. They represent the various business process areas, information domains, technology sub-domains, operational and security concerns, etc. that constitute the enterprise. Their perspectives are invaluable contributions to the quality and completeness of the enterprise architecture. The knowledge the Extended EA team acquires through the process of developing integrated EA deliverables spreads throughout the organization as members perform their normal day jobs. Additionally, members often act as coaches, internal EA consultants, and supporters of EA Governance as examiners in the EA compliance process.

EA Community - Not everyone is a member of the Core or Extended teams. But they may still have a role in the EA Program. The EA Community is anyone in the enterprise that uses EA content, and therefore has a vested interest in its accuracy, completeness and utility. These EA stakeholders leverage information provided by the EA knowledge bases, repositories and models to inform their decision processes. Including everything from outsourcing to asset management, application development to strategic planning, financial management to portfolio analysis, the EA Community must have knowledge of strategic direction, current state and future state EA information and their impact on the enterprise. The EA Community influences the way the EA program operates by driving the core team to produce EA content that can be leveraged.

Roles and responsibilities: Tuning the Team & Beware the Slippery Slope
Complex, layered team structures, multiple skill sets, perspectives ranging from enterprise to narrower domain views and the need for team members to juggle multiple roles makes EA management a challenge. The Core Team leader must determine how to allocate team resources to achieve balance across the various tasks the team must perform.

Figure 2 shows the proportion of time and effort divided between the creation of cross-domain enterprise models and narrowly-focused domain model detail. The Core team should spend the majority of its effort on reconciling enterprise models and a more modest amount of time on domain models. Conversely, the Extended team should focus primarily on domain models. While the upper and lower extremes of this model are easy to appreciate, the challenge is in managing the boundary between tasks assigned in the middle of the model. In practice, members of both teams overlap, wearing both hats at different times and in different ratios. This is represented by the horizontal dotted line that moves up and down as the focus on the EA team changes throughout the course of EA Program evolution.

Figure 3 contains a similar model representing the division of tasks between focus on the entirety of the enterprise portfolio (the role assigned primarily to the Core team) and focus on personal support for projects, major initiatives and optimizing specific sub-portfolios, such as managing the server portfolio evolution assigned to technical architects in the Extended team. Again, the horizontal dotted line suggests that ratios and divisions will change as the EA program progresses and enterprise needs change.

An element common to both models is the reference to the “'slippery slope.” “Slippery slope syndrome” occurs as a natural result of demand. Specifically, this is demand for the detailed work products associated with short-term concerns, such as project schedules, cost reduction initiatives, asset management or firefighting, for example or even the “in the weeds” minutia of low-level domain architecture modeling. The slippery slope is not a bad thing unto itself. Given that most individuals engaged in EA work are dedicated individuals with strong skills and professionalism, it is not a surprise that they will jump at any opportunity to help their enterprise when a need arises. Slippery Slope Syndrome becomes a bad thing when it pulls so strongly that nobody is left at the top of the model to pay attention to enterprise concerns. When that happens, the enterprise architecture program stops and the EA team becomes an engineering support organization. The EA team must be constantly vigilant and not permit demand to pull them permanently away from the enterprise perspective. That is a challenge that everyone must manage individually, and one that the Chief Architect must focus on specifically.

The Conductor
The Chief Architect has a very special role to perform, acting as the conductor of the EA team. As does the conductor in an orchestra, the Chief Architect must set the agenda, select the players, assign the parts, set the tempo, adjust the dynamics, and create the harmonies and other musical elements. Also, as in an orchestra, it is the players that create the music, as the EA team members create content and perform their own roles. Because of their special role, every enterprise should consider having a full time Chief Architect, ideally reporting directly to the CIO. This gives them the focus required to deftly manage the myriad activities and perspectives of the EA team.

Conclusion
The virtual nature of the team and the multiple layers of stakeholders and participants, combined with the dynamic nature of changing tasks, roles and responsibilities, means that there is more to assembling an EA team than simply picking a few architects and assigning them a manager. Building and running an effective EA team requires a strategy as well as planning and insight. Reach across the organization to find the best talent with diverse skills that can be assembled into an aggregate team. Seek out representatives from all stakeholder domains and engage them to participate with measured contributions. Manage time and effort to balance toplevel enterprise perspectives against the needs of shorter-term value opportunities. Finally, recognize that an EA program and the teams that represent it will change through various phases of EA evolution. By understanding the dynamics of the people on your team and managing them accordingly, you will all but ensure the success of your EA program.

by George S. Paras, the editor-in-chief of Architecture & Governance Magazine. He is also Managing Director of EAdirections, a firm specializing in improving the effectiveness of enterprise architecture programs. He can be reached at george.paras@architectureandgovernance.com.