Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
708
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
34
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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 – What’s in it?
    • EAP does not define one architecture, but multiple architectures
    • There is not one perspective for EAP, but many
      • Planner, owner, designer, builder, subcontractor 1
      • Each level is not just more detail, but with essential differences 2
    • 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)
    • 1 Sowa, J.F. & Zachman, J.A. “Extending and formalizing the framework for information systems architecture.” IBM Systems Journal, Vol. 31, No. 3, 1992.
    • 2 Zachman, 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
      • Architecture’s 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 dis integration 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 From “Reflecting on the strategy process,” Mintzberg, Henry. Sloan Management Review. Vol. 40 No. 3. Spring 1999. 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. Configuration How organizations use degrees of freedom to maneuver through environments. Limits to strategic choice due to environmental conditions. Environmental Focus on common interest and integration, strategy formation is a social process rooted in culture. The threat of Japan in the 1980s spurred this. Cultural Development of strategy is political, a process involving bargaining, persuasion and confrontation among actors who divide power. Power Disjointed incrementalism, logical incrementalism, muddling-through, emergent strategies, the learning organization. Learning Strategies originate in people’s minds as frames, models, maps, concepts, schemas. Cognitive biases, heuristics, naturalistic decision making. Creativity. Cognitive Focus on the CEO, intuition, metaphor. Forceful leader. Start-up, niche. Leader maintains close control on his or her formulated vision Entrepreneurial Positions selected through formalized analysis of industry situations. Porter’s five forces, PIMS, Boston Consulting Group. Positioning Formal, decomposable into discrete steps, checklists, techniques. Planning Senior management formulates clear, simple and unique strategies in a deliberate process of conscious thought Design
  • 13. Types of strategies Intended Strategy Realized Strategy Unrealized Strategy Emergent Strategy Deliberate 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 can’t 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 (don’t 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 4:1 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 doesn’t 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 them 1
      • The hierarchical structuring of knowledge about things by subcategorizing them according to their essential (or at least relevant and/or cognitive) qualities 1
      • 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 Aristotle’s 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.  
  • 27. Zachman Framework
    • ISA – Information Systems Architecture
    • A taxonomy with 30 boxes or cells: 6 columns, 5 row
    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 Detailed presentations Subcontractor / out-of context Technology model Builder / physical System model Designer / logical Business model Owner / conceptual Scope Planner / contextual Motivation Why Time When People Who Network Where Function How Data What
  • 28.  
  • 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/313/sowa.pdf
  • 30. Zachman rules
    • Columns have no order (or bias)
    • Each column has a simple, basic model
    • The basic model of each column must be unique
    • Each row represents a distinct, unique perspective
    • Each cell is unique
    • The composite or integration of all cell models in one row constitutes a complete model from the perspective of the row
    • The logic is recursive.
      • Models in a perspectives (row) map into higher perspectives
      • As-is and to-be versions of each cell model are possible
      • 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/313/sowa.pdf
  • 31. Gartner’s 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 technology’s maturity at the brick level and then measure the maturity level of the portfolio of bricks. This provides an index of the organization’s 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-> animal -eats-> food
      • horse –isA-> animal –madeOf-> meat –isA->food
    • 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.HTM#N17
  • 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/aalst/
  • 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/artifacts/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/dataFlowDiagram.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. Architecture requirements IS staff Functional staff Customers ?? Customers Functional staff IS staff Architecture requirements $$ Typical situation Desired state
  • 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 Unit’s 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