Building EA Management Standards: The Progresses and Challenges of the EA Management Guide Project

1
Building EA Management StandardsThe Progresses
and Challenges of the EA Management Guide Project

• Haiping Luo, CEA
• aEA Standards Committee

2
Topics

• Why We Need EA Management Standards
• EA Management Guide (EAMG) Project Overview
• Challenges Encountered by the EAMG Project
• Approaches and Progress

3
Why We Need EA Management Standards

• The EA discipline is a relatively new and
  evolving field
• The EA Body of Knowledge has three major
  deficiencies
• Inconsistency
• Incompleteness
• Lack of community participation and ratification

4
Inconsistency

• Situations
• Lack of consensus on EA concepts, terminologies,
  goals, approaches, techniques, and outcomes.
• Disagreement on what an EA program should do and
  deliver.
• Consequences
• Confusions in communications within the EA field
  and with EA stakeholders
• Instability on quality and performance
  requirements and measures

5
Incompleteness

• Situations
• Literatures often focus on part of EA topics such
  as frameworks, models, processes.
• Knowledge gaps exist in terms of covering the
  complete spectrum of EA management, from
  establishing an EA management program, to
  delivering the final output and outcomes of the
  EA management
• Lack of a true enterprise perspective and
  coverage. Literatures often have an IT-centric
  thinking.
• Consequences
• Architects cant find complete guidance to carry
  out all aspects of EA management work.
• Stakeholders dont see EA outcomes beyond IT
  planning.

6
Lack of Community Participation and Ratification

• Situations
• The existing EA literatures are often the
  products of individual effort or focus-group
  effort.
• The EA community had no formal structure to take
  wide participation in the development of EA body
  of knowledge or to ratify and maintain the
  resulting body of knowledge.
• Consequences
• Inconsistency and gaps continue.
• The EA discipline and practice cannot advance
  toward maturity.
• EA deliverables and expectations may not able to
  meet.

7
Benefits of Developing EA Management Standards

• Build consensus and common ground
• Fill knowledge gaps
• Involve participation and establish commitment
• Raise levels of effectiveness, quality,
  reliability, efficiency, interoperability, and
  return on investment for EA services.

8
EA Management Guide Project Overview

• Purpose
• Identify and organize EA knowledge and best
  practices for every aspect of EA management
• Assemble EA management information that is
  generally recognized as good EA practice and
  knowledge in most enterprises, most of the time.
• Project Management Led by aEAs EA Standards
  Committee
• Objectives
• Complete an EA Management Guide (Version 1.0).
• Establish the Guide as an aEA standard.
• Pursue acceptance with international standards
  organizations.
• Target Timeline for the Guide Nov 2005 Oct 2007

9
Project Approach and Progress

• Principles
• Open participation Transparent process
  Consensus-building journey.
• Team
• Currently over 70 volunteers from 9 countries,
  representing practitioners and scholars with EA
  expertise in public and private sectors, civilian
  and military institutions, and different
  industries.
• Progress
• Project initiated and planned.
• Call for Participation distributed to the EA
  community.
• Outline reviewed by the EA community.
• First draft authoring is underway.

10
Challenges Encountered

• Disagreement on concepts and terminologies
• Divergence on goals and outcomes
• Discrepancy in processes and approaches

11
Examples

• Disagreement on concepts and terminology
• What is Enterprise Architecture, after all?
• The physical structure of an enterprise?
• The documentation or blueprint of an enterprise
  structure?
• The process to architect an enterprise
  structure?
• An EA program?
• The discipline about architecting an enterprise?
• A framework referred in architecting work?

12
Examples

• Disagreement on concepts and terminology (cont.)
• Implications
• None of the definitions are wrong, but multiple
  definitions can cause real problems.
• For example, when we measure EA maturity, are we
  measuring
• How good the physical structure of an enterprise
  is?
• How good the documentation of an enterprise
  structure is?
• How good the architecting process is?
• How good an EA program is? or
• How well established the EA discipline is?
• Different definitions lead to very different
  measuring systems and quality standards.
• Also, when we communicate about EA, in which
  meaning are we talking about?

13
Examples

• Divergence on goals and outcomes
• What an EA program should achieve and deliver?
  The answers to this question range from
  delivering blueprint plans to providing good
  management.

14
Examples

• Divergence on goals and outcomes (cont.)
• EA program goal spectrum

Deliver enterprise architecture blueprints to
support and guide enterprise planning.
Implement enterprise management.
Lead the enterprise to pursue architectural
soundness to support enterprise management.
Deliver IT architecture blueprints to control
IT investment development.
15
Examples

• Divergence on goals and outcomes (cont.)
• Implications
• Divergence in goals and outcomes results in
  discrepancy in processes and approaches.
• Again, how to assess quality and performance
  becomes a problem.

16
Examples

• Discrepancy in processes and approaches
• Architects give discrepant answers to common EA
  questions
• What are the architectural principles we should
  implement or steward?
• Whether architecting is a process cycle or a
  chain of incremental changes?
• What are the key stages an architecting process
  must have?
• Who should be doing what in an architecting
  process?
• Architects take discrepant approaches to address
  enterprise problems
• Investments are done in stovepipes. Should
  architects be the police or the guide to reduce
  stovepipes?
• Accountability is missing. Should architects push
  for centralization, decentralization, or
  something else?
• Interoperability is poor. Should architects
  promote integration or standardization?
• Processes are not aligned. Should architects
  coordinate or merely record and report?

17
Examples

• Discrepancy in processes and approaches (cont.)
• Implications
• Stakeholders are confused on what to expect from
  architects and from an EA program.
• Management sees an EA program a rubber stamp good
  only for dealing with OMB or GAO.
• Other disciplines see the EA discipline a copy
  cat with a fancy hat but no solid methodology and
  value.

18
EAMG Approaches and Progresses

• Clarify and harmonize concepts and terminologies
• Specify goals and outcomes
• Identify key principles, major processes and core
  approaches
• Encourage innovation and creativity while
  standardize good practices

19
Examples

• Clarify and harmonize concepts and terminologies
• Follow Three Principles to Name an Object
• Singularity. The term represents one and only one
  object in a subject area.
• Correctness. The term is not a faulty
  representation of the object.
• Recognize-ability. The term is commonly
  recognizable in the subject area as identifying
  the object it is supposed to represent.

20
Examples

• Clarify and harmonize concepts and terminologies
  (cont.)
• What is Enterprise Architecture, after all?
• This term has been used in ambiguous ways. EAMG
  should avoid use this term alone. EA can be used
  as the modifier to terms that are more specific
• the Architecture of an Enterprise
• the Enterprise Architecture Discipline
• the Enterprise Architecting Lifecycle
• Enterprise Architecture Program Management
• the Documentation of an Enterprise's
  Architecture and
• the Design of an Enterprise's Architecture.

21
Examples

• Specify goals and outcomes
• EA management goal range

Deliver enterprise architecture blueprints to
support and guide enterprise planning.
Implement enterprise management.
Deliver IT architecture blueprints to control IT
investment development.
Lead the enterprise to pursue architectural
soundness to support enterprise management.
22
Examples

• Identify key principles, major processes and core
  approaches
• Sample architectural/architecting principles
• Quantitatively allocate enterprise goals into
  local goals to ensure enterprise, not local,
  optimum.
• Clearly assign each responsibility for an outcome
  to a specific individual to implement
  accountability.
• Standardize interfaces and exchange flows of
  modules to form interoperability.
• Impacts must be identified and handled before any
  change takes place.

23
Examples

• Identify key principles, major processes and core
  approaches (cont.)
• Sample major architecting processes
• Architecting lifecycle
• Prerequisites to Architecting Lifecycles
• Phase 1 Documenting Existing Architecture
• Phase 2 Analyzing Existing Architecture
• Phase 3 Planning and Ratifying Target
  Architecture
• Phase 4 Developing and Committing Transition
  Plans
• Phase 5 Implementing Planned Changes
• Phase 6 Evaluating Implemented Changes
• Phase 7 Continuing Architecture Management

24
Examples

• Sample core approaches
• EA metamodel standardization

25
Examples

• Encourage innovation and creativity while
  standardize good practices
• EAMG recognizes alternatives, different opinions
  and identifies implications for the alternatives.
• EAMG standardizes and promotes core EA practices
  that are considered good for most enterprises
  most of the time.

26
EAMG Focus Areas

• Concepts and Terminology Establish concepts,
  terms, definitions, a common language, and a
  basic understanding of the EA discipline.
• Design Principles and Patterns Identify criteria
  for good architectures and feasible ways to reach
  the good architecture.
• Processes and Techniques Specify the standard
  processes and approaches for architecting an
  enterprises structure.
• Program Management Build a high quality and
  strong performing EA program to carry out the EA
  mission.
• Problem Solving Decision Support Apply the EA
  discipline to solve common types of real world
  problems and provide support for specific
  decision-making.

27
Summary

• The EA Discipline needs standards to guide
  practices.
• The EA Management Guide project assembles
  existing standards, extracts EA communitys
  wisdom and best practices, and align them all
  into a more consistent and complete set of
  standards to support the delivery of sound
  architectures.
• Challenges are natural part of the EAMG journey.
  We call for your continuous support, input, and
  participation to achieve our common goal.

28
Summary

• How to help
• Authoring
• Reviewing
• Promoting
• Funding
• Contact Information
• Haiping Luo (haiping_at_aeajournal.org)