Business Driven Enterprise Architecture Assessment Methodology

1. Business Driven Enterprise Architecture Assessment Methodology Josh Arceneaux August 16, 2011

2. Agenda • Introduction and Approach • Assessment Methodology • Maturity Model • Conclusions

3. Introduction • Enterprise Architecture is often thought of incorrectly as an “IT” activity • Typically the Enterprise Architecture function resides within the CIO organization which does nothing to dispel this thought (Clinger Cohen Act) • To derive real and tangible value, Enterprise Architecture needs to not only reside within the IT community but also be understood and practiced within the business community

4. Introduction • Objectives: • Create an Enterprise Architecture Assessment methodology to determine how IT services align with customer business needs • Create a methodology that will enable assessment of how to evolve to meet customer needs • Create an assessment methodology that is reusable • This presentation will discuss how we created two things to meet our objectives • An assessment methodology that ties Enterprise Architecture Assessments directly to key business needs • A maturity model that enables an objective assessment of how mature, and by therefore how valuable, an Enterprise Architecture capability is to the organization

5. Approach for Establishing a Comprehensive Methodology for Enterprise Architecture Assessments and Maturity Assessments

6. Assessment Methodology

7. Specific Goals • The Enterprise Architecture assessment methodology needed to answer the following: • Why is the assessment being performed? • By what means is the assessment being performed? • What resources and skills are required to perform an EA assessment? • What are the expected products the EA assessment will deliver and how will these products be utilized in the decision making process?

8. Our approach begins with an Enterprise Strategy and Design framework built up from integrating leading Enterprise Architecture Frameworks from across government and industry

9. What Does the Business/Customer Want to Know? This is typically the best starting point for most stakeholders • How is my organization going to be impacted and evolve to accommodate change across NASA and maximize our ability to thrive?

10. Tying Questions and Answers to Views (DoDAF 2.0 Views) This section is often best left to the EA performing the assessment to complete Stakeholders typically say yes to everything creating unrealistic goals and expectations

11. Refining the Assessment Details for building the Event Trace Description (OV6c) and the Conceptual Data Model (DIV1)

12. Refining the Assessment Details for building the Event Trace Description (OV6c) and the Conceptual Data Model (DIV1) The next step in the assessment planning is to identify the predecessor views needed Identifies additional views needed Identifies additional knowledge and skills needed

13. Working through the methodology worksheet you arrive at a model of what is needed to exercise use cases based on external change and evaluate the impacts to the organization business proceses Operational Resource Flow Description (OV2) Operational Resource Flow Matrix (OV3) Conceptual Data Model (DIV1) Overview and Summary Information (AV1) Operational Activity Model (OV5b) Event Trace Description (OV6c) Operational Activity Tree (OV5a) High Level Operational Concept (OV1) What is Happening When it Happens Why it Happens What information is being consumed What information is being produced Operational Rules Model (OV6a)

14. Knowledge and Skills Needed This will provide the Business/stakeholder with a high level model to assess various use cases against and determine how business operations will be impacted by change Is it complete; No, but it will enable decision makers to make educated decision about how to accommodate change and further expand the architecture to answer more detailed and technical questions

15. Build a Project Plan and Assign Schedule and Resources Balancing scope against resources is critical to meeting expectations while delivering an actionable results to the business/stakeholders

16. Putting Everything Together • An agreed upon project plan: • What business driven questions are being answered • What products are being produced from the assessment to answer the questions • What information is needed to produce the products • What resources (people, funding, and tools) are needed to produce the products • What schedule will the products be produced on

17. Maturity Model

18. Specific Goal • Objectively measure maturity of the Enterprise Architecture Program and identify concrete activities needed to increase the maturity level

19. Maturity Model • There are five maturity levels that apply to five categories • Maturity levels 0. No capability • Initial capability • Under development • Defined • Managed • Optimized • Categories • People • Processes • Technology • Controls • Strategy • Each category has specific actions that must be in practice throughout an organization to meet a specific maturity level • Example: To achieve Level 1 for “processes” the EA must perform the following actions • Processes are ad-hoc, unstructured, informal and/or inconsistent across technologies and/or lines of business • Documentation of business drivers, technology standards, and other artifacts are informal and inconsistent • Center has decided on a methodology to support the EA Program. • CIO communications are not standardized.

20. Maturity Model with Key Activities for Each Level Provide an Objective means of assessing Organizational EA Maturity

21. Evaluating Current Maturity Level Overall Maturity is based on how many activities are true across each category with weighting provided to account for a mixture of level 1, 2, 3, 4, and 5 activities ongoing concurrently

22. Planning Enterprise Architecture Maturity Improvement By altering what activities you decide to improve upon you can predict and create what-if scenarios for your near term and long term maturity level. This provides input into investments with rationale tied to organizational goals and objectives for EA maturity.

23. Conclusions

24. Conclusions • This activity produced two artifacts • A workbook for: • Planning and guiding Enterprise Architecture assessments that fundamentally tie back to key questions that the business needs answers to • Evaluating Enterprise Architecture maturity throughout the organization and planning improvements • A primer on enterprise architecture that provides an introductory level description of what Enterprise Architecture is and gives the basic knowledge needed to begin Enterprise Architecture assessments • Benefits to Enterprise Architects across NASA • The methodology can be utilized across NASA to establish and guide architecture assessments for any organization • The Fundamental starting point for performing Enterprise Architecture assessments begins with a business need to understand answers to key questions • There is a maturity model that provide objectives evaluation of how functional Enterprise Architecture is within an organization and provides clear guidance on improving