(Advanced)

426
-1

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
426
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
21
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • The US Department of the Interior manages Federal lands, some Federal natural resources, all Federal mineral and oil resources, historical cultural assets, fish and wildlife on some Federal lands, and the welfare of all native American tribes. The DOI has 700 officially recognized major IT systems, but if unofficial and undocumented systems are included that number increases to at least 5,000 systems.
  • The method used for the DOI modernization effort was described earlier by Peter De Meo.
  • To be successful, an enterprise architecture engagement must have measurable end goals. An enterprise architecture engagement must be limited in scope.
  • The DOI enterprise architecture engagement has technology, process, application and data modernization goals. Initially cost savings are realized from technology and software transformation savings. Data and process savings take longer to realize.
  • DOI developed a custom tailored enterprise architecture modeling tool for the US Department of the Interior. This an actual screen shot of the tool.
  • Within the DOI each domain (security, IT investments, IT portfolios, data, software development, configuration management) had multiple, isolated repositories
  • DOI integrated these isolated repositories into a single integrated repository.
  • Today, D.E.A.R. is the source of record for architecture artifacts across the DOI and its Bureaus. This provides the CIO with a single view of the enterprise.
  • US law mandates that US departments have performance metrics. Each department (ministry) is measured in their ability to achieve these metrics each year and this is reported to the US congress.
  • Within the modeling tool, we can see what IT investments support a given end outcome goal. We can see how much the DOI spends to achieve and end outcome goal.
  • We can perform queries against the repository and view the results as formatted HTML This report shows multiple IT investments supporting various DOI strategic goals.
  • The SRM Service Components are model objects that can be used in the modeling tool. They can be related to the BRM and to systems.
  • The Federal OMB DRM is not a data model – it is a framework of high-level data categories.
  • (Advanced)

    1. 1. DOI Enterprise Architecture Using Enterprise Architecture to create Modernization Blueprints at the Department of the Interior
    2. 2. U.S. Department of the Interior <ul><li>The Department manages more than 440 million areas of federal lands, including some 360 national parks. This includes fostering the wisest use of our land and water resources, protecting our fish and wildlife, providing recreation, and preserving the environmental and cultural values of our national parts and historic places. </li></ul><ul><li>The Interior Department also assesses mineral resources and works to assure that their development is in the best interest of all the people. </li></ul><ul><li>Additionally, the Department has a major responsibility for American Indian reservation communities and for people who live in the Island Territories under United States administration. </li></ul><ul><li>The Interior Department manages an annual I/T budget of approximately $1B USD with over 900 major I/T systems across 8 Bureaus and multiple Offices </li></ul>
    3. 3. Modernization Blueprint Approach
    4. 4. Goals of DOI Modernization Blueprint Approach <ul><li>Develop a sequencing plan that describes a value-based incremental strategy for transitioning the baseline to the target architecture </li></ul><ul><li>Ensure alignment between application systems and customer mission and goals. </li></ul><ul><li>Reduce or eliminate functional redundancies across systems. </li></ul><ul><li>Foster the “Write-Once Use-Many” principle of data management through integrated data stores. </li></ul><ul><li>Obtain/retain adequate funding for customer’s application systems. </li></ul><ul><li>Reduce O&M costs associated with existing and planned systems. </li></ul><ul><li>Leverage, where possible, existing and planned infrastructure components. </li></ul><ul><li>Re-use, where possible, existing and planned technology components. </li></ul>
    5. 5. The DOI enterprise architecture engagement has technology, process, application and data modernization goals. Initially cost savings are realized from technology and software transformation savings Process Architecture Application Architecture Technology Architecture Same Process Same Format Application Optimization Local Consolidation Merged Processes Merged Data Enterprise Integrated Data Store Portfolio Optimization Enterprise Optimization Regional Consolidation Centralized Consolidation Standard Processes Year 1 Year 2 Year 5 Data Architecture Cost Savings $ $$$ $$ Time
    6. 6. DOI developed a tailored enterprise architecture modeling tool. (Screenshot) DOI Enterprise Architecture Repository
    7. 7. Within the DOI each domain (security, IT investments, IT portfolios, data, software development, configuration management) had multiple, isolated repositories
    8. 8. DOI integrated these isolated repositories into a single integrated repository - D.E.A.R.
    9. 9. Today, D.E.A.R. is the source of record for architecture artifacts across the DOI and its Bureaus. This provides the CIO with a single view of the enterprise.
    10. 10. A Four Step Take Action Approach was developed to set the vision, develop an inventory, analyze, and take-action via a modernization blueprint of the Target Application Architecture (TAA) Step 3 Step 4 TAA Step 1 Step 2
    11. 11. Step 1: The capturing of DOI Business Strategy involved modeling the DOI Strategic Plan and interviews with DOI business and technology leaders
    12. 12. The DOI Strategic Plan’s logical structure lent itself to being modeling within the DEAR modeling tool US law mandates that US departments have performance metrics. Each department (ministry) is measured in their ability to achieve these metrics each year and this is reported to the US congress.
    13. 13. Within DEAR, Strategic Plan elements have been mapped to ABC Work Activities and have been classified within the context of OMB PRM Measurement Categories Strategic Plan Mapped to ABC Elements Strategic Plan Mapped to End Outcomes Within the modeling tool, we can see what IT investments support a given end outcome goal. We can see how much the DOI spends to achieve and end outcome goal.
    14. 14. Modeling the Strategic Plan in DEAR allows DOI to perform queries such as “what I/T investment support a given End Outcome Goal?” We can perform queries against the repository and view the results as formatted HTML This report shows multiple IT investments supporting various DOI strategic goals.
    15. 15. Step 2: Capturing the DOI Baseline Architecture involved data collection templates and validation workshops for each line of business
    16. 16. Examination of the As Is (Current) Environment <ul><li>Each system developed to support a single line of business </li></ul><ul><li>Systems created to support historical goals / process – not necessarily valid today </li></ul><ul><li>Systems have stove-piped infrastructures with no component sharing </li></ul><ul><li>Technology often outdated with escalating operations and maintenance costs </li></ul><ul><li>Systems developed using proprietary or local standards – low reusability </li></ul><ul><li>Information exchange among systems is ad hoc or manual </li></ul>
    17. 17. The Business Reference Model as implemented by the DOI extended the FEA BRM down to the level of function / activities and process steps <ul><li>Original FEA BRM was extended two additional levels </li></ul><ul><li>DOI systems were mapped at lower levels of the DOI BRM to perform more detailed Analysis. </li></ul><ul><li>Lower-level function / activities were decomposed further into IDEF0 and IDEF3 process models </li></ul><ul><li>Process models were used to examine existing work processes and then used optimize work flow for to be (target) systems </li></ul>
    18. 18. BRM Reports Generated from DEAR
    19. 19. SRM – Complete OMB FEA SRM Modeled in DEAR
    20. 20. DRM as implemented in DEAR Conceptual Data Model for Law Enforcement LoB in DEAR Data Subject Areas for Law Enforcement LoB in DEAR
    21. 21. DOI System – to – System Interfaces Modeled in DEAR (CBS System Shown)
    22. 22. HTML Report of Systems and their relationship to all FEA Reference Model domains
    23. 23. Ad Hoc Matrix Report showing Systems related by Data Subject Areas (DRM)
    24. 24. OMB TRM Framework Modeled in DEAR
    25. 25. OMB TRM Framework Modeled in DEAR (details on a single TRM Standard shown)
    26. 26. TRM Reports Generated from DEAR
    27. 27. Step 3: DOI Gap Analysis resulted in the classification of existing systems and the identification of horizontal services
    28. 28. DOI Gap Analysis assessed alignment of baseline architecture with FEA and DOI architecture standards System Assessment Process Data Technology Application Architecture Classification <ul><li>Business processes supported by the system </li></ul><ul><li>System support of DOI and BLM strategies, goals, and objectives </li></ul><ul><li>Stakeholders feedback on performance </li></ul><ul><li>Functional overlap with other systems </li></ul><ul><li>System training and support opportunities addressed. </li></ul>PRM / BRM DRM SRM / CBA TRM <ul><li>Existence and documentation of data standards and protocols </li></ul><ul><li>Data storage / access method maturity </li></ul><ul><li>Data entity access / modification overlap with other systems. </li></ul><ul><li>Target Application Architecture compliance </li></ul><ul><li>Extent system design requirements are defined and documented. </li></ul><ul><li>Extent systems interfaces are defined and documented. </li></ul><ul><li>Extent to which high-level design or operational concepts are defined. </li></ul><ul><li>Compliance with TRM technology architecture components </li></ul><ul><li>Extent of use of shared, existing infrastructure components and services </li></ul><ul><li>Extent of compliance with TRM standards, protocols and best practices. </li></ul><ul><li>Legacy </li></ul><ul><li>Data Migration (re-engineer) </li></ul><ul><li>Consolidate (re-engineer) </li></ul><ul><li>Target </li></ul>
    29. 29. DOI Gap Analysis explored and defined tactical (short term) Improvements for existing systems <ul><li>Conduct baseline Analysis </li></ul><ul><li>Set improvement targets </li></ul><ul><li>Identify, select, and propose improvements </li></ul><ul><li>Maximize investment across entire portfolio </li></ul>
    30. 30. DOI Gap Analysis classified existing systems based on weighted results of Analysis
    31. 31. Step 4: The results of the gap Analysis, industry best practices, and DOI patterns and reference architecture artifacts drove the creation of the DOI conceptual target architecture
    32. 32. Definition of the Conceptual To Be (Target) Environment <ul><li>Systems are a collection of service components supporting multiple business lines </li></ul><ul><li>Systems support current mission / goals and can adapt rapidly to change </li></ul><ul><li>Technology based on service orientated architecture (SOA) </li></ul><ul><li>Reusable components are deployed in a scaleable distributed infrastructure </li></ul><ul><li>Systems developed using open enterprise standards </li></ul><ul><li>Data standards and standard information exchange mechanisms support information sharing among systems </li></ul>
    33. 33. The DOI conceptual target application architecture is a service oriented architecture designed to meet future business requirements
    34. 34. The DOI conceptual target application architecture is aligned with the FEA E-Government Interoperability Model <ul><li>End-user access (across the top – section A). </li></ul><ul><li>Applications (in the center – section B). </li></ul><ul><li>Application Integration and Common Services (the vertical bar on the right – section C). </li></ul><ul><li>External Applications and Portals (the boxes on the right – section D). </li></ul><ul><li>Cross-cutting Architectural Requirements (the layers upon which the application are built – section E). </li></ul>
    35. 35. Migration planning resulted in both a tactical and strategic implementation plan
    36. 36. Tactical recommendations included short-term improvements in alignment with strategic architecture goals within constraints of existing O&M budgets.
    37. 37. Tactical recommendations were prioritized to yield maximum benefits across the portfolio within budget constraints
    38. 38. The strategic implementation plan provided a conceptual roadmap to the target architecture <ul><li>Enables progress towards target application architecture </li></ul><ul><li>Provides conceptual roadmap to target architecture </li></ul><ul><li>Identifies systems to be retired, consolidated, and re-engineered </li></ul><ul><li>Informs project, program, and portfolio management </li></ul><ul><li>Identifies investment proposals to be worked now to enable the future state </li></ul>
    39. 39. DOI Schedule – Where are we today? Common Collection Technique IT Assets DEAR Reporting DOI Level Portfolio 5 LOB Functions System Inventories and lists OMB Reference Models DOI TRM DRM ITIPS Strategic Plan ABCs DEAR TAA I n g e s t A c c e s s Repository Associated and Normalized Artifacts Department-wide Interpretable Information Actionable Recommendations and Plans Apply Standards and Conventions Modernization Blueprints Agency Raw Data TRM/SRM PRM BRM System Inventory Security C&A technical info and status April, 2004
    40. 40. Some lessons learned … <ul><li>Importance of collaboration / concurrence more difficult than technical issues– organizational / process / culture / view of change </li></ul><ul><li>Common vision, FEA reference models, documented processes, documented work products provide a “common language” among diverse team members </li></ul><ul><li>Importance of program management skills for engagement lead – Enterprise Architect must be diplomatic yet lead </li></ul><ul><li>Short term successes and deliverables are important to provide feedback and direction to the team </li></ul><ul><li>Well-documented deliverable descriptions, well-documented schedule important to manage customer expectations </li></ul><ul><li>Each EA engagement must be tailored to customer-specific requirements </li></ul><ul><li>Common modeling tool / repository assisted with enforcing common modeling methods and ensuring compatibility of model artifacts across different teams. </li></ul>
    41. 41. Document Abstract Revision History Take_Action_DOI_EA.ppt Revisions for Publishing on DOI Site Mtricomi 05/07/04 Ready to Present POV Presentation - Making EA Real V6.ppt Original content FCollins 04/16/04 WIP Filename/lineage Description of edit Author/Editor Rev. Date Doc Status Key Words: DOI, System, Architecture, DEAR, Modernization Blueprint DOI Summary of Modernization Blueprint approach Contract #: XXXXXXXX Task Number: 5 A 1230 FEAF Area: All Subject Function Code:
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×