Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

(Advanced)

584 views

Published on

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

  • Be the first to like this

(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:

×