EA Educause Midwest 2007 Presentation
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

EA Educause Midwest 2007 Presentation

on

  • 584 views

 

Statistics

Views

Total Views
584
Views on SlideShare
583
Embed Views
1

Actions

Likes
0
Downloads
12
Comments
0

1 Embed 1

http://www.slideshare.net 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

EA Educause Midwest 2007 Presentation Presentation Transcript

  • 1. Building an Enterprise Architecture Program at Saint Louis University Copyright 2007 Saint Louis University. This work is the intellectual property of the author. Permission is granted for this material to be shared for non-commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of the author. To disseminate otherwise or to republish requires written permission from the author.
  • 2. Agenda • Introductions • Section 1: EA Overview • Section 2: Getting Started at SLU • Section 3: Advancing EA • Section 4: When We’ve Arrived…
  • 3. James Hooper • Bredemeyer-trained Enterprise Architect • 5 years as Director of Client/Systems Services and lead systems architect • 5 years+ as a lead systems architect • 15 years IT technical roles • Degrees in Biology and Management Information Systems Introductions
  • 4. Kevin Ballard • Chief Architect • Department head of Business Intelligence • Functional DBA and Information Architect • Corporate IT Background (19 years) Introductions
  • 5. John Ashby • 7 years in IT management: educational technology (classrooms, content/ distribution, computing) • 12 years academic media management • 14 years media services roles • 17 years as adjunct faculty • MA - Communication Introductions
  • 6. Section One: EA Overview • What is Enterprise Architecture? • Common Metaphors for EA • Two Manifestations of EA • Questions EA Asks… • Guiding Principles • Everyone has an architecture…
  • 7. The Purpose of Enterprise Architecture “EA provides a common basis for understanding and communicating how systems are structured to meet strategic objectives.” Source: Bredemeyer Consulting Section 1: EA Overview
  • 8. More specifically… Enterprise Architecture (EA) is… • Set of processes for describing the current and future state of the structures and behaviors of an enterprise. • Includes people, process and technology as architecture components. • For the purpose of aligning with the University’s strategies. Section 1: EA Overview
  • 9. Insert New Diagram Here • Jim H. Section 1: EA Overview
  • 10. Common Metaphors • More Like City Planning – High Level • “Connect the Dots” • The “glue” that connects Business and Technology. • A “bridge” between business problems and technology solutions. • EA: The Architecture of Business Capabilities Section 1: EA Overview
  • 11. EA: Two Major Manifestations • Establishing “IT Architecture Governance” as a part of “IT Governance” • Enterprise Architects engaged in “strategic differentiator” projects to ensure alignment. Section 1: EA Overview
  • 12. EA asks the following questions… • What are the top to bottom linkages between business strategy, processes, projects and technology and where are the gaps? • What technologies do SLU’s new projects require and do they align with business strategy? Section 1: EA Overview
  • 13. …and EA asks…. • What are the opportunities for reuse and simplification across organizations and projects? • What is the business impact of planned project or technology changes? Source: http://www.architectureandgovernance.com/articles/05-reyes.asp Section 1: EA Overview
  • 14. EA Provides Context http://www-128.ibm.com/developerworks/rational/library/jan07/temnenco/index.html Section 1: EA Overview
  • 15. Principles to Guide Architects • Minimalist Architecture Principle • Keep your architecture decision set as small as it possibly can be, while still meeting your architectural objectives. • If a decision can be delegated to someone with a more narrow scope of responsibility, then do so! • Decisions with Teeth Principle • Only make a decision part of your architecture if you can make it stick • There must be a process to ensure the decision is adhered to or you must be passionate enough about it to do what it takes. • Connect-the-Dots Principle • Show how decisions relate to higher level goals or decisions • You must document and communicate this traceability Section 1: EA Overview
  • 16. Section Two: Getting Started at SLU • Drivers for EA at SLU • First steps: Getting Started at SLU • Initial focus: Organize the IT architecture • Timeline on next steps
  • 17. Drivers for EA at SLU • Mitigate Risk Associated with Banner Upgrade and Related Projects • SAS 112 / SOX IT control levels • Lack of Standards and Documentation • Inconsistent or Undocumented Architectural Decisions • Lifecycle (Mis)Management • Lack of Coordination across Technical Boundaries and organizational silos Section 2: Getting Started at SLU
  • 18. How We Got Started • Our CIO decided to launch EA • We opted to “roll our own” • Formalized “Architect” as a job title through Broadbanding Classifications • Provided Training (Bredemeyer) to Enterprise Architects • Separated the Effort Into Two Phases Section 2: Getting Started at SLU
  • 19. Phase I – Getting ITS’ House In Order • Form the Structure • Recruit Architects • Start Producing Results Right Away – Create a Product Item Master to Document Standards – Integrate with Project Management Framework – Introduce Lifecycle Management Section 2: Getting Started at SLU
  • 20. Initial Structure • Enterprise Architecture (3 positions) • Architecture Council (19 positions) • Architecture Review Board proposed • Different Governance, Vision, Charters Section 2: Getting Started at SLU
  • 21. PIM beginnings… Section 2: Getting Started at SLU
  • 22. Phase II – Putting the “E” in EA • Gather and update University Mission, Values, Strategy documents • Look Outward to Business Units, Functional Areas, Provost’s Office, etc. • Adopt a Repository and Templates to support the framework and documentation needed by lines of business • Identify Savings and ROI measures Section 2: Getting Started at SLU
  • 23. Section Three: Advancing EA • Finishing up Phase 1: Governance Proposal and Validation • Publish the PIM, Integrate Governance with standards enforcement in IT business practice • Phase 2 begins Maturity Advancement
  • 24. IT Governance Relationships • IT Business Office (purchase screening for standards) • Change Control Board (standards enforcement in production systems) • Project Management Office (gate review, design standards review) Section Three: Advancing EA
  • 25. Proposed Entity Relationships
  • 26. Who decides what: RACI diagram* EA Architecture Architecture CCB, PMO, Tasks/Roles Review Board Council Others Owns the PIM A R Defines process/resolves exceptions to the PIM A R Provide input/expertise to PIM A R Propose changes to the PIM A R C Approves changes to the PIM A R C Governs Architectural Changes within EA framework A R I Professional Development Plan for Architects A R Initiate/propose architectural discussions A R I Decide or escalate proposed architectural items A R C Project Initiation Gate Review R Project Definition Gate Review A R Project Close-out Meeting Participation R Execute the processes defined by EA for architectural change control, project gate review, security review, and standards enforcement in business processes A R * Responsible, Accountable, Consult, Inform Section Three: Advancing EA
  • 27. Continuing: Addressing the Gaps • Functional architects identify products and systems lacking architectural oversight, refer to governance • Variability reduction (sure we have standards- lots of them!) • Standardizing of architectural issue tracking, documentation templates Section Three: Advancing EA
  • 28. Documentation and Repository • Adopt a framework to guide documentation • Standard templates and artifacts developed for consistency in documents • University executive access via web- based repository- all lines of business • Should all users have access to all artifacts? What is Public on the web? Section Three: Advancing EA
  • 29. Repository for E2AF Documentation Framework
  • 30. Maturing Enterprise Architecture Saint Louis University Enterprise Architecture Maturity Model Parameters Organizational Maturity Level Characteristics Level 0 Level 1 Level 2 Level 3 Level 4 Level 5 Planning Administration No architecture governance Need for standards committees identified Need for committees for architecture governance Architecture governance committees and roles Governance and committees updated to Committees proactively review activities and identified; EA articulating roles; committees defined; committees aligned and work smoothly incorporate changes to maturing EA framework; improve their processes; EA works with other EA forming participants take ownership of roles organizations to share governance ideas No directed future state EA need identified; EA activities informal and Enterprise vision developing; EA tasks and EA Program governance, framework, timelines, EA plan reviewed and changed to improve initial Action plans for process improvements based on unstructured resources being articulated; EA methodology in budget, and mission well defined; activities match EA program; metrics captured to measure captured metrics; EA works with other development plan. progress against plan; goals set for future. organizations on best practices and EA future improvements Framework Architecture, processes, templates No unified architecture process across EA program documented; architecture processes Lifecycle management processes documented; Metrics for EA process & template effectiveness; Lifecycle processes are ingrained in organization; undocumented technologies, business lines planned-tracked; templates and reusable architecture process models prepared; templates corrective plans for process-template deficiencies; captured metrics inform process improvements information in development are used for consistency in documentation management meetings to govern framework before issues are raised administratively; EA changes works with other organizations to share process and template ideas Blueprint Current standards undocumented Documentation of business drivers, technology Business drivers and strategy identified; repository Consistent documentation maintained for Documentation of business drivers and strategy Captured business and technology information is Business Capabilities strategy and standards informal and inconsistent need identified to store and disseminate artifacts business drivers, strategy, and classification of has become standard practice; managed used along with business monitoring and existing technology products and lifecycle is standard practice; technology trends to proactively improve metrics from compliance process drives business; EA works with other organizations to standards updates share ideas on business and technology trends Compliance Communication Executive level unaware of EA definitions or Need for EA awareness identified; little Executive level committed to EA definitions and Training provided for Senior Management on EA Formal communication process established and Metrics proactively used to improve benefits institutional communication about architecture benefits; EA awareness activities underway process and benefits; training/professional followed; process reviewed and changes to communication; EA works with other processes development for EA committees advanced improve clarity and detail; EA awareness training organizations to share ideas for communication in employee orientation; metrics document processes effectiveness of communication No compliance process in organization Need for standards compliance process identified; Organization has begun to develop compliance A formal process is defined, documented, and Compliance to architecture standards and Information gathered in compliance process compliance unstructured-informal-unmeasured process to assure projects and enhancements are applied for design and architectural change processes is common; quality metrics captured informs framework and standards changes; consistent with standards management; business case required for from business cases; compliance process architecture metrics inform business cases in exceptions reviewed and updated when deficiencies or development; EA works with other organizations enhancements are identified to share best compliance practices Integration No process to integrate IT investments across Need to integrate common IT functions with EA Need for Architecture Lifecycle and EA framework EA program integrated with strategic planning and EA used to guide development and acquisition; EA process drives continuous innovation enterprise planning identified; projects typically designed in identified; basic mapping between EA and budgeting; touch points with enterprise metrics document ROI in time and $; costs and throughout the enterprise; Business influences isolation of architecture context organizational business processes management processes well-defined benefits weighed in projects across organization; Technology and vice-versa; metrics proactively integration procedures reviewed as problems or drive improvements to integration; EA works with enhancements require other organizations to share ideas for improved integration including project & procurement practices Involvement Independent groups may work on single issue; no Organization has identified need to make all staff EA educational sessions and materials to IT teams advance implementation of EA principles Personnel across organization understand EA and Distributed departments work as contributors to program for architectural awareness EA-aware organization; EA concepts beginning to appear in in planning, projects and operations; senior touch points to their projects; organization architecture and processes; metrics inform action normal meetings. management participates in EA committees; captures metrics on staff awareness and plans for EA marketing and education; EA works business and technical staff participate in EA satisfaction with EA processes and outcomes with other organizations to share ideas for committees distributed involvement in architecture. Control hard-dollar costs driving tuition growth (competition and federal pressure) Value of integration across activities and hierarchy (data sharing and security mandates) Strategy Need for standards with "teeth", selective focus on strategic activities Auditable and accountable processes expectation Alignment of Architecture with organization Implementation Gaps Strategic differentiators Based on the NASCIO (National Association of Chief Information Officers) Enterprise Architecture Maturity Model, adapted to SLU. Section Three: Advancing EA
  • 31. Working Toward Maturity Level Two… Organizational Maturity (up to Level 5) Growth Metric Level 0 Level 1 Level 2 Administration No architecture governance Need for standards committees identified Need for committees for architecture governance identified; EA articulating roles; committees forming Planning No directed future state EA need identified; EA activities informal Enterprise vision developing; EA tasks and and unstructured resources being articulated; EA methodology in development Framework Architecture, processes, templates No unified architecture process across EA program documented; architecture undocumented technologies, business lines processes planned-tracked; templates and reusable information in development Blueprint Current standards undocumented Documentation of business drivers, Business drivers and strategy identified; technology strategy and standards informal repository need identified to store and and inconsistent disseminate artifacts Communication Executive level unaware of EA definitions Need for EA awareness identified; little Executive level committed to EA or benefits institutional communication about definitions and benefits; EA awareness architecture processes activities underway Compliance No compliance process in organization Need for standards compliance process Organization has begun to develop identified; compliance unstructured- compliance process to assure projects & informal-unmeasured enhancements are standards-based Integration No process to integrate IT investments Need to integrate common IT functions Need for Architecture Lifecycle and EA across enterprise with EA planning identified; projects framework identified; basic mapping typically designed in isolation of between EA & organizational business architecture context processes Involvement Duplicative work on a single issue; no Organization has identified need to make EA educational sessions and materials to program for architectural awareness Section all staff EA-aware Three: Advancing EA organization; EA concepts beginning to appear in normal meetings.
  • 32. Section Four: When We’ve Arrived… • Better, Faster Cheaper • Positive Outcomes / Supporting SLU’s Value Proposition • Action Architecture
  • 33. Better, Faster, Cheaper • “Consulting firm Meta Group Inc. says companies that embrace EA spend 30% less on IT and are more adaptive and make better decisions.” Source: CFO.com Section 4: When We’ve Arrived…
  • 34. Top Outcomes / Supporting SLU’s Value Proposition • To support decision making • Inform the IT portfolio • Deliver roadmaps for managed change • Support systems development • Manage complexity and reduce cost Source: The Institute for Enterprise Architecture Development Section 4: When We’ve Arrived…
  • 35. EA Becomes “Action Architecture” A mature EA program solves real world problems… • Opening eight application windows to answer a student’s question • Managers scrambling for information they need to make decisions • Projects not tied to strategic objectives • Silos of applications Section 4: When We’ve Arrived…
  • 36. Q&A Saint Louis University Information Technology Services 3690 West Pine Mall St. Louis, MO 63108-3304 Kevin Ballard James Hooper John Ashby Chief Architect Enterprise Architect Enterprise Architect kballar2@slu.edu hooper@slu.edu ashbyjm@slu.edu Building an Enterprise Architecture Program at Saint Louis University © 2007 Saint Louis University
  • 37. Recommended Sites • http://ea.slu.edu • http://www.bredemeyer.com • http://www.togaf.com • http://eajournal.blogspot.com • http://www.nascio.org/nascioCommitte es/ea/EAMM.pdf