1. Enterprise Architecture Planning (EAP) Administrative Computing Services 12/17/2002

2. Dec 17, 20022 Topics What is Enterprise Architecture Planning (EAP)? What is an EA used for? Why should we do it?

3. Dec 17, 20023 A comprehensive blueprint of an organization by which we analyze and plan changes and make additions. The structure of (Enterprise) components and their relationships, as well as principles and guidelines governing their evolution over time. A common understanding, of the names and definitions of our organization’s entities. MOST IMPORTANTLY: THE MODELS... We need to build a new application… What do we have already in place? Impact? What is an Enterprise Architecture?

4. Dec 17, 20024 The EA is a strategic asset repository which defines the current and target architecture environments, including: the business (processes), the information (data or entities), the technology, and the transitional processes that keeps all aligned. Emphasis on Logical, not Technological… Technology will always change Beware of Protocol Gas! What is an Enterprise Architecture? Source: Federal Conceptual Architecture model

5. Dec 17, 20025 Example: Technical Blueprint

6. Dec 17, 20026 Example: Organizational Data/Entities

7. Dec 17, 20027 Example: Organizational Data Attributes

8. Dec 17, 20028 EAP Consists of... A standard methodology A standard framework A standard set of templates A repository A change management process

9. Dec 17, 20029 Methodology adopted: “Guiding Principles” Conceptual Guiding Principles for all Architecture Domains Specific Domain Architecture Guiding Principles Commercial-Off-The-Shelf Solutions Developed Applications Middleware Network Platforms Security Databases Operations Management

10. Dec 17, 200210 Adopted “Sliding Window” Technology Change Management Methodology Matrix for a 4-year, 16-quarter sliding window within which the various recommendations for the Specific Domain Architectures are documented. Document which components should be researched, piloted, invested in, maintained but not upgraded, disinvested, obsoleted, and rejected. Planning Architecture Governance and Change Management Procedures

11. Dec 17, 200211 Adopted Baseline Reference Technology J2EE XML LDAP Directory Business Portal (uPortal) as application development and integration framework

12. Dec 17, 200212 Adopted Zachman’s Framework for Information Systems Architecture

13. Dec 17, 200213 Topics What is Enterprise Architecture Planning (EAP)? What is an EA used for? Why should we do it?

14. Dec 17, 200214 Investment decisions, vendor selection Modeling Analysis Requirements definition Planning Describing, understanding, and communicating What is an EA used for?

15. Dec 17, 200215 What is an EA used for? Promote interoperable and cost-effective systems Provide the rules, guidance and governance for buying or developing systems and managing change Ensure a common denominator for understanding, describing, comparing, and integrating systems Provide a mechanism for managing complexity.

16. Dec 17, 200216 Architecture Defines the Transitional Roadmap Source: Federal Conceptual Architecture model

17. Dec 17, 200217 Topics What is Enterprise Architecture Planning (EAP)? What is an EA used for? Why should we do it? Too much work! Too difficult! Too many deadlines!

18. Dec 17, 200218 Non-optimum HRIS Situation DATA Applicant Tracking DATA Staffing Management (Job Description Builder, QuickRec, FastClass) Employee Evaluation DATA Training Mgmt. DATA Payroll DATA Budgeting DATA

19. Dec 17, 200219 Competency Modeling Staffing Management (Job Description Builder, QuickRec, FastClass) Optimum Situation Employee Evaluation Training Mgmt. Payroll Applicant Tracking Budgeting DATA Integrated Systems and Data

20. Dec 17, 200220 Non-optimum Payquest Billing Agency Info AdCom Payquest Billing Agency Info Gastroenterolog y Pediatrics Billing Agency Info

21. Dec 17, 200221 Competency Modeling Gastroenterology Optimum Payquest Situation Training Mgmt. Pediatrics AdCom Payquest Any department Billing Agency Info in LDAP Directory Integrated Data and Access Control Eudora Any LDAP compliant software (DralaWorkflow, uPortal, Expresso)

22. Dec 17, 200222 Present “Stovepipes” Source: Federal Conceptual Architecture model

23. Dec 17, 200223 Desired State Source: Federal Conceptual Architecture model

24. Dec 17, 200224 Target Source: Federal Conceptual Architecture model

25. Dec 17, 200225 How do we get to the Target? Understand our challenges, goals and “Guiding Principles”. Apply and maintain “16-quarter Sliding Window” technology management Matrix for Domain Architectures (Security, COTS, etc). Build in Reference Technology (J2EE, XML, LDAP, Portal) Populate Zachman Framework Row 1 - the Planner’s perspective. Work with our business units to populate Zachman Framework Row 2 - the “Stakeholder’s” perspective (business models). Understand where we take “shortcuts”, why, and for how long. Plan, organize and commit. Communicate.

26. Dec 17, 200226 Applications in different technologies Redundant code, redundant data with multiple uses Redundant security, user/group management 30 year old systems Alignment with business needs not timely Data quality issues Costly integration Customized development of application instead of assembly from “parts” Funding (State Budgets depend on explicit EAP ) Projects done without architecture planning cost significantly more in long term (John Zachman) Without it, we can’t understand impact of change. Why? Too much work! Impossible!

27. Dec 17, 200227 Benefits to the Business of planned systems More responsive to customer’s needs Reduced data-entry costs Efficient systems maintenance means improved service. Architectures eliminate complex costly interfaces between incongruent systems Management decisions in all functional areas will be based on more accurate and timely data, leading to various improvements and cost-saving measures New systems are developed faster and at less cost due to common data, common code, and a shortened requirements phase Easier to evaluate and select vendor SW packages Source:Enterprise Architecture Planning Steven Spewak

28. Dec 17, 200228 Conclusion What is Enterprise Architecture Planning? What is an EA used for? Why should we do it? MOST IMPORTANTLY: THE MODELS... We need to build a new application… What do we have already in place? Impact?

29. Dec 17, 200229 "You may think this is too much work… Or, it takes too long And it costs too much Or is too theoretical Or too high risk Or too whatever. However, if that’s your assessment… You can’t complain that the systems aren’t “aligned” with the enterprise,or are inflexible, or cost too much, or that vital information is not available, or that the data you get isn’t any good, or too late, or you can’t change anything, or that I/S is slow and unresponsive… and, I am here to tell you Outsourcing isn’t going to fix the problem. Packages (in themselves) won’t fix the problem. Decentralization won’t fix the problem. And, the Internet isn’t going to fix the problem. No amount of money, Or technology is going to fix the problem! It is NOT a technical problem, it is an ENTERPRISE problem. Only ACTUAL WORK is going to fix the problem, and “Someday, you are going to wish you had all those models, Enterprise wide, horizontally and vertically integrated, at excruciating level of detail.” You might as well start working on them TODAY!!! John Zachman Zachman reflections on EA Planning

30. Dec 17, 200230 Benefits Facilitates information services that provide: flexibility interoperability reliability survivability affordability sustainability portability reusability adaptability compatibility

31. Dec 17, 200231 Business Benefits of EAP Focus on strategic use of technology for managing data as an asset Standard vocabulary facilitates communication and reduces inconsistency and data redundancy Documentation increases understanding of the business Models can be used to explain the business and assess the impact of business changes Decision making policies can be reviewed It allows for a comprehensive, objective and impartial approach The long range systems plan compliments the business plan It involves a feasible migration strategy with short term achievements It is easier to assess the benefits and impact of new systems and software It allows easier accommodation of dynamic business changes Management participation provides a business prospective, credibility, confidence Source:Enterprise Architecture Planning Steven Spewak

32. Dec 17, 200232 Examples - Entities Source: U.S. Coast Guard Information Architecture A distinguishable - person - about which information is kept. place, thing, event, concept

33. Dec 17, 200233 Work involved... Refine goals, objective, principles Establish membership Identify a methodology Identify a framework Identify resources Define deliverables Refine timeline

34. Dec 17, 200234 Technical Reference Model - A common framework, probably conceptual, to define a common vocabulary so as to better develop and aquire some level of support. It would provide you with a representation of the domain showing commonality and integration and interoperability. Common Operating Environment - The set of capabilities that would allow you to address the suite of integration products that you need to ensure a cohesive framework of systems for development. Like the DII COE address architecture, standards, software reuse, shared data, interoperability, portability, configuration management and integration. Standards Roadmap - It would start with a common set of mandatory standards and guidelines. It would then be tailored to the development that was being implemented. So it would be the "building codes" that would be reviewed and selected to facilitate the development of the system or systems needed to be built. (A Technical Architecture View for a particular area (Defense Transportation System) starting from the DOD Joint Technical Architecture.) Dick Webb, ASD(C3I) Definitions - Miscellaneous