Enterprise Architecture and Design

1
Enterprise Architecture and Design

• Vince Kellen
• Vice President, Information Services, DePaul
  University
• Instructor, DePaul CTI
• http//www.kellen.net

2
Introduction to EAP
3
Enterprise Architecture Planning

• What is it?
• Spewak
• EAP is the process of defining architectures for
  the use of information in support of the business
  and the plan for implementing those architectures
• Handbook on Enterprise Architecture (HEA)
• On Enterprise Engineering It is the collection
  of those tools and methods which one can use to
  design and continually maintain an integrated
  state of the enterprise.
• Boar
• On IT Architecture It is a series of principles,
  guidelines, drawings, standards and rules that
  guide an organization through acquiring,
  building, modifying and the interfacing of IT
  resources throughout the enterprise.

4
EAP Scope

• Information is the life blood of a business.
  Information management is the essence of business
  management. EAP can refer to a business or to IT.
  Can you model IT architecture separate from
  business architecture? Where does one begin and
  the other end?
• Scope for EAP can be
• A virtual enterprise (7.2 HEA)
• The enterprise
• A business unit (or collection of business units)
• IT only
• Can the scope for EAP be a cluster of enterprise
  (18.5.3 HEA)?

5
EAP Whats in it?

• EAP does not define one architecture, but
  multiple architectures
• There is not one perspective for EAP, but many
• Planner, owner, designer, builder, subcontractor1
• Each level is not just more detail, but with
  essential differences2
• There is not one tool for EAP, but many
• Many modeling languages (3.5, table 3.1 HEA, p
  133)
• Several modeling methodologies/frameworks (3.3,
  3.6 HEA)
• Several software packages (3.9.1, 3.9.2 - HEA)
• 1Sowa, J.F. Zachman, J.A. Extending and
  formalizing the framework for information systems
  architecture. IBM Systems Journal, Vol. 31, No.
  3, 1992.
• 2Zachman, J.A. A framework for information
  systems architecture IBM Systems Journal, Vol.
  26, No. 3, 1987.

6
What do architects do? Roles

• Technology life-cycle management
• Identify emerging technologies, defining
  standards, retiring technologies
• Technology procurement
• Purchasing, managing the vendor relationship
• Methodologies
• Gartner is referring to design methodologies
• Life cycle process and standards
• Project management, reuse, metrics and testing
• Skills planning
• Architectures perspective helps plan future
  skill development
• Data architecture
• Identify common standards to ensure
  interoperability
• Interfaces and modularization
• City planning how do parts relate to each other?

7
What do IT architects do? Organization

• Architecture is not monolithic. Planning may be
  carried out by groups other than the core team
• Software architecture
• Business architecture and functional
  rationalization
• Establish repositories of knowledge management
  and best practice
• Shared software component development
• Activities in architecture
• Identify potential architecture investments and
  cost-justify them
• Communicate the architecture and maintenance
  process to users, stakeholders
• Road map management
• Conflict resolution and exception handling
• Deploying the architecture
• Monitoring the effectiveness of the architecture

8
GERAM

• Generalized Enterprise Reference Architecture and
  Methodology (GERAM)
• Became part of ISO standards in the mid 1990s,
  history is in manufacturing industries
• Think of it as a specification to compare with
  any architecture methodology. GERAM is likely to
  be more complete and robust.

9
Some points to consider

• Internet is highly decentralized. But
  decentralization without structure is chaos
  (Zachman, 1987).
• Computing architectures are complex and ever
  changing. Integration between computing
  architectures, while increasing in richness and
  benefit, is also getting more complex
• Architecture is a needed response to prevent
  disintegration of the enterprise, virtual or
  otherwise.

10
Strategy
11
Strategy

• What is strategy?
• A pattern in a stream of decisions. (4.2.2,
  Mintzberg)
• Behind every successful company lies a successful
  strategy
• It is an interdisciplinary field involving
  economics, management, organizational theory,
  law, (cognitive sciences)
• Many different schools of strategy
• Strategy is pragmatic. Strategies exist to give
  organizations (businesses) advantage in their
  ecosystems (markets). Profit motive
• The role of IT in strategy has had much debate
  both recently and historically

12
Different schools
Design Senior management formulates clear, simple and unique strategies in a deliberate process of conscious thought
Planning Formal, decomposable into discrete steps, checklists, techniques.
Positioning Positions selected through formalized analysis of industry situations. Porters five forces, PIMS, Boston Consulting Group.
Entrepreneurial Focus on the CEO, intuition, metaphor. Forceful leader. Start-up, niche. Leader maintains close control on his or her formulated vision
Cognitive Strategies originate in peoples minds as frames, models, maps, concepts, schemas. Cognitive biases, heuristics, naturalistic decision making. Creativity.
Learning Disjointed incrementalism, logical incrementalism, muddling-through, emergent strategies, the learning organization.
Power Development of strategy is political, a process involving bargaining, persuasion and confrontation among actors who divide power.
Cultural Focus on common interest and integration, strategy formation is a social process rooted in culture. The threat of Japan in the 1980s spurred this.
Environmental How organizations use degrees of freedom to maneuver through environments. Limits to strategic choice due to environmental conditions.
Configuration Configure an approach to strategy by adopting one or more schools. Shift from one mode to another depending on the life-cycle of the firm.
From Reflecting on the strategy process,
Mintzberg, Henry. Sloan Management Review. Vol.
40 No. 3. Spring 1999.
13
Types of strategies
Intended Strategy
Realized Strategy
Deliberate Strategy
Unrealized Strategy
Emergent Strategy
From Of strategies, deliberate and emergent.
Mintzberg, Henry Waters, James. Strategic
Management Journal. Vol. 6, 1985.
14
Introvert approach to strategy

• Resource-based view (RBV) of the firm, dynamic
  capabilities approach (DCA)
• Firms compete on resources and capabilities
  (4.3.2.1 HEA)
• Resources are assets, tangible or intangible
• Capabilities are a capacity to deploy resources,
  know-how
• Functional capabilities deepens specific
  knowledge
• Integrative capabilities combines functional
  capabilities and absorbs external knowledge
• Firms gain access to resources and capabilities
  through networks (or relationships) . Managing
  this network may be considered a capability.
  Could a network be thought of as a resource?
• Capabilities and resources are not singular items
  considered in isolation. They interact with each
  other and comprise a complex system.
• Capabilities and resources which are
  non-tradable, rare, inimitable or
  non-substitutable can be a source of competitive
  advantage
• Is this sounding mystic, unmanageable, tacit?

15
Additional arguments

• While an introverted view may be warranted, a
  competency that is emerging as significant is
  knowledge of market opportunities. This is
  different than knowledge of product engineering
• Markets are collections of customers. Customers
  demonstrate their power in making choices.
  Customers choice-making is increasing in power
• Commoditization of complex manufacturing,
  imitable globally
• Diversity of choices due to many manufacturers is
  giving customers more choices
• Diversity of choices increases consumption and
  overall market opportunity (post-modern
  consumerism)
• Knowledge of customer choices is a key capability
  
• This capability is focused on external
  information (integrative capability)
• Systems, data and information is the overwhelming
  means by which this integrative capability is
  executed

16
Knowledge and capabilities

• Capabilities are a key component to competitive
  advantage
• Knowledge is a significant ingredient within
  capabilities
• Therefore, knowledge is important

17
Two views

• Dominant view of knowledge management
• Tacit knowledge conversion to explicit storage,
  retrieval and diffusion of explicit knowledge
• Focus on the production versus consumption of
  knowledge
• How is knowledge produced? (innovation)
• Knowledge can be managed
• Some reactions to the dominant view
• Knowledge grows via a series of unplanned,
  indeterminate interactions between people
• Knowledge is acted upon in tacit form without
  full awareness or validity
• Learning is fraught with difficulties
• Cognitive biases, organizational and individual
  defensiveness
• Knowledge cant be managed

18
Knowledge and behavior

• Can you see someone acquire knowledge when it
  occurs?
• Knowledge must lead to observable behavior change
  that can be linked to business success.
• Learning occurs when people produce what they say
  they know (C. Argyis)
• Two forms of behavior change intrinsic and
  coerced
• Coerced behavior change
• We will pay you more if you do X
• We will accept you in the group if you behave in
  following X ways
• Intrinsic behavior change
• I want to earn more money, so I will do X
• In the name of my religious beliefs, I will do
  X
• I want to rule the earth and coerce others, so I
  will do X
• Questions
• Is it easier to acquire knowledge or get
  knowledge acted upon with coercion?
• Is intrinsically motivated behavior better? Is it
  harder to get the behavior started or stopped?

19
Knowledge chain or knowledge network?
Identify
Catalog
Store
Distribute
Or
What is the precise sequence of interactions that
produces the knowledge needed by the
organization? What comprises the interactions?
Can you repeat the sequence each time? What rules
govern the sequence?
20
IT does not matter. Or does it?

• Resource view of IT
• It is not scarce, it is ubiquitous. It is
  imitable.
• The advantage is short-lived due to ubiquity and
  imitability.
• IT is looking like railways and electric power
  markets
• Spend less, follow (dont lead), work on
  vulnerabilities and not opportunities
• IMHO Wrong view of IT!
• Capability view of IT
• It powers others and is in and of itself an
  integrative capability. It lets firms know
  their environments and react or proact in
  them.
• It is complex. Processes in and around IT are
  complex. No normative frameworks exist for the
  development of these processes. Success is scarce
  and not imitable. Success emerges, often
  unpredictably.
• The range between high and low cost/performance
  firms may be 41 or higher, suggesting no
  commoditization of use has occurred
• IT is perpetually mutable. It can be molded into
  an infinite array of products/offerings. It is
  NOT a railway or an electric power company.

From IT doesnt matter, Carr, Nicholas G.
Harvard Business Review. May, 2003.
21
Change is collective

• Designing change is a collaborative exercise.
  Many IT staff need to be involved, as do many
  non-IT staff
• Implementing change is surely a collaborative
  exercise. Unproductive resistance to change can
  surface in many forms from the obvious to the
  extremely subtle consciously and nonconsiously
• New IT architectures introduce and come along
  with other organizational changes. In fact, the
  technology is usually not the reason for
  architecture failures
• In times of change, we need zones of stability
  communicating the goal, seeking alignment between
  teams and individuals is important

22
Attitudes and behavior
Attitudes
Behavior
Do we adjust our behavior to align with our
attitudes? Or Do we adjust our attitudes to
align with our behavior?
23
EAP Frameworks
24
GERAM

• GERAM is a comprehensive framework for
  producing or managing enterprises, projects,
  products, new methodologies any entity
• An ontology
• An explicit formal specification of how to
  represent the objects, concepts and other
  entities that are assumed to exist in some area
  of interest and the relationships that hold among
  them1
• The hierarchical structuring of knowledge about
  things by subcategorizing them according to their
  essential (or at least relevant and/or cognitive)
  qualities1
• Ontologies are simply hierarchal description of
  the important concepts in a domain, coupled with
  a description of each of these concepts.
  Ontologies consist of various concepts that
  include class, subclass, class hierarchy,
  instance, slot, value, defaults value, facet,
  type, cardinality, inheritance, variable and
  relation. The word ontology first appeared in
  Aristotles philosophical essays, where it used
  to describe the nature and organization of
  being.2
• 1 http//www.dictionary.com
• 2 Ontologies for Supply Chain Management,
  Ahmad, A., Mollaghasemi, M., Rabelo, L.,
  http//www.isye.gatech.edu/faculty/Leon_McGinnis/
  8851/Sources/Ontology/Ontologies.pdf

25
GERAM

• GERA General Enterprise Reference Architecture
• Identifies the concepts for enterprise
  integration. Human, process and technology
  oriented concepts
• EEM Enterprise Engineering Methodology
• Describes process of enterprise engineering.
  Process model or structured procedure with
  detailed instructions for each enterprise
  engineering and integration activity.
• EMLs Enterprise Modeling Languages
• Provides modeling constructs for modeling of
  human roles, processes and technologies
• GEMCs Generic Enterprise Modeling Concepts
• Define the meaning of enterprise modeling
  constructs. Natural language explanation of
  meaning of modeling concepts (glossaries), meta
  model (ER diagram) of concepts available in
  modeling languages
• PEMs Partial Enterprise Model
• Provide reusable reference models and designs of
  human roles, processes and technology. Capture
  characteristics common to many enterprises within
  or across one or more sectors. Aka reference
  models, reference architectures. Speed up the
  process of engineering (reusability)
• EET Enterprise Engineering Tools
• Support enterprise engineering analysis, design
  and use of enterprise models
• EMs Enterprise Models
• Represent the particular enterprise, expressed
  using enterprise modeling languages. May consist
  of several enterprise designs and models to
  support analysis and operations of the
  enterprise.
• EMOs Enterprise Modules
• Provide implementable modules of human
  professions, operational processes, technologies.
  PS or SAP product modules are an example of an
  EM.
• EOS Enterprise Operational Systems
• Support the operation of the particular enterprise

26
(No Transcript)
27
Zachman Framework

• ISA Information Systems Architecture
• A taxonomy with 30 boxes or cells 6 columns, 5
  row

Data What Function How Network Where People Who Time When Motivation Why
Scope Planner / contextual
Business model Owner / conceptual
System model Designer / logical
Technology model Builder / physical
Detailed presentations Subcontractor / out-of context
Taxonomy 1) The classification of organisms in
an ordered system that indicates natural
relationships, 2) The science, laws, or
principles of classification systematics. 3)
Division into ordered groups or categories
28
(No Transcript)
29
"Extending and Formalizing the Framework for
Information Systems Architecture." J.F. Sowa and
J. A. Zachman. IBM Systems Journal, vol. 31, no.
3, 1992. http//www.research.ibm.com/journal/sj/31
3/sowa.pdf
30
Zachman rules

1. Columns have no order (or bias)
2. Each column has a simple, basic model
3. The basic model of each column must be unique
4. Each row represents a distinct, unique
   perspective
5. Each cell is unique
6. The composite or integration of all cell models
   in one row constitutes a complete model from the
   perspective of the row
7. The logic is recursive.
8. Models in a perspectives (row) map into higher
   perspectives
9. As-is and to-be versions of each cell model are
   possible
10. The logic of the framework can be applied to
    itself, to analyze the design and construction
    issues that affect that cell

"Extending and Formalizing the Framework for
Information Systems Architecture." J.F. Sowa and
J. A. Zachman. IBM Systems Journal, vol. 31, no.
3, 1992. http//www.research.ibm.com/journal/sj/31
3/sowa.pdf
31
Gartners Architecture Perspective
32
The expanded Gartner Framework
33
Patterns

• Patterns are logical models of technology, design
  ideas that can be reused and leveraged across the
  enterprise. They are usually industry standard
  and endure for a long time. We can think of them
  as blueprints that identify components, show
  roles, interactions and relationships
• Within a specific pattern, where is the emphasis
  and intensity?

34
Bricks

• Bricks provide device specificity for the pattern
• The following elements should be captured in a
  brick
• A description of the technology and its role
• Specific implications, dependencies, and
  deployment and management strategies
• Information about the state of the technology
• Vendor stability and asset management information
• Measure the technologys maturity at the brick
  level and then measure the maturity level of the
  portfolio of bricks. This provides an index of
  the organizations overall technology maturity
• Four maturity states
• Mainstream, retirement, containment, emergence

35
EAP tools
36
Gartner review of EA tools

• ASG Rochade
• Casewise Corporate Modeler
• Computas Metis
• IDS Scheer ARIS
• MEGA International
• Popkin Software System Architect
• Proforma ProVision
• Ptech Enterprise Framework

37
Gartner MarketScope ratings
38
Gartner EAP Tools Ratings
39
Vendors, criteria

• Companies
• Adaptive
• Agilense
• Alfabet
• Casewise
• IDS Scheer
• Mega International
• Popkin
• Proforma
• Select Business Solutions
• Simon Labs
• TeleLogic
• Troux

• Criteria
• Frameworks supported
• Zachman
• FEAF/TEAF
• C4ISR, DoDAF
• TOGAF
• Others
• Modeling languages
• UML
• MDA (OMG)
• BPML
• BPEL4WS
• BPMN
• ADML
• IDEF family
• ER/ DFD

40
Modeling languages
41
Basic concepts

• A modeling language is a set of constructs for
  building models of systems
• Models can be prepared at various stages of the
  system life-cycle
• The modeling language should be suited for the
  modeling task
• The modeling language should have sufficient
  expressive power to capture all the information
  needed in the model
• The modeling language should be easily understood
  by the intended audience
• Modeling languages fall into three categories a)
  data and object modeling (information view), b)
  activity and process modeling (function view) and
  c) multi-view modeling (multi-level)

42
Information modeling

• Information base
• A repository that contains accumulated,
  disseminated, structured information
• Physical models
• Records, arrays, strings, lists, etc.
• Logical models
• Sets, relations, mathematical symbol structures
• Conceptual models
• More expressive, semantic terms such as Entity,
  Activity, Agent, Goal

43
Semantic networks

• Ross Quillian proposed them in 1968
• Directed, labeled graphs
• Nodes in a semantic network represent concepts
• Links between nodes have semantic meaning (e.g.,
  isA, has, eats)
• horse -isA-gt animal -eats-gt food
• horse isA-gt animal madeOf-gt meat isA-gtfood
• Spreading activation
• http//www.jfsowa.com/pubs/semnet.htm
• http//www.semanticresearch.com/semantic/

44
Express

• ISO standard 10303-11
• Formal modeling language for the specification of
  static aspects of an informational model
• Object oriented constructs
• Basic element is the entity type, used to
  represent objects of the real world. Entities
  describe groups of instances
• http//www.infoloom.com/gcaconfs/WEB/granada99/ber
  .HTMN17

45
Object role modeling (ORM/NIAM)

• NAIM natural language information analysis
  method
• Unlike E/R diagrams, in ORM, attributes do not
  exist, but instead are expressed as a
  relationship
• Person country born
• Person was Born in Country
• Step-wise process
• Transform familiar information into facts, draw
  the fact types
• Add uniqueness constraints, check arity of fact
  types
• Add various constraints
• Final check
• Rich notational system,language
• http//www.agilemodeling.com/artifacts/ormDiagram.
  htm

46
Database Language SQL

• Originally not a complete programming language,
  but a data sublanguage
• The relational model gained prominence with a
  1974 paper by E.F. Codd, mathematical
  underpinnings
• Relational concepts relation, attribute, tuple
• SQL concepts table, column row
• DDL data definition language
• DML data manipulation language
• Semantic integrity constraints
• Referential integrity, triggers, constraints,

47
Petri Nets

• Introduced by C. A. Petri in 1962
• Discrete event systems (DES), such as
  manufacturing systems or information networks
• Modeling facilities
• Quantitative analysis performance (throughput),
  responsiveness (turn around time), utilization
  (size of queues),
• Qualitative analysis absence of deadlocks,
  ability to reach some states (reachability),
  ability to return to some pre-defined states
  (reversibility, home states)
• Places, transitions, arcs, weights, initial
  marking
• http//www.daimi.au.dk/PetriNets/introductions/aal
  st/

48
State transition diagrams

• Introduced in the 1950s
• Have played a major role in hardware design
• A STD is a graph whose nodes represent states of
  a system and whose arrows represents state
  transitions
• Related terms finite machine, finite automaton
• UML state machine http//www.agilemodeling.com/ar
  tifacts/stateMachineDiagram.htm

49
Data flow diagram

• Popular in the late 1970s, Gane and Sarson
• Used to show how processes communicate and store
  data
• Four concepts
• External entities (squares, sources or
  destinations of data)
• Processes (circles or rounded rectangles)
• Data flows (arrows)
• Data stores (open-ended rectangles)
• http//www.agilemodeling.com/artifacts/dataFlowDia
  gram.htm

50
IDEF family

• IDEF0 Function modeling
• Model decisions, actions, activities of an
  organization, derived from SADT
• IDEF1 Information modeling
• E/R modeling and relational model are influences
• Designed to capture information that exists in
  the enterprise
• Not a database design method
• IDEF1X Data modeling
• Most useful for logical database design
• IDEF2 System dynamics modeling
• Simulation modeling, what if analysis, predict
  what a system would do
• IDEF3 Process description capture
• Process flow, object state transitions
  scenario-driven
• IDEF4 Object oriented design
• Targets OO technology, not relational
• IDEF5 Ontology description
• Extracting the nature of a problem domain and
  storing it isA, system kind and relation type
  diagrams
• IDEF6 Information system design rationale
  capture
• Models why or why not a design is the way it is
  and how one arrived at that design
• http//www.idef.com/

51
Virtual enterprises

• Source Tolle, M. Bernus, P. (2003). Reference
  models supporting enterprise networks and virtual
  enterprises. International Journal of Networking
  and Virtual Organizations, Vol. 2, No.1.

52
Virtual Enterprise Reference Architecture

• VE a customer solution delivery system created
  by a temporary and re-configurable
  Information and Communication Technology (ICT)
  enabled aggregation of core competencies
• Firms create VEs to move quickly
• In order to move quickly, people, process,
  technology models need to be built quickly
• Reference models are key. They serve as a
  blueprint that firms follow in constructing and
  managing the VE
• VEs might include entire supply chains or just a
  collection of partners bringing a product to
  market

53
A sample VE
54
Creating a VE

• Partners must be prepared with the architecture
  (technical, human, process) with tested building
  blocks
• Building a VE architecture should be rules-based,
  not ad-hoc
• Must map architecture to core competencies (SOA)
• Should establish a set of reference architectures
  to support constructing the VE
• Rules should cover a range of typical issues
• Loosely coupled/controlled partners versus highly
  coupled/controlled
• Long term VEs versus short term
• Establish the kowledge management approach
• Data, metrics, lessons learned, alterations,
  modifications to the architectures

55
VERA
56
VERA views
57
View descriptions

• Functional
• Activities and business processes
• Information
• Data models, operational database designs
• Resource view
• Hardware, software resources, human resources
• Organizational view
• Models for designing the organization
• Allocation of resources to activities/processes

58
Relevant reference models
59
Relevant reference models
60
Relevant reference models
61
Governance, maturity
62
Typical situation
Customers
Architecture requirements
??
Functional staff
IS staff
Desired state
Customers
IS staff
Architecture requirements

Functional staff
63
Level 1 - Initial

• Informal IT Architecture Process Underway
• Processes are ad hoc and localized. Some IT
  Architecture processes are defined. There is no
  unified architecture process across technologies
  or business processes. Success depends on
  individual efforts.
• IT Architecture processes, documentation and
  standards are established by a variety of ad hoc
  means and are localized or informal.
• Minimal, or implicit linkage to business
  strategies or business drivers.
• Limited management team awareness or involvement
  in the architecture process.
• Limited. Operating Unit acceptance of the IT
  Architecture process.
• The latest version of the Operating Units IT
  Architecture documentation is on the Web. Little
  communication exists about the IT Architecture
  process and possible process improvements.
• IT Security considerations are ad hoc and
  localized.
• No explicit governance of architectural
  standards.
• Little or no involvement of strategic planning
  and acquisition personnel in enterprise
  architecture process. Little or no adherence to
  existing Standards.

64
Level 2 Under development

• IT Architecture Process Is Under Development
• The architecture process has developed clear
  roles and responsibilities.
• IT Vision, Principles, Business Linkages,
  Baseline, and Target Architecture are identified.
  Architecture standards exist, but not necessarily
  linked to Target Architecture. Technical
  Reference Model and Standards Profile framework
  established.
• Explicit linkage to business strategies.
• Management awareness of Architecture effort.
• Responsibilities are assigned and work is
  underway.
• IT Security Architecture has defined clear roles
  and responsibilities.
• Governance of a few architectural standards and
  some adherence to existing Standards Profile.
• Little or no formal governance of IT Investment
  and Acquisition Strategy. Operating Unit
  demonstrates some adherence to existing Standards
  Profile

65
Level 3 Defined

• Defined IT Architecture Including Detailed
  Written Procedures and Technical Reference Model
• The architecture is well defined and communicated
  to IT staff and business management with
  Operating Unit IT responsibilities. The process
  is largely followed.
• Gap Analysis and Migration Plan are completed.
  Fully developed Technical Reference Model and
  Standards Profile. IT goals and methods are
  identified.
• IT Architecture is integrated with capital
  planning investment control.
• Senior-management team aware of and supportive of
  the enterprise-wide architecture process.
  Management actively supports architectural
  standards.
• Most elements of Operating Unit show acceptance
  of or are actively participating in the IT
  Architecture process.
• Architecture documents updated regularly on
  Architecture Web Page.
• IT Security Architecture Standards Profile is
  fully developed and is integrated with IT
  Architecture.
• Explicit documented governance of majority IT
  investments.
• IT acquisition strategy exists and includes
  compliance measures to IT Enterprise
  Architecture. Cost-benefits are considered in
  identifying projects.

66
Level 4 Managed

• Managed and Measured IT Architecture Process
• IT Architecture process is part of the culture.
  Quality metrics associated with the architecture
  process are captured.
• IT Architecture documentation is updated on a
  regular cycle to reflect the updated IT
  Architecture. Business, Information, Application
  and Technical Architectures defined by
  appropriate de-jure and de-facto standards.
• Capital planning and investment control are
  adjusted based on the feedback received and
  lessons learned from updated IT Architecture.
  Periodic re-examination of business drivers.
• Senior-management team directly involved in the
  architecture review process.
• The entire Operating Unit accepts and actively
  participates in the IT Architecture process.
• Architecture documents are updated regularly, and
  frequently reviewed for latest architecture
  developments/standards.
• Performance metrics associated with IT Security
  Architecture are captured.
• Explicit governance of all IT investments. Formal
  processes for managing variances feed back into
  IT Architecture.
• All planned IT acquisitions and purchases are
  guided and governed by the IT Architecture.

67
Level 5 - Optimizing

• Continuous Improvement of IT Architecture Process
  
• Concerted efforts to optimize and continuously
  improve architecture process.
• A standards and waivers process are used to
  improve architecture development process
  improvements.
• Architecture process metrics are used to optimize
  and drive business linkages. Business involved in
  the continuous process improvements of IT
  Architecture.
• Senior management involvement in optimizing
  process improvements in Architecture development
  and governance.
• Feedback on architecture process from all
  Operating Unit elements is used to drive
  architecture process improvements.
• Architecture documents are used by every decision
  maker in the organization for every IT-related
  business decision.
• Feedback from IT Security Architecture metrics
  are used to drive architecture process
  improvements.
• Explicit governance of all IT investments. A
  standards and waivers process is used to improve
  governance-process improvements.
• No unplanned IT investment or acquisition
  activity

68
Governance models

• EAP governance is largely an IT affair
• EAP governance is run by a broader engineering
  group
• EAP is sponsored by the CIO, but has strong
  functional executive involvement (finance,
  marketing, sales, etc.)
• EAP is owned by the CEO
• William Shaw, Marriott President and COO We are
  beyond alignment. We are into convergence.

69
Steps to establishing governance

• Preconditions
• Establish trust and respect in IT leadership
• Improve functional-technical boundary knowledge
• CIO to establish good peer relationships
• The architecture business case must warrant CEO
  or board level attention
• Steps
• Secure VP-level interest and involvement
• Secure CEO acceptance or sponsorship
• Staff the EAP function
• Establish the governance group, agenda,
  engineering methodology
• Design monitoring, measurement and feedback
  mechanisms into the process

70
Unleashing the EAP process

• Unilateral (or anarchical) control over
  architecture begins to fade as federated control
  over architecture emerges
• A federated model?
• Balances local needs and central authority (state
  versus federal government rights)
• Is focused on systems integration (HEA p 619)
• Flexibility, agility, efficiency, quality
• Requires great team and governance skills
• Relies on multiple disciplines
• What should a federal government do?
• Provide for the common defense
• Provide a common infrastructure otherwise not
  possible (road design, railway standards)
• Gather and intensify scarce intellectual capital.
  Improve certain skills
• Use a carrot first and then a stick

71
EAP / systems integration methodology

• Use and adopt reference models
• Model the system functional (components and
  processes), information, resources, organization
• Harmonize component interactions (web services
  wrappers to deal with heterogeneity)
• Link together information and knowledge.
  Establish common ontologies. Planfully overcome
  semantic incompatibility between concepts used by
  different components
• Achieve new coordination levels