Your SlideShare is downloading. ×
0
Enterprise Architecture
Enterprise Architecture
Enterprise Architecture
Enterprise Architecture
Enterprise Architecture
Enterprise Architecture
Enterprise Architecture
Enterprise Architecture
Enterprise Architecture
Enterprise Architecture
Enterprise Architecture
Enterprise Architecture
Enterprise Architecture
Enterprise Architecture
Enterprise Architecture
Enterprise Architecture
Enterprise Architecture
Enterprise Architecture
Enterprise Architecture
Enterprise Architecture
Enterprise Architecture
Enterprise Architecture
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Enterprise Architecture

479

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
479
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
32
Comments
0
Likes
0
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
  • I want to thank you for inviting me here to speak on “Aligning Enterprise Architecture and ERP, Enterprise Resource Planning”. I believe there is a fundamental opportunity and relationship for both of these enterprise programs.
  • Let’s look at the history and current state of these enterprise programs: For Oregon State Government’s Enterprise Architecture: 09-11 DAS POP requests creation of EA & Standards Program. The Agency Directors in 2004 and again in 2006 documented a need for effective, enterprise-level planning and IT alignment. I participated in both of those sets of agency director interviews. The 2007-11 Enterprise Information Resources Management Strategy endorsed by CIOC and the Administrative Business Directors call for Enterprise business, technical architecture and standards. And, If approved by Legislature, EA and Standards Program would begin July 2009. On the other hand, DAS and ODOT Directors have agreed to develop an Enterprise Resource Planning ERP Program that will first be piloted at ODOT, but aspects will serve as replacement system for Finance, HR and Procurement over time. To that end DAS and ODOT created an interagency agreement Each has 09-11 POPs packages An RFP for pre-implementation services was created for the Integrated Systems ERP. And, a Joint DAS/ODOT Steering Committee and Charter has been established.
  • But Enterprise Architecture and ERP Alignment has been Elusive. In a perfect world, the State would have already have completed an Enterprise Architecture. Showing …… The State’s Business Architecture The Information and Data Architecture The supporting Applications Architecture, And the underlying Technology Architecture On the one hand, Enterprise Architecture equips us with a Sustainable Business Architecture for best-in-class Decision Making. With Alignment of EA to business needs. A repeatable EA framework. Architecture that is visible across all State agencies. On the other hand Enterprise Resource Planning can define the AS-IS and TO-BE states for systems supporting Human Resources, Finance and Procurement. The Central Services of our organizations.
  • . The goal is that Enterprise Architecture should INFORM ERP. So that one is supporting the other.
  • Because Developing the Right Perspective is Critical to the success of both Enterprise Programs. EA has the responsibility of SHARED INTEREST, including an Enterprise perspective, providing a migration path to move toward target architectures, and establishing a consistent EA methodology statewide for repeatable processes. ERP has TARGETED INTEREST, including being informed by EA, developing rich requirements and business process models, many executive agency stakeholders who have a true stake to ensure they provide their agencies input and requirements for a statewide ERP system; and of course ensuring that the ERP implementation is bulletproof. Because when we successfully unite these two and really get it right, then there are OPPORTUNITIES and STEWARDSHIP for improve performance, Introduction of new capabilities, expanded responsibilities, reduced costs, and leverage of new technology Develop a target architecture that reflects the enterprise’s need to evolve its information resources. Develop a migration plan to move towards the target architecture. Adopt a set of architectural principles to guide decision-making as an ongoing practice. Refine an architecture development methodology for continued use. (Core Team) Establish governance structure to manage architecture as an ongoing process. (Core Team)
  • For the DAS and ODOT Integrated System ERP Program, the focus is on applying an off the shelf product that will provide integrated data across a Core ERP for Finance, HRIS, and Procurement, while ensuring one Authoritative Data Source. The program recognizes there will be Enterprise Application Interfaces to other legacy applications and databases.
  • As of today, the ERP Proposed Scope and Release Strategy has three initial release plans. Release 1 has CORE Financials……….. Release 2 and 3 deal with a whole host of functions……… Future Releases have………. DAS to Provide several HR functions and ODOT is to pilot them.
  • So how is Enterprise Architecture defined? From Garter we have….The process of translating business vision and strategy into effective enterprise change by creating, communicating and improving key requirements, principles and models that describe the enterprise’s future state and enable its evolution. From Wikipedia we have……The practice of documenting the elements of business strategy, business case, business model and supporting technologies, policies and infrastructures that make up an enterprise.
  • But we know Enterprise Architecture supports Agency Requirements Gathering . The ongoing work of some agencies today involves Integrated Data and Information form AS-IS through TO-BE States. In fact, some of our agencies are already doing individual EA work. We would like to retrieve the fruit of their work and translate three segments of their work into a larger State of Oregon Enterprise Architecture. Those segments include the central services functions of Finance, Human Resources and Procurement. These are the same segments that can help inform the ERP Program to ensure we get the requirements right!
  • And so What is the Compelling Business need for Enterprise Architecture? The basis is in adding value to the Business on one end and Adding Value to the supporting IT Organizations on the other end. For Business, it… Facilitates business transformation throughout the enterprise. Formalizes and captures knowledge about the business that helps identify new opportunities and clarify existing gaps . Provides a set of guidelines, standards, and blueprints that can be used to acquire, build and deploy business solutions . For Technology, it Makes new initiatives easier to manage because they are designed and implemented according to architecture guidelines . Delivers a more manageable, agile IT environment . Aligns IT initiatives to business imperatives so that business benefits justify the costs. Allows IT to stay ahead of the curve with respect to the underlying technologies and infrastructure to support business applications .
  • Enterprise Architecture can expose core business functions of our agencies. Of our Agency Business Functions, all of our agencies have core business functions. We can call these Agency vertical functions. We also have Agency Horizontal Functions, which serve as central services functions across all our lines of business. Enter the Statewide Enterprise Services managed by DAS. These are the functions that will, over time, be replaced by the Enterprise Resource Planning (ERP) program. If we had Enterprise Architecture today for all the target agencies, then we could ensure that the requirements the agencies will surely want to give us could inform the ERP program.
  • Let’s examine this notion a little closer. – That Enterprise Architecture can inform ERP. We know that some of our agencies are already underway with Agency level enterprise architecture work. Although they might be using different EA methodologies, overall the intent of that work is to expose the Business Architecture, the Information /Data Architecture, the Application Architecture and the underlying Technology Architecture. The upper levels should inform the lower levels of this architecture stack, so we do not get into mis-starts. In any case, we want to take the fruit of their silo work and feed that to the State’s Enterprise Architecture team so they can translate it into an overall standard EA for the state. This serves to inform the Target Business Architecture, the Enterprise Information Architecture, the Enterprise Application Architecture and the Enterprise Technology Architecture.
  • For example: We could take the fruit of the Forestry Department EA work and inform the State’s Enterprise Architecture, especially around the business architecture of Financial Processing.
  • So what might an Action Path look like for Aligning EA and ERP? R esponsible - Those who do work to achieve the task. There can be multiple resources responsible. A ccountable - (Also Approver) The resource ultimately answerable for the correct and thorough completion of the task. There must be only one A specified for each task. C onsulted - Those whose opinions are sought. Two-way communication. I nformed - Those who are kept up-to-date on progress. One-way communication.
  • Enterprise Architecture Consulting Estimated Timeline for a 12-week engagement. A simple project duration typically runs up to 16 weeks and can be requested for any duration and volume of content is estimated separately.
  • Architecture activities occur at different levels within an agency, including at the enterprise level (enterprise architecture) and the segment level (segment architecture). Agencies can also develop individual solution architectures for IT systems supporting a segment. Architecture at one level is used to guide and inform architecture activities at levels below it (e.g., segment architecture to solution architecture) and is reconciled to the architecture at the level above it (e.g., segment architecture to enterprise architecture). Architectural levels differ in their scope, level of detail, impact, and intended audience. For example, an agency’s enterprise architecture is designed to provide an architectural view of the entire agency. However, a segment architecture is focused on an individual line of business and provides more detail for the line of business than the agency’s enterprise architecture. In order to be successful, agencies need a partner and effective stakeholder buy-in. In some cases, it can be helpful to solicit assistance from outside organizations to get attention and senior level buy-in, such as Agency Directors, Administrative Business Services Directors, CIO’s and other stakeholders.
  • Transcript

    • 1. Aligning Enterprise Architecture and ERP presented by Ben Berry, ODOT Chief Information Officer [email_address] August 19, 2008 CIO Council
    • 2. Current State of Enterprise Programs
      • DAS & ODOT agree to Enterprise Resource Planning (ERP)
      • DAS/ODOT create ERP Interagency Agreement.
      • 09-11 Program Option Package (POP) created.
      • RFP let for pre-implementation services to the Integrated System ERP.
      • Joint DAS/ODOT Steering Committee and Charter established.
      • Oregon Enterprise Architecture (EA)
      • 09-11 DAS POP requests creation of EA & Standards Program .
      • Agency Directors in 2004 and 2006 documented need for effective, enterprise-level planning and IT-alignment.
      • 2007-11 EIRMS endorsed by CIOC and Admin Business Directors calls for Enterprise business, technical architecture & standards.
      • If approved by Legislature, EA and Standards Program would begin July 2009.
    • 3. Enterprise Architecture and ERP Alignment is Elusive
      • Sustainable Business Architecture for Decisions
      • Alignment of EA to business needs.
      • A Repeatable EA framework
      • Architecture is visible across state agencies
      • Define AS-IS & TO-BE
      • functions for
      • - Human Resources
      • - Finance
      • - Procurement
      ERP Enterprise Resource Planning EA Enterprise Architecture
    • 4. Enterprise Architecture should Inform ERP ERP Enterprise Resource Planning EA Enterprise Architecture
    • 5. Developing the Right Perspective is Critical!
      • Shared Interest
      • Enterprise perspective
      • • Migration path to move toward target architectures
      • Consistent EA methodology statewide
      • Targeted Interest
      • Informed by EA
      • Rich Reqts
      • Stake Holders
      • Implement Bulletproof
      • Opportunities and Stewardship for:
      • Improved performance
      • Introduction of new capabilities
      • Expanded responsibilities
      • Reduced costs
      • Leverage new technology
      ERP Enterprise Resource Planning EA Enterprise Architecture
    • 6. DAS & ODOT Integrated System ERP Program Finance HRIS Procurement Core ERP Enterprise Application Interfaces Integrated System Authoritative Data Source Legacy Application Legacy Application Legacy Application
    • 7. ERP Proposed Scope and Release Strategy as of August 2008 DAS to Provide; ODOT to Pilot
    • 8. Enterprise Architecture Definition
      • The process of translating business vision and strategy into effective enterprise change by creating, communicating and improving key requirements, principles and models that describe the enterprise’s future state and enable its evolution. (Gartner)
      • The practice of documenting the elements of business strategy, business case, business model and supporting technologies, policies and infrastructures that make up an enterprise. (Wikipedia)
    • 9. EA Supports Agency Requirements Gathering Others Integrated Data and Information from As-Is through “To Be State” Forestry DCBS DAS DHS ODOT Using the FEA-DRM Procurement Management Other Central Services Functions… Finance Chart of Accounts Procurement Human Resources Personnel Management
    • 10. What is the compelling business need for Enterprise Architecture?
      • Business: Value to the Business
        • Facilitates business transformation throughout the enterprise.
        • Formalizes and captures knowledge about the business that helps identify new opportunities and clarify existing gaps .
        • Provides a set of guidelines, standards, and blueprints that can be used to acquire, build and deploy business solutions .
      A properly designed and implemented enterprise architecture helps the enterprise implement processes and technology in harmony to achieve the business objectives.
      • Technology: Value to the IT Organization
        • Makes new initiatives easier to manage because they are designed and implemented according to architecture guidelines .
        • Delivers a more manageable, agile IT environment .
        • Aligns IT initiatives to business imperatives so that business benefits justify the costs.
        • Allows IT to stay ahead of the curve with respect to the underlying technologies and infrastructure to support business applications .
    • 11. EA can Expose Core Business Functions Statewide Enterprise Services Agency Business Services Payroll / Budget Recruit / Hire Purchasing Agency Horizontal Central Functions Agency Vertical Core Functions Human Resources Financial Management Procurement Forestry Employment Others Revenue DAS DHS ODOT
    • 12. Enterprise Architecture can inform ERP Infrastructure Business Technology Application Information (Data) ODOT DAS ERP EA Procurement Financials Human Res Target Business Architecture Enterprise Information Architecture Enterprise Application Architecture Enterprise Technology Architecture Forestry Lottery OED DCBS DHS
    • 13. For example: Incorporate Forestry Department EA into Statewide EA/ERP Forestry Business Improvement Initiative
    • 14. So, what might an Action Path look like for aligning EA/ERP? C C R 9. Establish governance structure to promote and manage architecture as an ongoing process. C C R 8. Refine an architecture development methodology for continued ongoing use. RA C C 7. Develop a target architecture that reflects the enterprise ’ s need to evolve its information resources. C RA C 6. Develop a migration plan to move towards the target Financial architecture. R AC/$ C C 5. Create Financial segment architecture for the enterprise. C RA C 4. Develop a migration plan to move towards the “ To - Be ” target HR architecture. R C AC/$ C 3. Create HR segment architecture for the enterprise. R C C AC/$ 2. Identify enterprise mission, vision, principles and environmental trends for enterprise administrative systems. AC AC R 1. Complete SOW and RFP to acquire contractor to develop “ As - Is ” EA for administrative functions and segment architectures for HR and Finance. Contractor Financial HRIS EA Activities C C R 9. Establish governance structure to promote and manage architecture as an ongoing process. C C R 8. Refine an architecture development methodology for continued ongoing use . RA C C 7. Develop a target architecture that reflects the enterprise ’ s need to evolve its information resources . C RA C 6. Develop a migration plan to move towards the target Financial architecture. R AC/$ C C 5. Create Financial segment architecture for the enterprise. C RA C 4. Develop a migration plan to move towards the “ To - Be ” target HR architecture. R C AC/$ C 3. Create HR segment architecture for the enterprise. R C C AC/$ 2. Identify enterprise mission, vision, principles and environmental trends for enterprise administrative Systems (Finance, HR and Procurement). AC AC R 1. Complete SOW and RFP to acquire contractor to develop “ As - Is ” EA for administrative functions and segment architectures for HR and Finance. Contractor Support Finance Team HRIS Team EA Team Activities I Governing Body I
    • 15.  
    • 16. Enterprise Architecture Consulting Project Approach and Milestones Review contract  Identify ARB members  Identify key stakeholders  Schedule interviews  Schedule Workshops  Team orientation  Other logistics  locations  space  communications  Intranet Access  Strategic documents  Business models  User groups  Pilots  Sourcing position  Baseline assessment Architecture Review Board  Kickoff (half day)  EA Principles ---------------  EA Visioning  EA Roles/Responsibilities  EA Metrics ---------------  EA Processes  EA Tools ---------------  EA Transition Plan ---------------  Conceptual Model  Access, Security  Applications  Data  Common Services Application Development, Cross - Function Applications  Systems Mgt Network, Platforms, Peripherals  Autonomic/Grid/UMI  EA Processes  Evaluation Criteria  Arch Review Board  Technical Steering Committee  EA in a Box  Complete Documentation  Initiatives  B&P Wk 3 - 5 Wk 6 - 9 Wk 9 - 12 Wk 2 - 12 Wk 1 Wk 1 - 3 Wk 2 - 12 Planning Status and Requirements Architecture Principles Architecture Modeling Architecture Management Management Action Plan Planning Sessions Gather and Summarize Inputs Document Key Requirements Principles Definition Workshops Develop Conceptual Model Gap Analysis Workshops Develop Evaluation Criteria Define Architecture Management Processes Develop Transition Plan Final Presentation  Set expectations  Review contract  Identify ARB members  Identify key stakeholders  Schedule interviews  Schedule Workshops  Team orientation  Other logistics  locations  space  communications  Intranet Access  Strategic documents  Business models  User groups  Pilots  Sourcing position  Baseline assessment Architecture Review Board  Kickoff (half day)  EA Principles ---------------  EA Visioning  EA Roles/Responsibilities  EA Metrics ---------------  EA Processes  EA Tools ---------------  EA Transition Plan ---------------  Conceptual Model  Access, Security  Applications  Data  Common Services Application Development, Cross - Function Applications  Systems Mgt Network, Platforms, Peripherals  Autonomic/Grid/UMI  EA Processes  Evaluation Criteria  Arch Review Board  Technical Steering Committee  EA in a Box  Complete Documentation  Initiatives  B&P Wk 3 - 5 Wk 6 - 9 Wk 9 - 12 Wk 2 - 12 Wk 1 Wk 1 - 3 Wk 2 - 12  Set expectations 
    • 17. Enterprise Architecture Consulting Estimated Timeline for a 12-week engagement. A simple project duration typically runs up to 16 weeks and can be requested for any duration and volume of content is estimated separately.
      • < An interim report will provide early feedback on the team's findings and recommendations.
      • < The final report will be presented at the end of the engagement.
    • 18. How EA/ERP creates value for the enterprise
      • Agency Directors
      • ABSD
      • CIOs
      • ERP Stakeholders
      • Segment Owners
      • Business Mgrs
    • 19. Remember, the 09-11 DAS POP already defines the work of the EA Core Team
      • Enterprise
        • Build architecture models for core statewide functions, e.g. HR, finance, & procurement.
        • Prepare for dedicated EA resources in 2009-11.
        • Promote EA concepts for and report to business community.
        • Establish a infrastructure for collaboration and sharing information across agency boundaries.
      • ERP Segment Architecture
        • Inform ERP program.
        • Support the ERP effort by creating reusable EA methods, templates, tools, etc.
        • Use segment architecture effort to jump-start cross-agency business understanding.
      • Agency Support
        • Inform and promote Enterprise Architecture and ERP architecture to agencies.
        • Develop methods, tools, and assistance for agency or segment architecture work.
        • Work to ensure that agency needs are recognized in both models.
        • Work with agencies to influence projects that contribute to enterprise architecture.
        • Assist agencies to promote project concepts.
      • Architect Community
        • Build architect’s community to share experiences, build skills, and reuse products.
        • Continue to build EA infrastructure, web accessible repository and support.
    • 20. Expected Outcomes: Top Down, Across and Bottom Up Enterprise Vision Agency Architectures Architects
      • Build target architecture models for core statewide functions, e.g. HR, finance, and procurement.
      • Promote EA concepts for business community.
      • Establish a infrastructure for collaboration and sharing information across agency boundaries.
      • Prepare for dedicated EA resources in 2009-11.
      • Reuse agency’s EA to ensure that their needs are recognized in a target statewide enterprise architecture model for core statewide functions.
      • Work with agencies to influence projects that contribute to enterprise architecture.
      • Assist agencies in promoting EA concepts.
      • Establish a community of architects to share experiences, build skills, and reuse architectural products.
    • 21. Contributors to this presentation
      • CIO Management Council
      • Ron Winterrowd
      • ERP Program Manager (ODOT)
      • Steve Schafer
      • HRIS Project Manager (DAS HR)
      • Tim Avilla
      • IS Process Improvement (ODOT)
      • Ed Arabas
      • EISPD Administrative Services
      • Scott Riordan
      • EISPD Administrative Services
    • 22. CIO Council ” Aligning Enterprise Architecture and ERP”

    ×