How to Develop a High-Performance Enterprise Architecture

Even if your Enterprise Architecture (EA) program is effective at managing technology or helping application development, you need to work on repositioning EA to be more business-focused. Here are some recommendations to help you develop a strategy to achieve that goal.

By Alex Cullen
Thu, September 06, 2012
Page 2

Build Your Strategy Around EA Capabilities and Services

Strategy is what separates a successful EA practice from busy one. Strategy looks at EA's current-state capabilities and the larger organizational context, constructs an appropriate mission, and lays out all the elements necessary to achieve that mission. It defines the key performance indicators (KPIs) used to measure progress and results. Moreover, a well-communications and well-executed strategy builds significantly more credibility than any amount of firefighting or chasing down of hot issues.

To get started, Forrester recommends using a capability map to translate high-level goals into more specific goals and objectives. Assess what the mission, objectives, and value proposition mean to the outcomes of capability, and set this as the goal. For example, you can set a goal for your strategy/road map capability around embedding it into developing your customer service plans for using social media.

EA services connect your capabilities to value for your customers. For each capability outcome, ask what is the service (or services) the EA program must provide to bring about that outcome. Define your services portfolio first, and then the processes, deliverables, and skills needed to deliver these services. Follow this definition exercise by selecting the key performance indicators that show your services' effectiveness and value.

Address Three Key Decisions

As you work through your strategy development, these critical decisions will bubble to the top:

1. The role and responsibilities of "extended team" architecture resources. Most organizations have a core team and an extended team of architects; the extended team is typically 150 percent the size of the core team. Extended teams typically include project or solution architects and technical domain architects. Defining what the EA program needs from this extended team is critical for an effective EA practice.

2. Changes to EA responsibilities and ownership. Enterprise architecture programs typically start out as subject matter experts for technologies. With a new, higher-value mission, some existing EA responsibilities may fit poorly -- for example, EA teams that have focused most of their resources on technology components may find themselves with insufficient time to build business-oriented future-state architectures and road maps. Continuing with these existing responsibilities brings two challenges: they take resources and attention away from the new EA mission, and they leave stakeholders confused about the EA charter and value proposition. Examine these out-of-scope responsibilities to see if they can be delegated with oversight to extended team resources, rather than EA ownership deliverable.

3. How architecture governance will be performed. Most organizations have some degree of architecture governance, which may simply be a review of the use of technical standards by IT projects. Business-focused EA programs will need a different approach to governance -- being involved before projects are approved and being enablers of business strategy, not mere protectors of IT standards. Key questions include authority and escalation, how to characterize and capture technical debt, how to handle compromises, and scope of architecture governance.

Alex Cullen is a Vice President and Research Director at Forrester Research, serving Enterprise Architecture professionals.

Our Commenting Policies