Managing Complexity (through Enterprise Architecture)

1. Managing Complexity(through Enterprise Architecture) Kelly McDonald BYU June 23, 2005

2. Framework for building an EA • We have adopted TOGAF Enterprise Edition Version 8.1 as our guiding framework. • TOGAF – The Open Group Architectural Framework • http://www.opengroup.org/architecture/togaf

3. The Architectural Development Method – (ADM)

4. Why the Extra Work? • Make more strategic IT decisions. • Better connect IT decisions to University initiatives. • Create a trail of decisions that provides information for the Resource Planning debate on resource limitations. • Provide value statements for better supporting the funding requests to the Church.

5. Guiding Principles (Top 10) • Primacy of Guiding PrinciplesArchitectures are defined for the enterprise. Where possible, solutions conform to established architectures to reduce complexity and enable resource sharing. • Architectural Oversight Principle Solutions are designed with an architectural focus in an attempt to manage complexity. Architecture precedes engineering and architectural principles are the cornerstone in design decisions. • Customer Responsiveness PrincipleSolutions are customer driven and support the mission of BYU in order to provide maximum benefit to the University as a whole. • Security PrincipleSystems are designed to ensure a safe level of security and integrity of data. Data is protected from unauthorized use, disclosure, and modification. This includes, but is not limited to, protection of sensitive and proprietary information such as financial information, student records, and student grades. • Reliability PrincipleArchitectures support highly available, reliable and robust systems and disaster recovery/business continuity plans. Systems are assumed to require this architecture. • Interoperability PrincipleInteroperable, standards-based application and system interfaces, with widespread support, are preferred over proprietary ones. • Off-the-Shelf Principle“Off-the-shelf” solutions are preferred when they can be integrated into the overall architecture. We will develop custom solutions only when commercial applications don’t closely meet business needs or cannot be integrated easily. Business requirements include cost and effort limits. • Do-It-Right Principle“Doing it Right” is more important than keeping it inexpensive. Total Cost of Ownership and Excellence of the Solution should largely influence decisions. • Risk Acceptance Principle We will deploy technologies and services that are mature and proven in our vertical industry, unless newer technologies provide an answer needed to solve a major issue. We will resist deploying “bleeding edge” technologies. • Globalization PrincipleApplications are presumed to be globalized and accessible worldwide.

6. Enterprise Architecture Model Business Architecture System Architecture Information Architecture Technology Architecture

7. Business Architecture System Architecture Information Architecture Technology Architecture Business Architecture

8. Business Architecture SystemArchitecture Information Architecture Technology Architecture System Architecture

9. Business Architecture System Architecture Information Architecture Technology Architecture Information Architecture

10. Business Architecture System Architecture Information Architecture Technology Architecture Technology Architecture

11. Business Architecture Business Architecture Discover Environmental Trends and Conditions (ETC) that have or will impact BYU

12. Business Architecture Business Architecture Discover Environmental Trends and Conditions (ETC) that have or will impact BYU Determine what Business Goals and Strategies (BGS) we have that react to or get ahead of the ETC’s

13. Business Architecture Business Architecture Discover Environmental Trends and Conditions (ETC) that have or will impact BYU Determine what Business Goals and Strategies (BGS) we have that react to or get ahead of the ETC’s Formulate IT Objectives (ITO) that contribute to the BGS’s that have been determined

14. System Architecture SystemArchitecture Create Product Line Requirements (PLR) that Completely or partially Meet the ITO’s

15. SystemArchitecture System Architecture Create Product Line Requirements (PLR) that Completely or partially Meet the ITO’s Cost PLR’s and organize them into a document for Resource Planning. (PLRD) Determine level of funding.

16. SystemArchitecture System Architecture Create Product Line Requirements (PLR) that Completely or partially Meet the ITO’s Cost PLR’s and organize them into a document for Resource Planning. (PLRD) Determine level of funding. Initiate projects to design and implement systems that fulfill the approved PLR’s

22. Summary • Like any other modeling discipline, enterprise architecture helps control complexity by increasing understanding of the ‘big picture’. • An iterative process (to increasing level of detail), that keeps the architectural artifacts current and relevant. • Artifacts • Requirements (derived from IT Objectives) • Guiding Principles (for each level) • Reference Architectures (or models)

23. Example Artifactsfor ‘Architecture Vision’ • Requirements – ( Why The Extra Work) • Guiding Principles – (The Top 10) • Reference Architecture – (The four triangles)