Estab Successful EA Program Office.ppt


Published on

Published in: Education, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • The discipline of EA has enjoyed a rapid growth because business leaders recognize it’s potential to make business changes less costly. Allows leaders to align IT investments to business needs – Strategic goals Project managers will increasingly be asked to explain EA to guide projects that interact with EA program offices to establish EA programs manage new projects under existing EA programs Also in the federal government – EA was done to satisfy Clinger/Cohen then they decided they needed program offices – so they just happened.
  • First I want to level the playing field. Many of you know what and EA is and why it has become so important. Others do not know, so I want to provide this background. Then, I’ll get to the meat of this session. Like anything else as successful EA program depends on the EA program office providing value. There are many correlations between a PMO and an EA Program Office.
  • An enterprise is a business organization performing functions of some scope, complication or risk. An architecture is a form or structure or the practice of designing structures The IEEE definition of EA is the simplest: the fundamental organization of an enterprise. The Federal Enterprise Architecture Program Management Office’s definition is very descriptive.
  • Or we could say it is the form or structure of a business organization. Did we say anything about it being limited to IT?
  • John Zachman is considered the father of Enterprise Architecture. He wrote his first EA paper while working for IBM in 1987. Therefore this paper still belongs to IBM. He was an information strategist working in the Aerospace industry and with that exposure wondered why we did less planning for information systems than we did to build an airplane. Between 1970 and 1987, he validated his analogy of IT to airplane design and construction with other industries. In fact to help people understand Enterprise Architects sometimes use a house analogy. Mr. Zachman retired from IBM in 1990, after 26 years.
  • For each perspective there are six fundamental aspects based on 6 interrogatives: What is it made of? How does it function? Where are things located? Who is involved? When do things happen? Why are things done? Motivation There are also 6 perspectives. Some illustrate the business architecture and some represent the technical architecture. The technical rows are easy.
  • Planner Scope and boundary views – similar to community planner Owner Business needs and requirements Designer – Logical view – blue prints, wiring diagrams, plumbing diagrams Builder - physical view – specifically were everything is located and what are the materials needed to build Sub-contractor - detailed view of specific sub-set of the whole User in the functioning enterprise operational view
  • This is a non-IT EA example.
  • What is our motivation(s) for creating an EA? There are many benefits to be derived from EAs. The more complex something is the harder it is to understand it without documentation. Identifies gaps and overlaps allowing the owners to eliminate waste and streamline processes. When we eliminate duplication we can share resources and save $$ Engineering something before it is built reduces risks and saves $$$
  • The greater the complexity the greater and the greater the envisioned change the greater EA value.
  • ROI or ROA???
  • The Clinger-Cohen Act of 1996 mandated that Federal Agencies develop and maintain an enterprise IT architecture. Federal Enterprise Architecture Framework (FEAF) was established in 1999 by the Chief Information Officers (CIO) in response to this mandate. OMB Circular A-130 – 2000 further explained what the Clinger/Cohen act meant and numerated what was intended to be in the Enterprise Architecture. The E-Government Act - 2002 directs agencies to collaborate and develop consistent citizen centric e-government systems (eliminating duplication and sharing processes or systems) and performance measure. OMB Circular A-11 – 2004 OMB Circular No. A-11 provides Federal Agencies with guidance on preparing the FY 2006 budget submission. This directive also required agencies to have an Enterprise Architecture before OMB would release funding. OMB continues to raise the bar
  • Cross Agency initiative are increasing: SmartBuy E-Gov Act of 2002 Intel Reform Act National Information Exchange Model VA Health Program Katrina Relief
  • Dick Burk is the Federal Enterprise Architect Program Manager – the Federal Chief Architect. His vision is that the federal government will share business processes, data and technical solutions. Therefore the architecture from all of the Departments and Agencies must be shared and capable of integration.
  • Exhibit 300
  • Similar to defining the scope.
  • Very similar to a Project Mgmt plan
  • Sequencing plan is really a project schedule
  • Estab Successful EA Program Office.ppt

    1. 1. Establishing a Successful Enterprise Architecture Program Office Presented by: Annette Hobbs, PMP [email_address] for Baltimore PMI Chapter
    2. 2. Agenda <ul><li>Background </li></ul><ul><ul><li>What is Enterprise Architecture (EA)? </li></ul></ul><ul><ul><li>Why is EA important? </li></ul></ul><ul><li>How to create a successful EA program office </li></ul><ul><li>Questions and Answers </li></ul>
    3. 3. What is Enterprise Architecture? <ul><li>The fundamental organization of an enterprise [ANSI/IEEE std 1471-2000] </li></ul><ul><li>The discipline of creating a blue print of an agency’s business, data, applications and technology [FEA-PMO ] </li></ul><ul><li>Enterprise [Houghton Mifflin] </li></ul><ul><ul><li>An undertaking , especially one of some scope, complication, and risk. </li></ul></ul><ul><ul><li>A business organization . </li></ul></ul><ul><ul><li>Industrious, systematic activity, especially when directed toward profit: Private enterprise is basic to capitalism. </li></ul></ul><ul><li>Architecture [Webster] </li></ul><ul><ul><li>The practice of designing structures (a discipline) </li></ul></ul><ul><ul><li>A coherent form or structure (an attribute) </li></ul></ul>
    4. 4. Or we could say: <ul><li>Enterprise Architecture </li></ul><ul><ul><li>Is the practice of designing and documenting the form or structure of a business organization’s undertaking. </li></ul></ul>
    5. 5. Do all enterprises have an architecture? <ul><li>Absolutely!!!! </li></ul><ul><li>Most enterprise architectures were not planned, they just happened. </li></ul>
    6. 6. A large part of the effort <ul><li>Involves analyzing and documenting the current architecture, as well as, planning, designing and engineering the future architecture. </li></ul>
    7. 7. EA Origin – John Zachman <ul><li>Mr. Zachman focused on architecture since 1970. His 1st article and the original framework was published in 1987 (“A Framework for Information Systems Architecture,” IBM Systems Journal, vol. 26(3), 1987. ). </li></ul><ul><li>In 1992 John Zachman and John Sowa wrote another article (“Extending and Formalizing the Framework for Information Systems Architecture.&quot; J.F. Sowa and J. A. Zachman. IBM Systems Journal, vol. 31, no. 3, 1992. ) expanded the framework to its current 36 cell framework (“Enterprise Architecture – A Framework”). </li></ul>Source:
    8. 8. Zachman’s A Framework for Enterprise Architecture ® John A. Zachman, Zachman International http://www.zachmaninternational.coml Business Technical
    9. 9. Perspectives <ul><li>Planner </li></ul><ul><li>Owner </li></ul><ul><li>Designer </li></ul><ul><li>Builder </li></ul><ul><li>Sub-contractor </li></ul><ul><li>User in the functioning enterprise </li></ul>
    10. 10. Zachman – for School Classroom Source: O’Rourke, C. (2003); Enterprise Architecture Using the Zachman Framework ; Course Technology Prepared students Timetables Students & teachers Classroom Montessori or individualization Books Functioning Enterprise Strategy & tactics based on plan, time, location & students Attendance Dismissals Security needs Location of classroom materials Lesson plan Arrange classroom things Sub-contractor Teacher rules and guidelines Teacher assignments Class assignments to remove conflicts Realistic location for activities Course plan based on enrollment & facility Practical material composition Builder Grading rules and guidelines Student and teacher interaction Teacher and student ratios Preferred location of teaching activities Optimal delivery of course plan Optimal material composition Designer Scholastic achievement targets Teaching schedule Teacher workflow Location of facilities Delivery according to student needs Material of classroom content Owner Government mandates School calendar Professors Instructors Staff Delivery technique Approved teaching delivery Approved Curriculum Planner Why Motivation When Time Who People Where Locations How Processes What Things
    11. 11. Why is EA Important? <ul><li>Enterprise Architectures (EA) help align the infrastructure with the business mission. </li></ul><ul><ul><li>Provides details of relationships. </li></ul></ul><ul><ul><li>Identifies gaps between needs and capabilities. </li></ul></ul><ul><ul><li>Describes where we are and where we are going. </li></ul></ul><ul><li>EA is a tool; for when “systems” are built they become business tools. </li></ul><ul><ul><li>Provides communications mechanism between business stakeholders because stovepiped-processes and systems lead to wasteful duplication. </li></ul></ul><ul><ul><li>Promotes interoperability and resource sharing providing greater potential for cost savings. </li></ul></ul>“ Can’t afford not to. The alternative is to suboptimize the enterprise’s performance and results.”, Randy Hite, Director of Information Technology Issues at GAO
    12. 12. Zachman on EA value <ul><li>Without the EA you can NOT achieve: </li></ul><ul><li>IT alignment with the business goals </li></ul><ul><li>Integration </li></ul><ul><li>Change management </li></ul><ul><li>Reduced time to market </li></ul>Speech at Data Management and Information Quality Conferences in the UK, 7-10 November 2005
    13. 13. Change Management <ul><li>EA’s value is tied directly to its ability help organizations deal with complexity and change. The greater the complexity and the greater the envisioned change , the greater will be the EA value to facilitate that change. </li></ul><ul><li>Readily available descriptive representations of the enterprise </li></ul><ul><li>Ability to unify and integrate business processes across the enterprise </li></ul><ul><li>Ability to unify and integrate data across the enterprise </li></ul><ul><li>Increased flexibility of the enterprise to link with external partners </li></ul><ul><li>Increased agility by lowering the &quot;complexity barrier“. </li></ul><ul><li>Reduced solution delivery time and development costs by maximizing reuse of enterprise models </li></ul><ul><li>Ability to create a common vision of the future shared by the business and IT communities = continuous business/IT alignment </li></ul>Source: Brown, A. (2004), “ Enterprise Architecture Value Proposition”
    14. 14. EA Return on Investment or Return on Asset <ul><li>Return on Investment: </li></ul><ul><ul><li>John Hancock realized a $6.25M savings on redundancies discovered. </li></ul></ul><ul><ul><li>Dow realized $300M savings on revenue from implemented a new project identified through EA work. </li></ul></ul><ul><ul><li>Key Corp realized a 1 year savings of $7M in reduction in software maintenance </li></ul></ul><ul><li>Return on Asset : </li></ul><ul><ul><li>EA helps you make decisions that will in due course improve your business’ productivity </li></ul></ul>Source: Blevins, T. (2004, April). “Enterprise Architecture: Return on Investment”.
    15. 15. Federal Government EA History <ul><li>The Clinger-Cohen Act - 1996 </li></ul><ul><li>Federal Enterprise Architecture Framework (FEAF) - 1999 </li></ul><ul><li>OMB Circular A-130 - 2000 </li></ul><ul><li>The E-Government Act - 2002 </li></ul><ul><li>OMB Circular A-11 – 2004 </li></ul><ul><li>Various OMB memorandums </li></ul>
    16. 16. OMB’s EA Assessment Framework for 2006 <ul><li>Use your EA to demonstrate results </li></ul><ul><li>Do you have an EA? Does it integrate cross agencies? </li></ul><ul><li>Does it show (business) results? </li></ul>
    17. 17. Future of EA in Federal Government E-Gov initiatives LOB Centers of Excellence Smart Buy Implementation/use of Government-wide Lower level Architectures include Department and Agency solutions Agencies include Gov-wide Initiatives in their EA Department/Agency Specific A gencies Contribute to Gov-wide Initiatives Source: Dick Burk Briefing at IAC meeting 1/27/2006 Program Solution Program Solution Program Solution Program Solution Agency/Bureau Solutions Department/Agency Solutions Federal Government-wide Solutions
    18. 18. Capital Investment Planning Strategic Plan Enterprise Architecture Migration Plan FY FY FY FY $$$ $$$ $$$ $$$ $$$ $$$ $$$ $$$ $$$ $$$ $$$ $$$ Maps Investment to Returns Today’s Architecture Future Architecture (today +)
    19. 19. Now that we understand what an EA is and its value to an organization Let’s talk about how to establish a successful EA program office
    20. 20. Staff the Program Office <ul><li>Typically a staff of 4-6 people working closely with functional staff and system developers </li></ul><ul><ul><li>Chief Architect </li></ul></ul><ul><ul><li>Business Architect </li></ul></ul><ul><ul><li>Systems Architect </li></ul></ul><ul><ul><li>Data Architect </li></ul></ul><ul><ul><li>EA Tool Expert </li></ul></ul><ul><li>Make sure staff is qualified and trained </li></ul>
    21. 21. Identify other stakeholders <ul><li>Sponsor – Champion of the EA program & ensures resources </li></ul><ul><li>Business Manager – Participates in EA decisions and promotes EA solutions </li></ul><ul><li>Business End-Users – Identifies requirement and provides feedback on results of solutions </li></ul><ul><li>CIO – Executive leader & primary EA decision maker </li></ul><ul><li>Other Chief Architects of related businesses </li></ul>
    22. 22. Determine the purpose of “your” EA <ul><li>This is unique to each organization </li></ul><ul><li>Helps answer some other questions that will need to be answered for future decisions </li></ul><ul><li>Helps determines the depth and breadth of the EA effort </li></ul>
    23. 23. Create a charter <ul><li>Similar to one for projects </li></ul><ul><li>Short, concise but informative </li></ul><ul><li>Obtain signatures </li></ul><ul><li>May be called other names in different organizations </li></ul>
    24. 24. Select an EA Framework Below is a partial list of available frameworks <ul><li>Zachman </li></ul><ul><li>EA 3 – Scott Bernard </li></ul><ul><li>Federal Enterprise Architecture Framework (FEAF) </li></ul><ul><li> </li></ul><ul><li>Department of Defense Architecture Framework (DODAF) </li></ul><ul><li> </li></ul><ul><li>Gartner Group </li></ul><ul><li>Purdue Enterprise Reference Architecture </li></ul><ul><li>Information Framework (IFW) </li></ul><ul><li>Treasury Enterprise Architecture Framework (TEAF) </li></ul><ul><li>NIST Enterprise Architecture Framework </li></ul><ul><li>TOGAF Open Group </li></ul><ul><li>The framework should support your organization’s specific needs, uses and scope of the effort </li></ul>
    25. 25. Determine and Document EA Implementation Methodology <ul><li>Detailed step-by-step description </li></ul><ul><li>Describes how EA program will be: </li></ul><ul><ul><li>Established </li></ul></ul><ul><ul><li>Executed </li></ul></ul><ul><li>Describes how the EA documentation will be: </li></ul><ul><ul><li>Developed </li></ul></ul><ul><ul><li>Maintained </li></ul></ul><ul><ul><li>Used </li></ul></ul>
    26. 26. Determine Methods for Collecting and Documenting EA <ul><li>Centralized </li></ul><ul><ul><li>Makes integration and maintenance easier </li></ul></ul><ul><ul><li>Might make buy-in harder </li></ul></ul><ul><ul><li>Are there enough resources with the necessary skills? </li></ul></ul><ul><li>Decentralized </li></ul><ul><ul><li>Make buy-in easier </li></ul></ul><ul><ul><li>Decentralized offices might not participate </li></ul></ul><ul><ul><li>Makes integration and maintenance harder </li></ul></ul><ul><ul><li>Program Office must create guidelines and standards that will continually be challenged </li></ul></ul><ul><li>Combination </li></ul><ul><ul><li>Program Office provides overarching enterprise structure for starting the effort </li></ul></ul><ul><ul><li>Program Office facilitates modeling and documentation sessions </li></ul></ul><ul><ul><li>Business organizations must provide subject matter experts </li></ul></ul><ul><ul><li>Resources and schedules are challenging </li></ul></ul><ul><ul><li>Requires strong EA sponsorship at the right level in the organization </li></ul></ul>
    27. 27. Establish Governance <ul><li>How will conflicts be resolved? </li></ul><ul><li>How will changes be approved? </li></ul><ul><li>Who will approve changes? </li></ul><ul><li>How will versions be controlled? </li></ul><ul><li>How will the EA be enforced? </li></ul><ul><li>How often will EA documents be re-published? </li></ul><ul><li>Etc. </li></ul>
    28. 28. Develop an EA Management Plan <ul><li>Documents the enterprise’s: </li></ul><ul><ul><li>Summary of the current and future architecture </li></ul></ul><ul><ul><li>Performance gaps, </li></ul></ul><ul><ul><li>Planned solutions </li></ul></ul><ul><ul><li>Resource requirements, </li></ul></ul><ul><ul><li>EA management process </li></ul></ul><ul><ul><li>EA implementation methodology </li></ul></ul><ul><ul><li>EA framework </li></ul></ul>
    29. 29. EA Management Plan (continued) <ul><li>Living document </li></ul><ul><li>Updated at regular intervals (annually) </li></ul><ul><li>Placed under version control </li></ul><ul><li>Sequencing sub-plan section: </li></ul><ul><ul><li>Tasks </li></ul></ul><ul><ul><li>Milestones </li></ul></ul><ul><ul><li>Timeframes for implementing new EA components and artifacts </li></ul></ul><ul><ul><li>May have dependencies </li></ul></ul>
    30. 30. Select Tools <ul><li>No single tool currently exists </li></ul><ul><li>Types of tools to consider: </li></ul><ul><ul><li>Database or Repository </li></ul></ul><ul><ul><li>Documentation tools </li></ul></ul><ul><ul><li>Communication tools </li></ul></ul><ul><ul><li>Modeling tools </li></ul></ul><ul><ul><li>Analysis tools </li></ul></ul><ul><ul><li>Business intelligence tools </li></ul></ul><ul><ul><li>Decision support tools </li></ul></ul><ul><li>Initial tool needed is the repository </li></ul>
    31. 31. Purpose of EA Repository Tool <ul><li>Single place for storage & retrieval of EA artifacts </li></ul><ul><li>Easy access </li></ul><ul><li>“One-stop-shop” for all the documents </li></ul>
    32. 32. Places to Look for EA Tool Assessments <ul><li>Gartner Group studies </li></ul><ul><li>Institute for Enterprise Architecture Developments (IFEAD) tools assessment and EA Tool Selection Guideline </li></ul>
    33. 33. Don’t forget the following critical steps: <ul><li>Develop a Communications Plan </li></ul><ul><li>Build templates and offer good examples </li></ul><ul><li>Obtain buy-in from participants </li></ul><ul><li>Manage stakeholders </li></ul><ul><li>Use EA for management decisions </li></ul><ul><ul><li>Analysis tools </li></ul></ul><ul><ul><li>Decision support tools </li></ul></ul>
    34. 34. Questions & Discussion