This report addresses many of the questions that EAdirections’ managing directors are frequently asked by Chief Architects or their team members.

These are the questions we are most frequently asked by practicing Enterprise Architects, CIO’s, their staffs, and business people who are curious about EA.

What is our definition of EA?

Enterprise Architecture is a strategic management discipline that creates a single, holistic view of the business processes, systems, information and technology of the enterprise designed and optimized to create shareholder value by achieving both the long-term business strategy as well as current business objectives.

The primary output of enterprise architecture is a roadmap that evolves the ‘as-is’ business processes, systems, information and technology of the enterprise from the ‘current state’ to the desired ‘future state’ design. The roadmap should be used to guide investment decisions within the overall project and asset portfolio management mechanisms of the enterprise.

Why is EA important?

EA is important because it increases an organization’s agility by reducing technology complexity which inhibits change. EA also reduces business risk by ensuring that technology decisions are made in the context of business strategy and long-term trends. Finally, EA reduces total IT expenditures over the long-term by ensuring that technology decision are made holistically in the context of overall enterprise value.

Another approach to evaluating the importance of EA is explored by asking the question, “What if we didn’t do EA?” Without an EA to guide them, most organizations make decisions bit by bit, project by project, without a grand plan for how all of these bits and projects fit together, and just do whatever the business asks for as quickly and cheaply as we can. After all, that’s what the business says they want. This approach often leads to multiple technologies, incompatible systems, high support costs, brittle environments, unnecessary redundancies, and integration nightmares.

The potential impact of EA is so significant that the importance of EA must be seen in what it can provide to an organization.

• A process to analyze and plan for change intelligently and consistently across the entire enterprise with full knowledge of the impact of change as well as the consequences of not hanging.
• Significant time savings to all areas of the business by saving them from making decisions and completing implementations that are redundant with and/or too narrow focused to benefit other areas of the enterprise.
• More intelligent investment decisions
• Extend the life of assets that will continue positive contributions
• Decrease the number of short-term, high-cost implementations that also tend to increase maintenance costs over time
• More agility than competitors, leveraging importance of speedy time-to-market in hypercompetitive markets

Where does EA belong in an organization? 
 
Long-term we believe that EA will become a key strategic planning function reporting to the VP of Corporate Strategy with a dotted line relationship to the CIO. EA would also appear as an agenda item for meetings of the Executive Committee and the Board of Directors.

Today, EA most commonly reports to the CIO or to a to high-level IT manager. Depending on the relationship that IT has with the business in your organization, this may or may not be a bad place for EA.

What is the relationship of EA to the business?

The ideal relationship would be one where the EA not only supports business strategy and transformation, but also contributes to business strategy and even drives innovation, exploiting new technology for the benefit of the organization. An EA team must develop a high level of credibility, effectiveness and knowledge of the business operations to have this type of relationship with the business.

However, EA is often somewhat of an annoyance to the business. Realistically, the business most likely will not care about EA, and that is acceptable. The phrase ‘Enterprise Architecture’ can be misleading to executive leadership and end users. Architects who insist on educating the business on the meaning and nuances of enterprise architecture are missing the point. It is all about the outcome, not the ‘A’ word. What enterprise architects must get the business to understand are EA outcomes. They will get the support of executive leadership and of the business if the value of EA is effectively demonstrated. An effective EA is one that proves itself as a partner to the business by further articulating the impact and means of achieving business strategy, in some cases even changing business strategy to better leverage new and existing enterprise capabilities. The relationship of EA to the business is usually symptomatic of the relationships between IT and the business, EA and business strategy, and EA and IT.

• The relationship of IT to the Business? Depends on the level of credibility and performance – lower results in IT being an order-taker on-demand of the business, while higher leads to a shared partnership where IT can use its knowledge of the business to proactively identify innovative ways to use information and technology to increase shareholder value
• EA is to business strategy what the playbook is to a championship football team. Business strategy represents what you want to be (“a championship football team”) and a high level vision of how you will achieve that (“Dominant passing game, great run defense”). EA represents all the things that need to be done to accomplish that (the playbook). To take this analogy one step further, the game plan for each game, week by week, is represented by the project portfolio.
• he first relationship that must get healthy is the one between EA and IT. If the CIO doesn’t buy-in to and actively support the EA program, it is going to be a long, frustrating journey to nowhere.

How do you gain support for EA from the business and IT?

Gaining support and sponsorship for EA is a critical and time-consuming task, so it requires constant focus and attentions. Following are some key considerations for increasing support and sponsorship for EA.

• Use business scenarios to show effect of transforming the business, and demonstrate the role of EA in achieving transformation “coordinated across the entire enterprise.”
• Demonstrate value in terms of EPS or EBITA or NIAT.
• Business/IT alignment is a term that is often used, but rarely understood, and even less frequently, achieved. Gaining support from the business will require an understanding of the complexity of business process change and its impact on systems, information and infrastructure. EA can provide the views of the complexity and the impact of change. Aligning the changes needed by the business with the changes they necessitate in IT is key capability for EA to gain more support.
• When someone says “EA has no credibility with the business” it is usually because “IT has no credibility with the business.” If this is the case, look at driving EA effort toward improving IT service delivery first. This will increase EA’s support from IT, increase the credibility of IT, and lead to more support for EA from the business.
• Create and execute on a communications plan, selling strategy and marketing plan for EA
• Don’t forget to ask specifically for what you need – time, money, resources, advocacy – when you are seeking someone’s support.

What are the key benefits of EA?

This question is similar to the earlier question about the importance of EA; however this one is more specifically referring to the outcomes that will benefit the organization. Every organization will derive different benefits from Enterprise Architecture; however, there are some common benefits that most effective EA programs can deliver to the organization:

• Increase efficiency of IT
  • Increase standardization, which leads to lower development, maintenance and support costs
  • Decrease project completion times
  • Reduce the complexity of the IT environment
  • Increase the “ility’s” (portability, interoperability, adaptability, maintainability, flexibility, etc.)
• Increase the return on investments
  • Eliminate redundant investments
  • Increase reusability and reuse of assets
  • Align investments with the business areas that receive the value
• Increase the effectiveness of impact analysis
  • Understand the relationships of business processes, information, systems and infrastructure to each other
  • Estimate costs associated with change more accurately and completely
• Increase effectiveness of communications with the business
  • Build models that communicate more effectively
  • Use business language to describe the contributions of IT

What are the essential elements of the EA Process?

• Business Strategy Driven
• Business Capability Focused
• Trend-Aware
• Future-Oriented Perspective
• Holistic (beyond technology) Scope
• Applied to the Enterprise, not a specific solution, domain or topic
• Links EA decisions back to the business
• Principles Based
• Evolutionary and iterative
• Prescriptive and directive
• Cycles completed just in time to deliver high-value guidance to transformation initiatives and budget planning
• Timely publishing of and education on content
• Connected to other enterprise Governance mechanisms and processes

Who is involved in the EA Program?

The most critical factor in EA success is the people that are involved. Understanding the competencies, capabilities, skills and dynamics required of different participants in the EA function will help an organization identify the best candidates for EA. Here is a list of common roles to be filled in relation to EA and associated governance bodies:

• EA Sponsor
• EA Champion
• Chief Architect
• EA Core Team Leader and Member
  • Could be a specialist in a Domain (Business, Information, Infrastructure, Application)
• Domain Working Group Chair
  • Could be Core Team Member or SME
• Domain Working Group Member
  • Domain groups should be filled with expertise from other domains
• EA Community Member
• Governance Roles
  • Executive Steering Committee
  • Architecture Review Board
• Project Reviewers/Auditors
• Project/Solution/Domain Architects (Silo architects)
• EA Project Consultants

Other considerations that you should have in building the people component of an EA practice:

• Good Chief Architect Characteristics
• Where should the team reside in the organization?
• What skills are required?
  • Personal, Domain, Business, etc.
• Who should be on the team?
• What the team must do
• What team members must do
• How should the team manage time and activities?
• EA Team Structure and Skills’
• Assigning RACI (responsibility, Accountability, Consulted, Informed)
• Communicating with Stakeholders – Executive sponsors and supporters
• Effectively using Business and IT Subject Matter Experts
• Leveraging the Enterprise PMO
• Leveraging strategic partners (business and IT vendors)

What are the essential elements of EA Governance?

EA Governance must be integrated with the overall governance and decision-making mechanisms/ bodies/processes of the enterprise. Additionally, most effective governance approaches account for or leverage the following elements:

• Stakeholder support to create authoritative top-level governance structure
• A process to submit EA recommendations to governance structure for EA approval and sign-off
• Operating rules (membership, voting, schedule, rejection, more info needed, delegation, etc.) for committee structure
• Governance Committee Charters
• When to create second, third tier approval bodies, and which EA items they are chartered to approve
• Approved EA publication rules/processes
• Architecture Assurance/Compliance linkages to SDLC
• Interaction points with SDLC governing body (PMO) defined
• Compliance process rules/regulations, decision criteria (which projects are reviewed what level)
• Training of EA Compliance reviewers/auditors
• Exception/Variance request process (review, reporting/recommendations, approvers, escalation, etc.)
• Exception/Variance request tracking/management/reporting processes/metrics
• EA Content remediation driven by Assurance/Compliance process
• Standards enforcement

What are the critical success factors for EA?

There are some common critical success factors that EAdirections has recognized in highly effective EA programs. Not all of these critical success factors are seen in every effective EA program; so each organization must determine which factors are hindering and which are enabling EA effectiveness

• All factors do NOT need to be present to be successful
• Some of the more common CSFs
  • The ability to assess the specific factors within your enterprise so that you can leverage the factors that contribute to EA effectiveness, and mitigate the factors that obstruct EA effectiveness
  • Having the active support of the CIO and IT leadership
  • ‘Breadth before depth’ approach
  • Rapid delivery of artifacts – 80% complete rule
  • Broadly communicating the activities and progress of the EA team, and the artifacts as they are produced (including drafts)
  • Linking EA decisions back to the business capabilities they support
  • Establishing an EA governance process that complements overall IT and corporate governance
  • An effective EPMO
  • EA team members who put the needs of the business first and ‘play-well-with-others’
  • A commitment to making holistic decisions (more later)
  • Each domain architecture team includes a cross-section of IT disciplines
  • At least one full-time Architect
  • Demonstrating the value of EA to business leadership
• What is NOT as critical?
  • The methodology or framework you chose (leadership is more important than ‘method)
  • The number of full-time staff assigned (it is about the right people doing the right things)
  • The technical standards you select (standards are useless unless there is governance and a designation of how the standards are supposed to be used and configured)

What are the metrics and measures of EA?

• Metrics reflecting the QUANTITY of the EA content, includes completion of planned EA deliverables across all of the area and domain architectures
• COVERAGE – How many people are aware of the existence of EA, the importance of EA, trained (certified) in the end user application of EA (in projects and assets), trained in EA compliance/assurance testing/auditing, actively submitting EA content to future state EA, performing gap analysis, etc.
• ACCESS – hits on EA portal, documents downloaded, etc.
• ACCEPTANCE – reflected in the number of projects/asset activities looking to and relying upon EA future state content for guidance
• QUALITY/UTILITY/ACCURACY – reflected in the percentage of EA recommendations accepted by EA approval processes/committees, the diminishing trend line of EA exception/variance requests, the trend line of approved vs. denied exception/variance requests, how current the EA deliverables are (dates of last update/review for accuracy), frequency of EA process cycles, etc.
• IMPACT/VALUE – reflected in convergence on enterprise objectives (lower cost, faster time to market, more agility, more growth, complexity, etc.) over time, includes measures of asset portfolio complexity, duplication, silo behaviors, integration or lack thereof, information/data duplication/redundancy, ability to satisfy aggregate risk measurements, security profiles, etc.

How do you get started with EA?

Lots here – this is just a first shot, no particular attention paid to trying to make the order perfect…

• Identify and Educate EA internal champion
• Building stakeholder sponsorship and support
• EA Charter
• Identifying EA team membership
• Establishing roles and responsibilities
• Building grass-roots support, establishing an EA Community
• Identifying active EA contributors
• Establishing training curriculum for core team, execs, contributors, users
• Establish current EA maturity
• Identify target EA maturity
• Establish EA objectives, short/medium/long term and define overall approach
• Build EA project plan(s)
• Identify initial deliverables
• Create top-level value diagrams and other strategic deliverables, CRV, etc.
• Establish principles
• Install governance committees and processes (see above)
• Build internal EA coaching/consulting practice
• Identify linkages to other internal processes
• Choose supporting tools/delivery infrastructure
• Identify current state
• Identify and analyze gaps and establish suggested transition/migration plans

What are some of the common mistakes with EA?

EA programs fail or stall for a large number of reasons. The most common mistakes are problems in execution.

• Over-reaching – trying to do too much, too fast
• Not being aggressive enough – not delivering relevant content to a broad enough audience, fast enough
• Not engaging a diverse EA Community – behaving as a small group dictating EA from an ivory tower and the EA team artificially disconnected from project and operational realities
• Perfectionism – Content takes too much time to develop, is too deep to be practical and used, or team suffers from paralysis of analysis
• Not enough detail – architecture content too high level to inform stakeholder community
• Lack of focus and a random approach – creation of a disjoint stream of “strategy white papers”
• Novel Writing – Writing and delivering tomes of EA tutorials and artifacts that are never read
• No business involvement – EA content created and governance operating without input and support from business stakeholder community
• Not enough time focused on “enterprise” – disproportionate time spent doing project engineering support
• Poorly communicated content – EA artifacts are not easily consumable and available to stakeholders
• Obstructionism – EA teams members attempt to interfere with projects after they are in motion
• Architecture Police – Enterprise architects assume authority they do not have and strong-arm project teams

How important is an EA Framework?

An EA framework is essential to organize and coordinate the work activities and deliverables of the EA team, to create auditable linkages across abstraction levels, to understand the relationships between elements within and between EA domains and to communicate the content to the stakeholder community in a logical fashion, targeted to specific perspectives. What is not important is that any particular framework be favored over another. Our guidance is to not invest too much time and energy evaluating frameworks, and definitely do not invent an original work of art from scratch. There are several good choices available in the market including the Zachman Framework, TOGAF, DODAF, The Federal EA Reference Models, EA-cubed, etc., though none are perfect for every purpose and every organization. Choose one that will satisfy most of your needs, or chose elements from several, and tune/adjust as required.

Which EA tool should we use?

The choice of EA tool environment, and the timing of when to introduce one, must be evaluated on a case by case basis. In general, organizations that are new to EA show focus most of their energy on launching effective EA and governance processes, involving the right participants, identifying early value opportunities, choosing frameworks, building an effective engagement model and creating early deliverables. During these early stages most teams will find ordinary office automation and drawing tools sufficient for their needs. Once the team has built momentum and begun to accumulate deliverables, they will soon find that environment lacking and difficult to manage. Increasingly, EA teams are hitting that wall sooner than in years past and are drawn to more sophisticated environments either for modeling, to support the application development and analysis communities, for repositories, to capture and manage the objects of the enterprise, or for both to help understand the relationships that exist at all levels of abstraction and content.

Directions: While many Chief Architects frequently ask these questions, the key to their success will most likely be in figuring out the unique questions to ask about their enterprise.