ITC 19 th November 2015 Creation of Enterprise Architecture Practice

Transcription

1 ITC ITC 19 th November 2015 Creation of Enterprise Architecture Practice C Description of paper 1. As part of a wider strategy of Digital Transformation of the University s core services, ISG have created an enterprise architecture (EA) practice. This paper explains why the team was created, what benefits the team will bring, describes the work it will be doing, and explains how the team will interact with the wider community. Action Requested 2. The committee is requested to comment on the approach for the team to engage with the wider university community. Recommendation 3. The Enterprise Architect to report progress to the IT committee periodically, via the Progress Updates standing agenda item. Background and Context 4. The purpose of enterprise architecture is to optimize IT and business processes across the University into an integrated whole that is responsive to change and supports the University strategy. The digital transformation the University wishes to see requires an agreed architecture that enables services to be coordinated, integrated and both seen and experienced by the staff & students as a holistic service. 5. The purpose of the EA team is to lead and co-ordinate the creation, maintenance and exploitation of architectural resources and standards in order to increase the flexibility and efficiency of the University s IT systems and business processes. Terminology and scope 6. Enterprise Architecture is an industry term in which enterprise refers to the entirety of an organisation. In the context of the University, in addition to the University s enterprise IT services, the University s enterprise architecture includes central services that the University provides to support research, teaching and learning, such as the research data service and VLEs. Schoolbased systems that support the operations and administration of the University will also be included. It should be noted that the University s enterprise architecture will encourage and support local services where local needs cannot be met by central systems.

2 7. The enterprise architecture will not include national and commercial services provided by EDINA, EPCC and other similar services, except where those services are provided to students as part of their engagement with the University. 8. Systems that students and researchers write as part of their study or research is not covered by the enterprise architecture, although the enterprise architecture way provide facilities such as sources of open data that these projects can exploit. Similarly, specialist local equipment is excluded from the remit. What problems are we solving? 9. Although IS support a large number of IT services and have a track record of successful projects that enhance the function of the University, these services and projects tend to suffer from a lack of co-ordinated planning and standardisation. This is exacerbated by the devolved nature of the University, as these services are run by different units within the three support groups, which makes collaboration and co-ordination harder. 10. These problems have been confirmed by external consultants, including the BI/MI Needs Analysis by Deloitte MCS, the Financial Systems Provision Review by KPMG, and the Architecture Scoping Study by Chaucer and Smart So far, the University has not strategically planned its data architecture at an enterprise level. This is a key gap and barrier in the ability of the institution to leverage is management and business information. It is increasingly important that the University s data accurately models the reality of the university s operations, that it is up-to-date, and that our data systems give people the information they when they need it. Key projects such as The Service Excellence programme, RAM, the HR Transformation project, and the BI/MI project require 2

3 overall enterprise architectural strategy and standards, data architectural planning and expertise from a dedicated function within IS. 12. The lack of co-ordinated planning also leads to a fragmented user experience for our students and staff. Sometimes users may need to log in to several systems in order to find all the information they need, rather than have this information presented to them in a single place. For example, students have to use different systems to see their lecture timetables, exam timetables, and course deadlines, rather than having these presented to them in a single calendar. Depending on the systems they need to access, users may have to sign in multiple times, sometimes with different user names. Policies such as the use of EASE for signon and MyEd to centralise access to systems have provided some consistency in the past but not all systems have followed these policies. The increasing use of vendor-hosted services puts pressure on our existing policies and we need to adapt. 13. There can be a particular discontinuity between central systems and schoolbased systems. It is currently difficult to access data programmatically from central systems, which can lead to data being input locally, followed by increasing discrepancies between central and local sources of information. 14. The widespread use of mobile devices requires a cross-university strategy in order to provide a consistent and useful user experience. While key services such as MyEd and the University Website have led the way, using cross-platform systems that adapt to different screen sizes, there is more to be done and new opportunities to be exploited, such as presenting information specific to the user s current location. Why we are setting up the EA team 15. The problems outlined above can be addressed by the introduction of an Enterprise Architecture function. The EA Team will be responsible for the following tasks: Defining and disseminating architectural principles, standards and resources Engaging with colleges and business units to align IT and business strategy and planning Leading and co-ordinating the creation, maintenance and use of architectural artefacts and standards, in order to simplify the integration of IT systems, to reduce development and maintenance costs and to reduce redundancy in systems provision. Working with the Data Governance Group to define data definitions, data models, data dictionaries and associated processes for using and maintaining these resources, in order to ensure consistent understanding of what data means and to allow effective decision-making, from operational levels to strategic levels Working with the Information Security Team to ensure that the architecture standards ensure that IT systems continue to meet the University s security requirements. 3

4 Defining reference architectures and reusable APIs in order to provide easy-to-use, joined-up services that meet users needs Assessing IT procurements and project proposals for conformance to the University s IT architecture, in order to reduce integration costs and redundancy of systems provision Supporting IT projects with guidance, analysis, and by reusing artefacts created by previous projects Benefits of creating the EA team 16. The Chaucer/Smart421 scoping study recommended the creation of an EA team, saying that a mature EA capability will: Provide the University with the ability to create and maintain a common vision of the future shared by both the University business and IT driving continuous business/it alignment; Provide a holistic view of IT, ensuring that solutions are fit for purpose, cost effective and aligned with University strategy; Help to develop common standards driving consistency across the University and suppliers; Reduce IT estate through rationalisation of applications against a Target Application Landscape (TAL); Help unify and integrate business processes across the enterprise; Give the University the ability to unify and integrate data across the enterprise and link with external partners/institutions; Increase agility by lowering the "complexity barrier"; Increase controls around systems and data security; and provide a key control point for the new Information Security team. Reduce solution delivery time and development costs by maximizing reuse of enterprise models; and Ensure documentation of the enterprise is readily available 17. The EA team will engage with projects and systems in their initial design stage. This will mean that all new projects like the new HR system, are specified and designed from the ground up in accordance with the architecture and that we have a strategic and integrated approach to data and application design. 18. The benefits for students, staff and the University will manifest in several ways. These should all improve student (and staff) satisfaction, lead to more efficient processes and enhance the University s reputation: A consistent and integrated user experience Authoritative data as a shared University resource, supporting quality quantitative-based decision making Process standardisation, optimisation and adoption More agile and efficient IT services Support for open data initiatives 19. Even if there are cases in which we cannot migrate all services to match the ideal, there is value in knowing what is desired and documenting the exceptions that arise. 4

5 Interactions with the wider community 20. The EA team reports to the Director of Applications Division. Regular reports will be presented to the IS Directors and to ITC. Priorities for the team will be determined by the enterprise architect, the Director of Applications Division and the CIO. 21. The enterprise architect is the first point of contact for general enquiries about the architecture. 22. The EA team will liaise with several other groups, including the Data Governance Group, Service Owners, the Procurement Office, and project teams within IS. For people working on projects with IS, IS will ensure that the EA team is appropriately engaged when required. 23. It is planned to create a technically-oriented Architecture Advisory Group. This group will advise the EA team on technical matters relating to various IT systems. Members of the group may also take role of architectural guidance on particular projects Planning for Enterprise Architecture 24. IS have seconded Dave Berry to the post of enterprise architect for 2015/16. An additional data architect contractor will join him for the remainder of the year. A budget for the team has been included in IS long-term planning. 25. The EA team will undertake two streams of work packages. One stream will iteratively build a central architecture capability, while the other will work with IT projects to iteratively tackle specific business issues. Thus the EA team will deliver immediate business benefits at the same time as contributing to a central repository of architectural artefacts for use by future projects. 5

6 26. The central architecture repository will hold artefacts such as data models, API descriptions, process flow diagrams, policies and standards. It will include catalogues of applications, APIs, data descriptions and other artefacts so that projects can find IT functionality that they can reuse. Much of the actual information will be added to the catalogues and dictionaries by IT projects. Each work package and project will be responsible for updating the collection of artefacts with the information pertaining to that project. 27. In the year 2015/16, the team will create the first instance of the repository, probably using Confluence or SharePoint. (More sophisticated tools are available and may be worth adopting when we have clearer understanding of our requirements). The team will also create key university-wide artefacts, including a conceptual data model & business vocabulary, high-level target architectures, and an interface catalogue. The team will also support a number of specific projects, to be determined from those ongoing. Resource implications 23. ISG includes the Enterprise Architecture practice in its funding plans. Risk Management 24. Establishment of the EA practice mitigates the risks noted above that arise from the previous lack of co-ordinated planning and standardisation. Equality & Diversity 25. There are no equality or diversity issues associated with this paper. Next steps/implications 26. The Enterprise Architect will establish the relationships noted above with relevant parties across the University. 6

7 Consultation 27. This paper has been reviewed by Gavin McLachlan (CIO) and Simon Marsden (Director, Applications Division) Further information 28. Dave Berry Enterprise Architect - Information Services 10 th November 2015 Freedom of Information 29. Open paper 2

8 Appendix Enterprise Architecture Principles: Summary Draft Version th October

9 Enterprise Architecture Principles: Summary Introduction The purpose of enterprise architecture is to optimize IT and business processes across the University into an integrated whole that is responsive to change and supports the University strategy. The Open Group defines principles as, general rules and guidelines, intended to be enduring and seldom amended, that inform and support the way in which an organization sets about fulfilling its mission. Enterprise architecture principles form the foundation upon which all architectural design decisions should be made within the University. These principles must be guided by the strategic goals for IT and should be clearly related to a small number of key architecture goals. Taken together, they should underpin a consensus across the University. This document sets out the (draft) enterprise architecture principles of the University of Edinburgh. These principles are modelled on the approach used in TOGAF, The Open Group Architecture Framework. The Open Group provide a sample set of architecture principles as part of the documentation of TOGAF and that prior art forms the basis for the University of Edinburgh EA principles 1. This basis is modified to align with the particular characteristics, strategy and goals of the University. Architecture Goals Three high-level goals encapsulate the major concerns that the enterprise architecture sets out to address: ENTERPRISE ARCHITECTURE GOALS A consistent and integrated user experience that delights our students Right first time design that reduces support costs and enables change Authoritative data as a shared University resource These goals encompass a number of architecture principles, each of which gives a more detailed rationale and implications. The goals set the vision; the principles provide the framework for analysis. Relation to the IS Strategic Vision The architecture goals are derived from the IS Strategic Vision 2015, which is summarised in the table shown overleaf. A consistent and integrated user experience that delights our students This statement directly addresses the student experience and support for online learners. It puts students and other users at the heart of the design of the University s processes and services. It requires units within the University to work 1 The Open Group, TOGAF 9.1, Part III: ADM Guidelines & Techniques, Architecture Principles, 1

10 Enterprise Architecture Principles: Summary together to provide a seamless, integrated set of services for students. The statement also supports the need for innovation, both to achieve the goal in the first place and to keep up with students expectations of our services. STUDENT EXPERIENCE Student experience and the unique Edinburgh offer Online and distance learning leaders Library national and international leadership RESEARCH & INNOVATION Research IT and Data Sciences Innovation Collaborative leadership and social responsibility SERVICE EXCELLENCE Process improvement, efficiency, quality and best practice Long-term IS strategic planning and linked professional services Information security `Right first time design that reduces support costs and enables change This statement primarily addresses the goal of process improvement, efficiency, quality and best practice. It also requires innovation in order to create better processes. Improvement in these areas frees resources to concentrate on other goals. Authoritative data as a shared University resource The management and care of University data underpins most of the goals in the IS Strategic Vision. Business Intelligence and Management Information (BI/MI) is vital for strategic planning in IS and other units, and best practice in this area will significantly improve processes. The exploitation of open data can address areas of social responsibility as well as innovation. The sharing and provision of timely data will give students the information they need, when they need it. At the same time, confidential data, including personal details, must be kept secure. Other considerations The enterprise architecture practice is itself one of the facets of IS strategy that directly addresses the vision of long-term IS strategic planning. These EA principles are a contribution towards achieving the long-term IS vision. 2

11 Enterprise Architecture Principles: Summary Some facets of the IS Strategic Vision are not directly reflected in the architecture goals. Library leadership and research data do not require architectural goals of their own, although of course the EA principles will apply to the IT in these areas as they do to all other areas of the University. Similarly, collaborative leadership with the wider community does not affect the enterprise architecture of the University, even though the EA practice may itself share experiences and knowledge with the wider EA community in the HE sector. Overview The EA principles are grouped by the four domains of Enterprise Architecture: Business, Data, Application and Technology. These domains are described by TOGAF as follows: The Business Architecture defines the business strategy, governance, organization, and key business processes. The Data Architecture describes the structure of an organization's logical and physical data assets and data management resources. The Application Architecture provides a blueprint for the individual applications to be deployed, their interactions, and their relationships to the core business processes of the organization. The Technology Architecture describes the logical software and hardware capabilities that are required to support the deployment of business, data, and application services. The EA principles for each of these four areas are shown in the following table. EA Principles ID B1: Primacy of Principles Principle Business Architecture Goals Consistent and integrated user experience Authoritative data as a shared University resource Right first time design These enterprise architecture principles apply to all organisational units within the University. 3

12 Enterprise Architecture Principles: Summary B2: Maximise Benefit to the University B3: Common Use Applications IT and business process decisions are made to provide maximum benefit to the University as a whole. Applications used across the University are preferred over similar or duplicate applications that only work for a particular unit. B4: Federation Local applications are supported and encouraged where units have local needs. B5: Digital First Business processes should be designed with the online user experience to the fore EA Principles ID D1: Golden Copies and Data Stewards D2: Data is Shared for Access and Innovation D3: Common Vocabulary and Data Definitions D4: Value is Extracted from Data 4 Architecture Goals Principle Data All data held in enterprise systems have a golden copy that holds the definitive value of that data. Consistent and integrated user experience Authoritative data as a shared University resource Users have access to the data they need; therefore, data is shared across the University. Data is defined consistently throughout the University, and the definitions are understandable and available to all users. Services provide users with consistent, accurate and timely information that allows them to make informed decisions. Right first time design D5: Data security Data is protected from unauthorized use and disclosure. A1: Integrated Experience Applications Services are easy to find, easy to switch between, use common look-and-feel, consistent terminology and show consistent data. A2: Ease of use Applications are easy to use, anytime, anywhere and on any device. A3: Build for reuse The applications architecture incorporates reusable APIs for providing/consuming data and providing common functionality. A4: Failure The impact of system failures and data transfer management failures is minimised. A5: Innovation Applications keep up to date with user expectations and take advantage of new technologies to improve efficiency. T1: Control technical diversity Technology Technological diversity is controlled to minimize the cost of maintaining expertise in and connectivity between multiple environments.

13 Enterprise Architecture Principles: Summary T2: Automated and scalable provisioning T3: Monitoring and analytics Management of technical environments is automated. Services can scale to handle changing load or additional users. Systems are monitored for failures and problems. Usage and load is tracked and used to plan and adjust capacity. T4: IT Security IT systems are protected from unauthorized access. 5