Enterprise Architecture Information Policy Council

563 views

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
563
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Enterprise Architecture Information Policy Council

  1. 2. Enterprise Architecture Information Policy Council Apr 19, 2001
  2. 3. Why Enterprise Architecture? <ul><li>Electronic government is fundamentally changing the way citizens interact with the government, both as consumers of government services and stakeholders in the affairs of state </li></ul>
  3. 4. Design Goals <ul><li>Facilitate change </li></ul><ul><ul><li>The primary design goal for information systems must be to enable rapid change in business processes and the applications and technical infrastructure that enable them. </li></ul></ul><ul><li>Provide better interoperability of agency systems </li></ul><ul><li>Deploy advanced electronic government services </li></ul>
  4. 5. Enterprise Technical Architecture <ul><li>A logically consistent set of principles, standards, and models that: </li></ul><ul><ul><li>Are derived from business requirements </li></ul></ul><ul><ul><li>Guide the engineering of an organization’s information systems and technical infrastructure across various domains </li></ul></ul>
  5. 6. Components of Technical Architecture <ul><li>Conceptual Architecture - the top-level set of principles and standards that guide the domain architectures </li></ul><ul><li>Domain Architectures - Logical groupings of related technologies </li></ul><ul><ul><li>e.g. application, network, data, middleware, groupware, security, accessibility </li></ul></ul>
  6. 7. Business Drivers I <ul><li>Appropriate government information and services will be accessible regardless of location, time, method of access and group (e.g. language, culture, age and ability) </li></ul><ul><li>Access to information and services will be authenticated to the degree required by specific information and services. Information will be protected to the level required both internally and externally. </li></ul><ul><li>Provide coherent and navigable access across multiple points of interaction for government information and services (I.e., “no wrong door”) spanning departments and other levels of government. </li></ul>
  7. 8. Business Drivers II <ul><li>Government information and services will quickly respond to the client’s changing expectations </li></ul><ul><li>Government will reduce the total cost of ownership of IT investments though the elimination of duplicate infrastructures, support services, and leveraging economies of scale. </li></ul><ul><li>The government will increase attractiveness for business investment to build stronger local economies. </li></ul>
  8. 9. Minnesota Version <ul><li>Start with existing Architecture Advisory Group and Architecture Working Group </li></ul><ul><li>Use shortcut process to display tangible progress </li></ul><ul><li>Use an existing template to develop a draft with small team from the Working Group </li></ul><ul><li>Get go-ahead from Advisory Group </li></ul><ul><li>Develop the conceptual and domain architectures with parallel teams. </li></ul>
  9. 10. Document Structure
  10. 11. Domain Structure <ul><li>Purpose </li></ul><ul><li>Scope </li></ul><ul><li>Principles </li></ul><ul><li>Best Practices </li></ul><ul><li>Implementation Guidelines </li></ul><ul><li>Standards </li></ul>
  11. 12. Cover Design ENTERPRISE ARCHITECTURE FOR DUMMIES CIO EDITION A Reference for The Rest of Us! 21 Hundred Sold
  12. 13. Other Considerations <ul><li>Operational focus of agency IT efforts </li></ul><ul><li>Impact on smaller agencies </li></ul><ul><li>Existing efforts, e.g.: </li></ul><ul><ul><li>Common security infrastructure (PKI) </li></ul></ul><ul><ul><li>Northstar portal upgrades </li></ul></ul><ul><ul><li>Electronic Government Services collaborative </li></ul></ul><ul><ul><li>Recordkeeping Metadata study </li></ul></ul>
  13. 14. Adoption and Implementation <ul><li>Willingness of agencies to adhere to the architecture in future development: </li></ul><ul><ul><li>Compelling perceived advantage </li></ul></ul><ul><ul><li>Substantial natural consequence </li></ul></ul><ul><ul><li>OT leadership </li></ul></ul><ul><ul><li>IPC sponsorship </li></ul></ul>
  14. 15. Schedule <ul><li>Drafting Committee - mid March </li></ul><ul><li>Working Group approval - Mid April </li></ul><ul><li>Advisory Group approval - late May </li></ul><ul><li>Domain architecture definitions - June-September </li></ul><ul><li>Architectural Reference, version 1 - October </li></ul>
  15. 16. Finis Per altro informazione [email_address] 651-297-5568
  16. 17. Attributes of State Government <ul><li>Lack of longevity and continuity in leadership </li></ul><ul><li>Lack of incentives to search for intra-agency or inter-agency savings </li></ul><ul><li>Historical lack of central leadership in statewide IT efforts </li></ul><ul><li>Perceived lack of understanding and support in the legislature for adequate resources </li></ul><ul><li>Concern about the ability to share data in an environment of much tighter privacy restrictions </li></ul>
  17. 18. Technical Architecture Process K e y E n t e r p r i s e D r i v e r s W h a t , W h o , W h e n , W h e r e C o m m o n R e q u i r e m e n t s V i s i o n D o m a i n A r c h i t e c t u r e W h a t , n o t H o w S e t o f P r i n c i p l e s E n v i r o n m e n t a l T r e n d s E n t e r p r i s e B u s i n e s s S t r a t e g i e s B u s i n e s s I n f o r m a t i o n R e q u i r e m e n t s R e q u i r e m e n t s f o r T e c h n i c a l A r c h i t e c t u r e C o n c e p t u a l A r c h i t e c t u r e C o n c e p t u a l A r c h i t e c t u r e A s - I s A s s e s s o f B e s t P r a c t i c e s I d e n t i f y D o m a i n s D o m a i n P r i n c i p l e s I d e n t i f y T e c h n o l o g i e s A s - I s A s s e s s m e n t T e c h n o l o g i e s I d e n t i f y S t d s , P r o d u c t s & C o n f i g s Best Practices
  18. 19. Enterprise Architecture Process
  19. 20. Silo Processes & Applications <ul><li>Applications optimized at program/department level </li></ul><ul><li>Theme: Empower the program director </li></ul><ul><li>IT optimized around each program area </li></ul>
  20. 21. What does it all mean? <ul><li>Power corrupts; </li></ul><ul><li>All of the books in the world contain no more information than is broadcast as video in a single large American city in a single year. Not all bits have equal value. — Carl Sagan </li></ul>absolute power is sorta neat, though. — Anonymous <ul><li>Data can be assembled into information . </li></ul><ul><li>Information is the currency of democracy. — Thomas Jefferson </li></ul><ul><li>Information can be used to create knowledge. </li></ul><ul><li>For knowledge, too, is itself power. — Francis Bacon There is no knowledge that is not power. — Ralph Waldo Emerson </li></ul><ul><li>All power to the people. — Eldridge Cleaver </li></ul>
  21. 22. Trends <ul><li>Ubiquitous bandwidth </li></ul><ul><li>Intelligent devices </li></ul><ul><li>Information dependency </li></ul><ul><li>Digital economy with the Internet </li></ul><ul><li>Cost curves - technology down, talent up </li></ul><ul><li>Demand for rapid new and innovative services and access to them </li></ul>
  22. 23. Ad Hoc Integration
  23. 24. Question of the day: <ul><li>Is the entire State government an Enterprise ? </li></ul>
  24. 25. Enterprise Architecture Process

×