Doing Enterprise Architecture

1. Doing Enterprise Architecture John Townsend Deputy Director (Corporate Information Systems)

2. Agenda • Background – EA • Background – LJMU • The JISC EA Pilot Programme • Description • Outcomes • What’s Next • References/Further Information • Q&A

3. What Is An Enterprise Architecture?Definition One A description of the current and/or future structure and behaviour of an organization's processes, information systems, personnel and organizational sub-units, aligned with the organization's core goals and strategic direction.

4. What Is An Enterprise Architecture?Definition Two A conceptual blueprint that defines the structure and operation of an organization. The intent of an enterprise architecture is to determine how an organization can most effectively achieve its current and future objectives* *(SearchCIO.com)

5. What Is An Enterprise Architecture?Definition Three A high-level, strategic technique designed to help senior managers achieve business & organisational change *JISC Technology & Standards Watch Early Adopter Study – Doing Enterprise Architecture

6. Flavours of EA • Zachman Framework • Department of Defence Architecture Framework • Federal Enterprise Architecture Framework • The Open Group Architecture Framework • etc http://www.opengroup.org/architecture/togaf8-doc/arch/chap37.html

7. Zachman Framework

8. What Is A Service-Oriented Architecture? Service Oriented Architecture (SOA) is an architectural style that guides all aspects of creating and using business processes, packaged as services, throughout their lifecycle, as well as defining and provisioning the IT infrastructure that allows different applications to exchange data and participate in business processes loosely coupled from the operating systems and programming languages underlying those applications.

9. Processes SOA focuses onthe interface betweenthe Organisation and ICT SOA-based Applications Enterprise Architecture & SOA* • Organisation Structure & Function • People & strategy • Processes • ICT Structure and Function • Applications • ICT Infrastructure • SOA focuses on: • Practices & Processes • Service-Based Applications Enterprise Architecture looks at the whole So SOA is a common way of implementing part of Enterprise Architecture *after JISC/Bill Olivier

10. LJMU Background & Context • LJMU commitment to the European Foundation for Quality Management Excellence Model – winner of the 2008 UK Excellence Award* • Associated implementation of Balanced Scorecard approach to strategic management • Well-established Development Programme using Managing Successful Programmes (MSP**)approach – coherent approach to managing all IS/Process projects – aligned with corporate strategy & Excellence Model requirement to manage by fact & process *http://www.bqf.org.uk/ex_description.htm **http://www.msp-officialsite.com/home/Home.asp

11. LJMU Background & Context • Major investment in Oracle applications and technology • Existing Information Systems Architecture project taking first steps in EA development • New Governance structure with senior mandate to oversee Architecture & Principles

12. JISC EA Pilot Programme* • Ran for CY 2008 • 3 funded projects – LJMU, Cardiff & Kings • Objective: to pilot EA approaches in HE & in particular The Open Group Architecture Framework (TOGAF)**, & to evaluate the approach & associated software tools *http://www.jisc.ac.uk/enterprisearchitectures ** https://www.opengroup.org/architecture/

13. LEAP Summary (1) The LJMU Enterprise Architecture Pilot (LEAP) will build on existing work in Information Systems Architecture, Governance and technical web services development to pilot The Open Group Architecture Framework (TOGAF) approach to establishment of a full Enterprise Architecture model

14. LEAP Summary (2) LEAP will also incorporate work carried out by the LJMU Process Framework project, which has developed an overall process management model for the University within the context of our strategic commitment to the EFQM Excellence Model, and has produced detailed process maps of many areas of the business with more recently a particular emphasis on student administration. Phase 1 of the pilot will concentrate on developing the architecture model for the Student Recruitment, Development and Support core process identified within the LJMU Process Framework.

15. Pilot Objectives • to gain familiarity with the TOGAF approach • to incorporate existing work into the TOGAF approach • to apply TOGAF to the ‘Student Recruitment, Development and Support’ domain, completing first-cut Business, Information Systems and Technology architecture models for the area • to evaluate the success of the approach in engaging with senior management • to evaluate the success of the approach in aligning business objectives with information systems • to evaluate the success of TOGAF in supporting SOA approaches • to provide the basis for continuing EA/SOA work

16. Drivers • Wanted to: • Better understand the relationship between business processes and application systems to support ICT-enabled business change • Move to a position where the business understands/requires services not systems • (current economic climate) Better understand the capabilities of existing systems to realise required services, rather than the continuum of business application renewals • ‘...the Enterprise Architecture discipline has emerged from the need to derive maximum business value from IT investments’* *Enterprise Architecture Handbook, Iacob, Franken & van den Berg, BiZZdesign Academy Publishers 2007

17. Motivation - LJMU • Already identified EA work as essential to contextualise other activity eg Information Systems Architecture project, Student Administration Review, technical service developments • Architecture = key responsibility in new Governance structure • Major investment with Oracle predicated on Fusion implementation, requiring SOA approach • Opportunity to engage with other practitioners/the Open Group to advance learning & expertise

18. Benefits to LJMU • Opportunity to: • define our IT architecture, linking process, data, applications and infrastructure = in essence, defining what services we require now/in future, and which systems deliver/will deliver these service • be flexible and future-proofed • standardise data and processes • benefit from work being carried out elsewhere in the community

19. Motivation: Wider Community • Contribute to the development of EA models for the sector • Promote the importance of effective Governance structures for EA/SOA implementation • Contribute models at various levels to the e-Framework • Support the development of shared service approaches

20. What does success look like for LJMU • Senior Management engaged with EA/SOA approach • Understanding/model of how things fit together in student administration area • Commitment to continuing development • Practical implementation of services linked to business objectives • Enhanced ability to deliver EA/SOA approach

21. What does success look like for the Programme • Enhanced understanding of importance of EA/SOA approaches across the sector • Validation (or otherwise!) of TOGAF approach • Contribution to e-Framework • Learning from early adopters as basis for future work

22. Key Areas of Activity • TOGAF: training & familiarisation, attendance at Open Group Conferences • Tools: review & evaluation of possible tools; deployment of selected tool • Business Architecture: review & assimilation of existing artefacts • Governance: promotion through Governance structure & development of Information Management Principles • Research: reading ref other/alternative approaches eg Enterprise Architecture As Strategy; Dynamic Enterprise Architecture; attendance at various events • e-Framework: workshop & familiarisation

23. TOGAF • TOGAF to EA like PRINCE2 to Project Management – seems too big, may be best treated as toolkit, use what works • Is a process – fairly neutral on what an EA may look like, what tools may be used, practicalities of modelling • The Architecture Development Method seems to conflict with our use of MSP – from LJMU point of view, there is a point at which the ADM would hand over; equally, parts of the ADM seem to fall into the institutional strategic planning process • Trick seems to be to align what you’re already doing with the ADM and fill in the gaps, rather than start with a blank sheet of paper

24. TOGAF Strategic planning/ Governance Programme Management

25. Approach (emergent) • implement a Governance structure that mandates Architecture development, develops Principles and gives Executive Board level endorsement • start assimilating artefacts/learn about TOGAF • select a tool (BiZZdesign Architect) • model the EA across the whole organisation at a high level, to give context/connectivity • select a burning platform to go into detailed EA and demonstrate business value (in LJMU’s case, Student Recruitment, Development & Support – driven by a high profile two year project to transform student administration)

26. Tools • All research suggests a deployment of a comprehensive EA tool is essential • Reviewed various options – Telelogic (IBM), Oracle, Orbus – settled on BiZZdesign Architect* • Based on the Archimate modelling language** • BiZZdesign delivered training & follow up • Beginning to get to grips with using tool, developing models in the area of Student Recruitment, Development and Support • Using with Business • Seems to be right choice, as ‘easy’ as an EA tool gets, particularly good in managing relationships – but this as much Archimate as the tool *www.bizzdesign.nl/joomla/component/option,com_frontpage/Itemid,1/lang,english/ **http://www.archimate.org/

27. LJMU Architecture

28. Governance & SOA “In 2006, lack of working governance mechanisms in mid size to large post-pilot SOA projects will be the most common reason for project failure ” (0.8 probability – Gartner)

29. IT Governance – A Definition • IT governance: Specifying the decision rights and accountability framework to encourage desirable behaviour in the use of IT* *Weill and Ross, 2004, IT Governance, HBSP

30. IT Architecture Decisions Organising logic for data, applications,and infrastruc- ture captured in a set of policies, relationships, and technical choices to achieve desired business and technical standardisation and integration IT Infrastructure Decisions Centrally co-ordinated, shared IT services that provide the foundation for the enterprise’s IT capability. Business Applications Needs Specifying the business need for purchasing or internally developed IT applications. Key IT Governance Decisions* IT Principles Decisions High-level statements about how IT is used in the business IT Investment and Prioritisation decisions Decisions about how much and where to invest in IT, including project approvals and justification techniques. *Ibid.

31. IT Governance Archetypes* STYLE Who Has Decision or Input Rights? Business A group of business executives or individual executives (CxOs). Includes Monarchy committees of senior business executives (may include (CIO), excludes IT executives acting independently. IT Monarchy Individuals or groups of IT executives. Feudal Business unit leaders, key process owners or their delegates. Federal C-level executives and business groups (eg business units or processes); may also include IT executives as additional participants. Equivalent of the central and state governments working together. IT Duopoly IT executives and one other group (e.g. CxO or business unit or process leaders). Anarchy Each individual user. *Ibid.

32. IT Governance Principles and Architecture Information Management Steering Group Business Membership Business Applications Needs Infrastructure CIS Membership Systems Development Programme Board IT Steering Group Business Membership Business Membership MSP ITIL Investment & Prioritisation

33. LJMU Governance Membership • 7 members of the LJMU Senior Management team, out of a total of 16 • School Directors • Service Directors – Library, Estates, HR • Admin/project/resource managers • All ICT Senior Managers

34. Continuum of user engagement • Doing it to them • Doing it for them • Doing it with them • Doing it to themselves

35. What Can Governance Do For You? • Get buy-in across the board • Do it with them, even if they don’t do it to themselves • Change behaviour, not just technology

36. EA & Governance • Executive buy-in to EA approach • Within LJMU Governance structure, Architecture already identified as responsibility of Information Management Steering Group • Demonstrate value of EA approach • ‘burning platform’ required, provided by existing Student Experience Review initiative • Visibility • Exposes Senior Management to EA approaches

37. Selling EA & Governance • Speak the language of the business • Or something as close as you can get • It’s all about value • The business has to see that this will promote better IS decision-making to support the business better • Show them pictures • Not like I’ve been doing in this presentation… • EA development will provide the pictures • See JISC SOA animation http://www.jisc.ac.uk/whatwedo/programmes/programme_eframework/soa.aspx

38. Selling EA & Governance • Business value: • Business wants to know how to analyse staffing requirements in light of increasing self-service • ‘As Is’ Architecture – self-service capability mapped to business processes as of now • ‘To Be’ Architecture – self-service capability mapped to business processes in light of move to Campus Solutions • Giving a visual representation that addresses the business problem

39. Governance – IM Principles • Information is a valuable shared institutional resource and must be managed appropriately throughout its lifetime. • Information should be available to those who need it (ideally ‘anytime, anywhere, and anyhow’) subject to security and acceptable use policies. • University information must be trustworthy (relevant, accurate, timely, secure) • All members of the University community are personally responsible for managing the information they create and use. • Information management should add value to the University community. • The status of information sources (e.g. definitive/primary, derived/secondary) must be clearly defined and only definitive/primary sources should be updated. • Information management must comply with external statutory and regulatory requirements. • Information management principles will inform IT principles. • There is a common vocabulary and data definition. • The University is responsible for assisting staff to work in the most effective ways possible.

40. Research & Evaluation • Alternative approaches: Dynamic Enterprise Architecture (DYA)* • Discussions with Oracle UK extending into meetings with Griffiths Waite, Oracle consulting partner & EA/SOA specialist • Engagement with EDUCAUSE EA constituent group (ITANA) & BCS Architecture Group • Interest in Dutch SaNS group, taking an EA approach to implementation of Oracle Campus Solutions *Dynamic Enterprise Architecture, Wagter et al, Wiley 2005

41. Outcomes/Next Steps(Dec ‘08, end of LEAP) • Overall high-level Architecture in place • Architecture for Student Recruitment, Enrolment & Development modelled in Architect • SUMS in relation to Enrolment in development for e-Framework • Architecture approach recognised as beneficial, further EA work mandated as part of major project to move from the Oracle Student System to Oracle Campus Solutions by 2010

42. Questions/Issues(Dec ‘08, end of LEAP) • Need to establish specific EA resource – Enterprise Architect as staff role • Is Open Group membership necessary/beneficial for the future? • Will BiZZdesign Architect prove to be the best tool in the longer term?

43. Roger Sessions, ObjectWatch, May 2007* “Whichever route you choose, remember that EA is a path, not a destination. EA has no value unless it delivers real business value as quickly as possible. One of the most important goals of any EA is to bring the business sides & the technology side together so that both are working effectively towards the same goals”. http://www.objectwatch.com/white_papers.htm#4EA

44. Outcomes/Next Steps • Identified Business Analyst role as key • Appointed Programme Office Manager • Expanded Programme Office to 4 Business Analysts, location of EA work, extending training to group • Established principle that all IS projects would include ‘as is’ & ‘to be’ architectures – incremental approach, building up big picture through individual projects • Archimate: big win, great for articulating relationships between people/processes/systems, using actively with business users in IS/Change initiatives

45. Enterprise Architecture

46. Some Initial Conclusions • Good Governance is essential • EA is not something you do just to have one – needs to be applied where can deliver business benefits, if can’t, don’t bother • Needs to be integrated with other existing approaches, part of overall toolkit, not new big thing • All about Change Management • Speak English

47. What’s Happening Now • Early Adopter Study published: • Doing Enterprise Architecture: Enabling the agile institution http://www.jisc.ac.uk/whatwedo/services/techwatch/reports/earlyadopters.aspx • JISC Flexible Services Delivery Programme launched • http://www.jisc.ac.uk/whatwedo/programmes/flexibleservicedelivery.aspx • Will include EA in HE Practice Group, including existing early adopters, the Open Group, and colleagues from the Netherlands • Join ENTERPRISE-ARCHITECTURES@JISCMAIL.AC.UK

48. Finally • Governance is an activity not a committee structure • EA is an activity not an artefact • They both form part of a vehicle that can help get you where you want to go • If you don’t want to go anywhere, you don’t need a vehicle • If you don’t know where you’re going, a vehicle won’t help

49. & again • Focus on making full & effective use of the systems we’ve already got: • Useful, Usable & Used • Means focus on people: • See VPEC-T: • Lost in Translation. Green & Bate, 2007 Evolved Media LLC • www.LIThandbook.com • “In the current economic climate, an effective enterprise architecture (EA) program is a necessity, not a luxury...” Gartner May 2009 http://www.gartner.com/it/page.jsp?id=995712