Building an Building an Enterprise Architecture Program Enterprise Architecture Program
at Saint Louis Universityat Saint Louis University
Building an Building an Enterprise Architecture Program Enterprise Architecture Program
at Saint Louis Universityat 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.
Agenda
• Introductions• Section 1: EA Overview• Section 2: Getting Started at SLU• Section 3: Advancing EA• Section 4: When We’ve Arrived…
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
Kevin Ballard
• Chief Architect• Department head of Business
Intelligence• Functional DBA and Information
Architect• Corporate IT Background (19 years)
Introductions
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
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…
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
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
Insert New Diagram Here
• Jim H.
Section 1: EA Overview
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
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
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
…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
EA Provides Context
Section 1: EA Overview
http://www-128.ibm.com/developerworks/rational/library/jan07/temnenco/index.html
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
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
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
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
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
42006Q
ODS Upgrade, Axiom, Identity
Management, Desktop Standards
42006Q
Announce / Establish EA Secure Management Support
Evangelize
- 1 22007Q Q
EDW
-2006Dec 2007Jan
Build virtualteam
12007Q
Oracle DBMS Upgrade
- Feb April2007
Establish Governance Model Establish Architecture Board
Integrate with PMO Framework
2007April
Identify and take architectural control
of strategic apps
2007Mar
Build PIM Establish Lifecycle
Management
42006Q
RoadmapEffort
2007July
PPPPP P1
Enterprise Architecture Phase 1 Timeline
-200610124version K. Ballard
- May Jun2007
2Plan Phase
2007Feb
Document currentstate
Initial Structure
• Enterprise Architecture (3 positions)• Architecture Council (19 positions)• Architecture Review Board proposed• Different Governance, Vision, Charters
Section 2: Getting Started at SLU
PIM beginnings…
Section 2: Getting Started at SLU
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
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
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
Proposed Entity Relationships
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
Section Three: Advancing EA
* Responsible, Accountable, Consult, Inform
Architecture Council (or members)
Architecture ReviewBoard
Enterprise Architecture(practitioners)
Project Office Change Control Board
2v. - PP2/23/2007 . PPPPP
InputsLegend
DecisionRequest
FYI
Referral
Technology Architecture Standards Governance Model
Deliverables
DecisionRequest
FYI
Referral
Approved
Request forInformation
Deferral ofdecision
Rejected
Conditionaldecision
DecisionRequest
FYI
ArchitectureReview
PIMvariancereview
Submit andAttend ARB
Intake Formand
Documentation
Intake Form andDocumentation
Agenda
Prod changePIM
compliant?
Agenda
Yes
CCB governs
Gate 1Review
No
Gate 2Review
Business Office, Security, Other
Governance Units
Referral
FYI
To Originator
- Add product to PIM- Status move on PIM- Remove item from PIM- Nonstandard use of item
- R&D early eval products- "Heads up" from IT units- Project gate 1 reviews
- IT governance units
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
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
Repository for E2AF Documentation Framework
Maturing Enterprise Architecture
Level 0 Level 1 Level 2 Level 3 Level 4 Level 5
Ad
min
istr
atio
n No architecture governance Need for standards committees identified Need for committees for architecture governance identified; EA articulating roles; committees forming
Architecture governance committees and roles defined; committees aligned and work smoothly
Governance and committees updated to incorporate changes to maturing EA framework; participants take ownership of roles
Committees proactively review activities and improve their processes; EA works with other EA organizations to share governance ideas
Pla
nn
ing No directed future state EA need identified; EA activities informal and
unstructuredEnterprise vision developing; EA tasks and resources being articulated; EA methodology in development
EA Program governance, framework, timelines, budget, and mission well defined; activities match plan.
EA plan reviewed and changed to improve initial EA program; metrics captured to measure progress against plan; goals set for future.
Action plans for process improvements based on captured metrics; EA works with other organizations on best practices and EA future improvements
Fra
mew
ork Architecture, processes, templates
undocumentedNo unified architecture process across technologies, business lines
EA program documented; architecture processes planned-tracked; templates and reusable information in development
Lifecycle management processes documented; architecture process models prepared; templates are used for consistency in documentation
Metrics for EA process & template effectiveness; corrective plans for process-template deficiencies; management meetings to govern framework changes
Lifecycle processes are ingrained in organization; captured metrics inform process improvements before issues are raised administratively; EA works with other organizations to share process and template ideas
Blu
epri
nt Current standards undocumented Documentation of business drivers, technology
strategy and standards informal and inconsistentBusiness drivers and strategy identified; repository need identified to store and disseminate artifacts
Consistent documentation maintained for business drivers, strategy, and classification of existing technology
Documentation of business drivers and strategy has become standard practice; managed products and lifecycle is standard practice; metrics from compliance process drives standards updates
Captured business and technology information is used along with business monitoring and technology trends to proactively improve business; EA works with other organizations to share ideas on business and technology trends
Co
mm
un
icat
ion
Executive level unaware of EA definitions or benefits
Need for EA awareness identified; little institutional communication about architecture processes
Executive level committed to EA definitions and benefits; EA awareness activities underway
Training provided for Senior Management on EA process and benefits; training/professional development for EA committees advanced
Formal communication process established and followed; process reviewed and changes to improve clarity and detail; EA awareness training in employee orientation; metrics document effectiveness of communication
Metrics proactively used to improve communication; EA works with other organizations to share ideas for communication processes
Co
mp
lian
ce No compliance process in organization Need for standards compliance process identified; compliance unstructured-informal-unmeasured
Organization has begun to develop compliance process to assure projects and enhancements are consistent with standards
A formal process is defined, documented, and applied for design and architectural change management; business case required for exceptions
Compliance to architecture standards and processes is common; quality metrics captured from business cases; compliance process reviewed and updated when deficiencies or enhancements are identified
Information gathered in compliance process informs framework and standards changes; architecture metrics inform business cases in development; EA works with other organizations to share best compliance practices
Inte
gra
tio
n No process to integrate IT investments across enterprise
Need to integrate common IT functions with EA planning identified; projects typically designed in isolation of architecture context
Need for Architecture Lifecycle and EA framework identified; basic mapping between EA and organizational business processes
EA program integrated with strategic planning and budgeting; touch points with enterprise management processes well-defined
EA used to guide development and acquisition; metrics document ROI in time and $; costs and benefits weighed in projects across organization; integration procedures reviewed as problems or enhancements require
EA process drives continuous innovation throughout the enterprise; Business influences Technology and vice-versa; metrics proactively drive improvements to integration; EA works with other organizations to share ideas for improved integration including project & procurement practices
Invo
lvem
ent Independent groups may work on single issue; no
program for architectural awarenessOrganization has identified need to make all staff EA-aware
EA educational sessions and materials to organization; EA concepts beginning to appear in normal meetings.
IT teams advance implementation of EA principles in planning, projects and operations; senior management participates in EA committees; business and technical staff participate in EA committees
Personnel across organization understand EA and touch points to their projects; organization captures metrics on staff awareness and satisfaction with EA processes and outcomes
Distributed departments work as contributors to architecture and processes; metrics inform action plans for EA marketing and education; EA works with other organizations to share ideas for distributed involvement in architecture.
Implementation Gaps
Based on the NASCIO (National Association of Chief Information Officers) Enterprise Architecture Maturity Model, adapted to SLU.
Bu
sin
ess
Cap
abili
ties
Organizational Maturity Level CharacteristicsParameters
Str
ateg
y
Strategic differentiators
Alignment of Architecture with organization
Auditable and accountable processes expectation
Need for standards with "teeth", selective focus on strategic activities
Saint Louis University Enterprise Architecture Maturity Model
Control hard-dollar costs driving tuition growth (competition and federal pressure)
Value of integration across activities and hierarchy (data sharing and security mandates)
Section Three: Advancing EA
Working Toward Maturity Level Two…
Section Three: Advancing EA
Organizational Maturity Growth
(up to Level 5)
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 and unstructured
Enterprise vision developing; EA tasks and resources being articulated; EA methodology in development
Framework Architecture, processes, templates undocumented
No unified architecture process across technologies, business lines
EA program documented; architecture processes planned-tracked; templates and reusable information in development
Blueprint Current standards undocumented Documentation of business drivers, technology strategy and standards informal and inconsistent
Business drivers and strategy identified; repository need identified to store and disseminate artifacts
Communication Executive level unaware of EA definitions or benefits
Need for EA awareness identified; little institutional communication about architecture processes
Executive level committed to EA definitions and benefits; EA awareness activities underway
Compliance No compliance process in organization Need for standards compliance process identified; compliance unstructured-informal-unmeasured
Organization has begun to develop compliance process to assure projects & enhancements are standards-based
Integration No process to integrate IT investments across enterprise
Need to integrate common IT functions with EA planning identified; projects typically designed in isolation of architecture context
Need for Architecture Lifecycle and EA framework identified; basic mapping between EA & organizational business processes
Involvement Duplicative work on a single issue; no program for architectural awareness
Organization has identified need to make all staff EA-aware
EA educational sessions and materials to organization; EA concepts beginning to appear in normal meetings.
Section Four: When We’ve Arrived…
• Better, Faster Cheaper• Positive Outcomes / Supporting
SLU’s Value Proposition• Action Architecture
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…
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…
EA Becomes “Action Architecture”
• 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
A mature EA program solves real world problems…
Section 4: When We’ve Arrived…
Building an Enterprise Architecture Program at Saint Louis University
Kevin Ballard Chief [email protected]
James Hooper Enterprise [email protected]
John AshbyEnterprise Architect [email protected]
Saint Louis University
Information Technology Services
3690 West Pine Mall
St. Louis, MO 63108-3304
Q&AQ&A
© 2007 Saint Louis University
Recommended Sites
• http://ea.slu.edu• http://www.bredemeyer.com• http://www.togaf.com• http://eajournal.blogspot.com• http://
www.nascio.org/nascioCommittees/ea/EAMM.pdf
Top Related