Doing Enterprise Architecture:

3,531 views

Published on

Published in: Technology, Business
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,531
On SlideShare
0
From Embeds
0
Number of Embeds
117
Actions
Shares
0
Downloads
280
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Doing Enterprise Architecture:

  1. 1. Technology & Standards Watch Early Adopter Study Doing Enterprise Architecture: Enabling the agile institution
  2. 2. 1 Contents 3. Executive summary Chapter 1 5. Introduction to the Enterprise Architecture Pilot Programme Paul Anderson and Gaynor Backhouse, TechWatch Chapter 2 11. Introduction to Enterprise Architecture Paul Anderson and Gaynor Backhouse, TechWatch Chapter 3 23. Introduction to TOGAF and The Open Group Paul Anderson and Gaynor Backhouse, TechWatch Case studies 37. Case study 1 Liverpool John Moores University John Townsend, Deputy Director, Corporate Information Systems LJMU 55. Case study 2 King’s College London Mark Hedges, Deputy Director, Centre for e-Research 69. Case study 3 Cardiff University Paul Hobson, Associate Director and Deputy CTO, Cardiff University Information Services Chapters 1, 2 and 3 © 2009 Intelligent Content Ltd Case study 1 © 2009 Liverpool John Moores University Case study 2 © 2009 King’s College London Case study 3 © 2009 Cardiff University
  3. 3. Executive summary 3 Executive summary A t the beginning of 2008, JISC funded a This programme also marks a new phase pilot project which set out to explore the of intra-JISC working: the longitudinal case applicability of Enterprise Architecture (EA), studies produced by the pilot projects have been a strategic management technique for enabling incorporated into this Early Adopter Study – the large companies to adapt to change, to the first in a new series of reports from TechWatch, higher education operational context. Although JISC’s technology horizon scanning service. Where largely unknown in the education sector, EA TechWatch’s existing remit is to anticipate and has been widely adopted over the last 15 years speculate, the study will demonstrate some of in the commercial world and in public sector the technology-related futures work that JISC organisations. EA provides an evolving, dynamic undertakes. The aim of this is to encourage way of describing and aligning the functional greater curiosity about futures thinking in order to aspects of an organisation: its people, activities, stimulate more widespread action. tools, resources and data/information, so that they work more effectively together to achieve the As well as documenting the Enterprise organisation’s business goals. Architecture pilot process, this study provides an introduction to the key concepts of EA and TOGAF. Three universities – Cardiff, Liverpool John Further TechWatch work in EA includes a high- Moores and King’s College London – were level synthesis and analysis of the programme’s the ‘early adopter’ organisations that were work. considered suitably ‘EA ready’ to undertake a 12-month evaluation of EA in the context of their own institution. In particular they ‘road- tested’ TOGAFTM, a non-proprietary framework for undertaking EA which has been developed by The Open Group. During the course of the project a small group of staff from each institution was exposed to the work of The Open Group, trained in the use of TOGAF and associated tools and techniques, and supported in the development of the first stages of an architecture for their institution. The pilot projects also shared emerging best practice with SURF, the Dutch equivalent of JISC. During the process they were asked to continually reflect on the process and hone the lessons learned as a way of providing feedback from the ‘bleeding edge’ to the wider community. The overall purpose was to try and answer the question: Can EA be fruitfully used by higher or further education?
  4. 4. Introduction to the Enterprise Architecture Pilot programme 5 1. Introduction to the Enterprise Architecture Pilot programme A t the beginning of 2008, JISC funded pilot 1.1 projects from three universities to explore the applicability of Enterprise Architecture The EAP programme and (EA), a technique for enabling large companies to adapt to change, to the higher education JISC’s innovation agenda operational context. More specifically, the EA pilot programme provided funding for the three Published in 2007, The e-revolution and post- universities to trial a particular approach – The compulsory education (Boys and Ford, 2007) Open Group Architecture Framework, or TOGAFTM explores the implications of e-business best – over a 12-month period and to provide an practice for post-compulsory education. In one of evaluation based on their experiences. the essays, Where are we now?, Les Watson surveys the state of play and examines how successful HE Funding for the projects came from the JISC has been at exploiting the opportunities offered by e-Learning Capital Programme (building on the ICT. The news is not good. Watson notes the huge e-Framework aspects of its work) although it is investment that has been made in recent years in recognised that EA has wider applicability than hardware, software, networks etc. However, he e-Learning. Therefore, as work on EA progresses, argues that across HE and FE there is little high- responsibility within JISC for driving that progress level, strategic impetus behind the integration of will be transferred to JISC’s Organisational these systems and the sector is still struggling to Support Committee (JOS), which is particularly get systems to ‘talk’ to each other. This is holding concerned with supporting the change capabilities back the potential gains that could be made from of both further education (FE) and higher education a modern ICT infrastructure and what is required (HE) institutions. is ‘an associated fundamental review – and rationalisation – of business processes’ (p.96). Watson goes on to demonstrate this using the ICL MIT 90s maturity model to map a view of business systems across the sector. The model has five levels of information systems achievement (in ascending order): Localised, Coordinated, Transformative, Embedded and Innovative, and he notes that ‘the UK HE and FE sectors remain at best at the coordinated level on the MIT 90s model’ (p.93). By this he means that institutions consist of data ‘silos’: self-contained data repositories, often part of small, department-level software systems. Each silo has its own system but will share some ICT infrastructure and some data with other silos. Citing the results of pilot projects (such as the JISC Managed Learning Environments for Lifelong Learning), Watson argues that the problem with
  5. 5. 6 Doing Enterprise Architecture: Enabling the agile institution moving towards a higher level of innovation are: Different countries have had different approaches. ‘“silo” culture, piecemeal tinkering rather than In the USA, the government has established organisational re-thinking… and a tendency to see the Federal Enterprise Architecture (FEA) and technology as a “neutral” solution to a problem, legislated through the Clinger–Cohen Act of 1996 not as the support for strategic business and that every government agency must have an EA. educational objectives’ (p.93, italics added). Lankhorst et al. (2005) argue that the Clinger– Cohen Act has been an important catalyst for It is this need to encourage organisational EA as well as the development of the discipline rethinking that the EA pilot programme set out to of architecture in IT. In Finland a common state investigate. IT architecture is being created – Finnish NEA – under the government’s Information Society programme. At the European level, the European Interoperability Framework for pan-European 1.2 eGovernment services has been developed.1 External strategic drivers: In the UK, a cross-Government EA (xGEA) has been introduced as part of the government’s governments, EA and ‘Transformational Government – Enable by shared services Technology’ strategy which was first published in 2005 and is being handled by the Chief Technology Officer (CTO) Council within the Cabinet Office.2 Governments across the world are increasing This high-level work will supplement rather than the pressure for public institutions and agencies replace the architecture capabilities of specific to consider the enterprise and formalise their public bodies.3 architectural processes. A Finnish government report concerning the state of play of EA in a In the UK, this work is part of a wider government number of different countries (FEAR, 2007) agenda of enabling a move towards a ‘shared shows that more than 90% of governments either services’ approach to delivering public services. have a national EA programme or are close to The shared services approach is being championed launching one. Much of this is tied up with the as part of the response to the Gershon Efficiency developing agenda around e-government and Review, which looked at public sector efficiency.4 providing accessible information flows to citizens. The Transformational Government report (which Such pressure inevitably flows down to individual followed Gershon) notes that: ‘Shared services departments, agencies and public institutions. provide public service organisations with the 1 http://europa.eu.int/idabc/en/document/2319/5644 2 http://www.cio.gov.uk/chief_technology_officer/index.asp 3 http://www.cio.gov.uk/documents/cto/pdf/enterprise_architecture_uk.pdf 4 http://www.hm-treasury.gov.uk/spending_sr04_efficiency.htm
  6. 6. Introduction to the Enterprise Architecture Pilot programme 7 of services and applies it to business and ICT opportunity to reduce waste and inefficiency by re- functions. It requires a change of thinking, seeing using assets and sharing investments with others’ organisational functions, software applications (p.12). and middleware as business services, application services and technical (typically now Web) Both HEFCE and JISC have responded to this services, respectively, and then aligning them. emerging public sector agenda by reviewing the Applied fully, the service oriented approach (soa) likely implications and ways forward with regard results in a Service Oriented Architecture (SOA). to tertiary education, through a number of reports. Most notable, in the context of this introduction, is the report known informally as the ‘Duke and Within UK HE, soa is presently enjoying a high Jordan’5 report into shared services (JISC, 2008). profile as a way of realising the vision of aligning Recommendation 9, for example, argues that business processes and ICT systems. There institutions should be supported in ‘the mapping are many similarities between EA and soa/SOA, and costing of specific business processes in but broadly, EA has a larger scope than SOA, institutional consortia’ (p.3), a process that is likely and conversely, SOA is now a common way of to involve some form of EA thinking. implementing EA. 1.3.1 Implementing soa in UK HE 1.3 The primary vehicle for JISC’s support for soa in The JISC EA programme: HE/FE is through the International e-Framework initiative, involving partners in Australia, the background and strategic Netherlands and New Zealand, and through context the development of the JISC Innovation Base. It is important to realise that both EA and the e-Framework have similar goals: to help define Across HE and the wider public sector, a business and technology related artefacts using a vision is emerging of an adaptive and flexible consistent methodology and vocabulary. The most ICT infrastructure that supports evolving important difference is that of scope. organisational goals. At the level of the technology needed to deliver this vision are software ‘services’ The International e-Framework describes – loosely coupled, autonomous, discoverable and service-oriented software models and is reusable software components which can be used focused on modelling and documenting forms of by different applications in a variety of contexts. interoperability between services as software and data layer components. The primary audience is More generally, ‘service orientation’ is an technical, consisting mainly of software developers approach, a set of principles that uses the concept and business analysts. EA, on the other hand, 5 with Mary Auckland
  7. 7. 8 Doing Enterprise Architecture: Enabling the agile institution “JISC has made a considerable commitment to the pilot programme with a total investment of £470,000” has a much broader sweep, being concerned with ten projects but only a small number met the the enterprise as a whole and the many areas of stringent requirements criteria with regard to ‘EA activity within it. Its audience ranges across the readiness’. In fact, the programme initially funded organisation and, critically, must include senior only three projects, at Cardiff University, King’s management and those with much less technical College London (KCL), and Liverpool John Moores backgrounds. University (LJMU), with a fourth project from Roehampton University joining the programme Whilst there is a continuing debate within the EA later in the year. community as to the exact relationship between soa and EA, one of the key points that everyone Each pilot project was given £50,000 to buy out agrees on is that problems can arise if these two time for one senior member of staff to participate are carried out within an organisation in isolation in The Open Group aspects of the project and of each other. to apply what they learned to their institutional architecture initiative (approximately 0.25 FTE). In terms of the EA pilot programme, the Specific Open Group activities included: e-Framework has been supporting the exploration of services and service-based approaches • Participation in one TOGAF training course for some time. Whilst JISC’s position is that • Participation in EA workshops for process a SOA is the prerogative of each individual modelling methods and tools institution, it recognises that the creation of an • Participation in two Open Group conferences institutional architecture, needed in order to • Participation in a joint SURF6 Architecture realise the benefits of a soa, is a non-trivial task. Meeting JISC therefore decided to undertake the pilot • Participation in The Open Group’s programme to support institutions that were ready Architecture Forum to start developing an institutional approach, using an existing, non-proprietary and widely accepted In addition, there were several JISC programme- framework – TOGAF – and support community – level activities, including: The Open Group. A discussion of the reasons for choosing TOGAF and The Open Group is included • Attendance at programme-level meetings in chapter 3 ‘Introduction to TOGAF and The Open • Engagement with TechWatch to create the Group’. case studies The remainder of the funding was allocated to 1.3.2 About the pilot programme enabling other staff members to support the institutional architecture initiative, engage with JISC has made a considerable commitment to JISC, and work under the supervision of the senior the pilot programme with a total investment member of staff to: of £470,000. The original JISC call was for 6 SURF is a consortium of Dutch HE and research institutes that guides ICT development in the sector and is a JISC partner.
  8. 8. Introduction to the Enterprise Architecture Pilot programme 9 • Trial (and evaluate) TOGAF include how they work together as a technology • Document the outcomes of the process for layer ‘business process’. The brief business layer the case study information enables the SUM and its services to • Contribute to evaluation and be incorporated into an EA as part of the business recommendations architecture. • Contribute to communication and dissemination activities Process and architecture models: beyond a name and a brief description, the e-Framework does not Extra funds of around £20,000–£30,000 per project capture the context information surrounding the were also made available to cover training costs business processes it models. With this in mind (eg workshops on the ArchiMate® modelling JISC funds the Innovation Base, a kind of ‘upper language and BiZZdesign EA tool), one year’s level’ that captures the context of a problem being Open Group Silver Membership, conference fees, solved, before handing over to the e-Framework software licences for EA tools, and additional to show how services are being used to solve the monies to allow institutions to make use of problem. It also acts as a repository for models external mentors and consultants. that are not intrinsically service-based. As part of the pilot programme each project is producing Additional support included a dedicated JISC process and architecture models that will programme manager who provided organisational eventually be added to the Innovation Base. support for the projects, and a representative from The Open Group who provided advice and liaison. Deliverables A longitudinal case study: created from quarterly progress reports and produced in conjunction with TechWatch. Service Usage Models (SUMs): as part of the pilot programme, projects produced SUMs that were incorporated into the e-Framework. Within the e-Framework context, SUMs show how one or more services are employed to provide a useful function. They are presented in the form of online documents that contain short summaries of supported business processes, set out the services that are involved in each stage of these processes, and indicate the data sources upon which these services operate. SUMs can be used as a link between business processes and background service components and may
  9. 9. architecture: The art of science of building; esp. the art or practice of designing and building edifices for human use, taking both aesthetic and practical factors into account. Oxford English Dictionary
  10. 10. Introduction to Enterprise Architecture 11 2. Introduction to Enterprise Architecture E nterprise Architecture (EA) is a high- 2.1 level, strategic technique designed to help senior managers achieve business Why consider EA? and organisational change. It provides an evolving, dynamic way of describing and aligning Although universities and colleges have invested the functional aspects of an organisation, its enormously in business and ICT systems in recent people, activities, tools, resources and data/ years there remains considerable frustration information, so that they work more effectively with institutions’ abilities to manage day-to-day together to achieve its business goals. EA is operations and handle the immense pressures for also about achieving desired future change change. Warning signs that all is not well will be all through design. It holds that by understanding too familiar to weary senior information services existing information assets, business processes, managers in HE/FE:7 organisational structures, information and application infrastructure (the ‘as is’ state) it is • Data exists in ‘silos’. Significant work is possible to ‘do something different’, something needed to take data from one system, new and innovative (the ‘to be’ state). manipulate it and enter it into another system • Information does not flow easily. ICT is a bottleneck to organisational change management because the information needed to make key decisions is not available • Meeting new regulatory or reporting requirements is a major effort • Lack of information integration means that staff and students have to visit multiple systems to get the information they need for daily work • Work processes and practices, knowledge and skills and supporting ICT systems are not well integrated to provide strategic capabilities • The institution lacks agility • Business process duplication means that the same activity is being completed by different systems across the institution • Senior management just don’t know whether the institution gets good value from investment in ICT systems 7 Adapted from Ross, Weill and Robertson (2006) and expanded.
  11. 11. 12 Doing Enterprise Architecture: Enabling the agile institution • Different parts of an organisation give 2.2 different answers to the same staff/student questions The Zachman Framework Proponents of EA argue that organisations which and the roots of EA are easier to manage and also handle change well have a ‘better foundation for execution’ (Ross et This process of enterprise-level thinking and tight al., 2006, p.2). Such organisations have embedded alignment between business and technology can ICT so that their business processes can carry be achieved through a formalised method first out core, day-to-day functionality efficiently and suggested by John Zachman back in the 1970s. reliably and are better placed to improve their Zachman, then a business systems planner for ability to respond to change (their agility). This IBM, was working with clients in the aeronautical effective foundation for execution depends on tight sector. He was struck by the similarities between alignment between business objectives and ICT what he was trying to do – make sense of and capabilities: a strategic application of ICT which organise complex business information systems delivers a closer coupling between business and – and the difficult process of pulling together management processes, strategic priorities and all the engineered parts of an aeroplane. The technological resources. difference was that aeroplane manufacturers had an architecture – an overarching process by which EA thus facilitates a high-level understanding of all the plans, models and technical specifications, the organisation as a holistic entity, that takes on many different engineering levels, somehow into account its structure, products, operations, all came together to produce an aeroplane that technology, and the web of relations tying these actually flew. together. This is achieved by working, thinking and communicating at the enterprise level. Zachman not only studied aeroplane manufacture but also went back to the ideas and concepts of Such thinking is not just ‘business school theory’. buildings’ architecture and examined the way Although these ideas are relatively new to the that the profession, with its long history, operated education sector, many large private companies with regard to developing representations of and public sector organisations are reported to the final product, stage by stage, from rough have gained great benefits from the adoption of EA bubble charting of key client ideas to the final, techniques over the last 15 years or so. architectural blueprints. In buildings’ architecture, different representations communicate information to different groups of people involved in the building’s development (the owner, designer, builder, electrician, etc.). Each of these is different in terms of what Zachman referred to as its ‘nature’, something that represents a different perspective, that has different semantics and content. To Zachman, each is not simply a provision of more detail but differs in ‘essence’.
  12. 12. Introduction to Enterprise Architecture 13 From this, he was able to construct an analogous 2.3.1 What do we mean by version of this ‘architecture’ way of working that ‘architecture’? could be applied to information systems. These insights led to the development of the The IEEE, when undertaking a body of work to nascent concepts of what was to become known formalise some aspects of architectural work as EA, and Zachman’s work had considerable (which became the IEEE 1471 standard), noted influence on the USA’s Department of Defense, that architecture itself is a difficult and somewhat which developed the Technical Architecture elusive concept that: ‘required elaborating on the Framework for Information Management (TAFIM) concept that an architecture is a very complex in 1994. This spread Zachman’s ideas throughout property of a system rather than a thing itself’ the US Federal Government and in 1999 the (Maier et al., 2001, p.107). What this attempts Federal Enterprise Architecture Framework to articulate is the need to distinguish between (FEAF) was released. The work on TAFIM that the architecture and the description of the took place within the Department of Defense architecture (used to record and communicate the was eventually turned over to The Open Group architecture). ANSI/IEEE published what is known who refined it into The Open Group Architectural as a ‘recommended practice’ in October 2000, Framework (TOGAF); this was used during the JISC which defined architecture as: EA pilot programme. ‘The fundamental organization of a system, embodied in its components, their relationships to each other and to the environment, and the 2.3 principles guiding its design and evolution.’ Defining EA Hillard, 2000 (presentation) Providing a precise, formal definition of EA is One other point to make is that it is a common difficult. Lankhorst et al. (2005) use the idea of an misconception to think that the word ‘architecture’ organising structure to offer a definition of the EA implies a focus on software or other technical technique itself: systems. An Enterprise Architect is not the same as a System Analyst and EA is not a process that ‘Enterprise Architecture: a coherent whole of should be controlled by the IS department. EA is principles, methods and models that are used only about technology in the sense that technology in the design and realisation of an enterprise’s has operational characteristics, provides organisational structure, business processes, operational context and one needs to align information systems and infrastructure.’ technology with other aspects of the business. Enterprise Architecture at Work, p.3.
  13. 13. 14 Doing Enterprise Architecture: Enabling the agile institution 2.3.2 What do we mean by ‘the educational institutions may find it easier to start enterprise’? from a project-by-project basis and build up an institutional EA step by step. One source of confusion is the term ‘enterprise’ – There are obviously dangers with this approach: what does it actually refer to? Much of the general if governance isn’t strong there is likely to be literature and other supporting materials are fragmentation across the organisation (one of the couched in business-orientated language that things that EA sets out to eliminate). In addition, can be difficult for public sector organisations to without senior management buy-in the results embrace. The Open Group are clear that: may not be used by other parts of the institution. What this emphasises is the importance of what ‘…“enterprise” in this context is any collection of architects refer to as scope. Unfortunately scope organizations that has a common set of goals and/ is a source of considerable confusion, not least or a single bottom line…The term “enterprise” because much of the associated EA literature in the context of “enterprise architecture” can emphasises the importance of considering the be used to denote both an entire enterprise, ‘whole’ organisation and working holistically. This encompassing all of its information systems, is one of the issues that is explored in the case and a specific domain within the enterprise. In studies. both cases, the architecture crosses multiple systems, and multiple functional groups within the enterprise.’ 2.3.3 Key concepts TOGAF 2007 edition (incorporating 8.1.1), p.4. These attempts at defining EA lead us to some important but general principles and concepts: If we substitute the word ‘institutional’ for ‘enterprise’ and remove references to the bottom • EA is a strategic management technique line then we may get a definition that is closer to that links business goals with information the thinking of those involved in education. It may systems. A part of an EA’s function is to help seem on first reflection that this implies that in HE/ provide the ‘glue’, or high-level aligning FE the fundamental unit that we are considering logic, between an organisation’s business – our enterprise – is the institution, an entire processes and the underlying ICT systems university or college. Closer inspection shows • EA involves taking a fundamental or holistic that The Open Group is implying that one can also view of an entire organisation or major part of consider the architecture of a specific structural an organisation domain (a faculty perhaps) within the enterprise or • EA is both a transitional process between even look in detail at one particular cross-campus the current state of an organisation and its specialism such as libraries, student records, etc. future, and is also a product (the documented Indeed, in practical terms, the latter approach may representation of the architecture) seem like a sensible place to begin a consideration • EA considers each of four architectural of the ‘enterprise’ as a whole. Experience from domains or perspectives of the organisation the Netherlands, for example, suggests that – ICT, business processes, data/information
  14. 14. Introduction to Enterprise Architecture 15 and applications. It is important to note that Enterprise domains this use of the word ‘domain’ is quite different to the more common use of ‘domain’ in UK At the base of the pyramid lie the key areas of HE, where it is used to refer to a ‘territory’ organisational life. These include staff and their such as a department or faculty domains of work that make up the organisation: • EA provides a mechanism for providing business processes, information, applications and organisational balance between these technology. EA is sometimes referred to as the architectural domains and for handling ‘place’ where these all meet. different stakeholders and their concerns • EA is fundamentally about facilitating clear communication between different groups of people within an organisation The importance of transition: • EA is widely carried out by architects, who from the ‘as is’ to the ‘to be’ are trained professionals. They may be drawn from both business and ICT communities Underneath strategy sit the concepts of ‘as is’ and ‘to be’ (often also referred to One way of understanding this better is to as the ‘baseline’ and the ‘target’), which consider where EA fits as a management process. are extremely important to the process of Lankhorst et al. (2005) depict EA within a pyramid architecture. A good deal of attention has to of management processes (see Figure 2.1). At the be paid not only to where the organisation top of the pyramid is the mission of the enterprise wants to be in the future, but also to being – the reason it exists. Beneath this is the overall very clear about the current state (existing vision and strategy of the enterprise. These should information assets, business processes, be translated by senior management into a series organisational structures, information and of strategic goals that take the enterprise from application infrastructure etc.). It is very its current position (often referred to as the ‘as is’ important that the process to determine the state) to a future scenario (known as the ‘to be’ ‘as is’ baseline is taken seriously. Feedback state). Translating these goals into changes to the from practitioners indicates the importance of business processes, day-to-day operations and this: you can’t know where you are going until ICT systems of an organisation – providing a kind you are clear about where you are. It is also of ‘road map’ – is where EA comes into play. A worth noting that every institution already has number of strategic management processes and in some senses an ‘architecture’, even if it has techniques are likely to feed in to the architectural evolved organically over the years and has not process including IT governance, IT service yet been documented. Identifying this current delivery (such as ITIL), quality management state can also help to find gaps, redundancies (EFQM) and other strategic management ideas and hidden data assets, and to show who does such as balanced scorecards. what and where in the institution they do it. Such a process may include some form of strategic gap analysis leading to the formation of a road map for the enterprise.
  15. 15. 16 Doing Enterprise Architecture: Enabling the agile institution Mission Vision Strategy Goals as is to be Enterprise Architecture Culture Actions leadership domain / aspect architectures people products processes Operations people IT ... Figure 2.1 Enterprise Architecture as a management instrument © Springer-Verlag, Berlin Heidelberg8 EA as organisational ‘glue’ Balancing views, concerns and stakeholders Each of the architectural ‘areas of concern’ can be considered to be a separate strategic discipline, The idea of providing a form of ‘glue’ leads to the and is likely to be the focus of separate groups importance of communication and, in particular, of people within an organisation. Often these the idea of being able to readily communicate groups will have their own expertise, processes between different organisational areas of work and and tools, and ways of communicating and the stakeholders involved in each one. sharing information about their area (for example, business process staff will carry out Business Stakeholders are a crucial concept in EA because Process Modelling, or BPM, and use a particular different stakeholders have different agenda tool or toolset to support this). Indeed they may or concerns and different perspectives as to even have their own forms of architecture. Thus the overall state of the enterprise. They often it is an important goal of EA to act as a kind of work within semi-autonomous groups in the ‘glue’ and to bring these together under a cohesive organisation and have little detailed understanding framework and, importantly, to provide balance of others’ work. For this reason architectural views across the enterprise. This is why EA is sometimes are representations of the overall architecture that described as a ‘meta-architecture’ (Armour et al., are meaningful to one or more stakeholders in 1999). the system. These must be expressed in ways that 8 Lankhorst, M. et al, (2005). This diagram is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilm or in any other way, and storage in data banks. Duplication of this publication or parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965, in its current version, and permission for use must always be obtained from Springer. Violations are liable for prosecution under the German Copyright Law.
  16. 16. Introduction to Enterprise Architecture 17 can be understood by the other stakeholders. The 2.4 detailed work of EA is to address these differing concerns, to understand and make sense of who Doing EA: state of the art the different stakeholders are and what views they hold, and to tease out potential conflicts between An EA may initially seem daunting to set up these different concerns in order to help senior and manage as it involves a continuing socio- management balance competing issues. Later technical process involving a number of internal on it will become important to represent this (and possibly external) stakeholders and senior information in a shared modelling language. staff throughout an institution. For this reason a number of structured methodologies and frameworks for developing and maintaining an Communication across the enterprise architecture, or parts of an architecture, have been developed by various organisations. These seek In order to be able to communicate across the to control and simplify the process of architecture enterprise, an Enterprise Architect must be able development and ensure complete coverage of all to explain the architecture to these different the related business and technical issues. Most groups and this leads to another key idea in EA: of these methods detail the different phases of the presentation of different views of the same an architectural life cycle, define precisely what overall organisational structure. As Lankhorst et deliverables are produced at each stage and how al. (2005) note: ‘Most stakeholders of a system are they are verified and tested. probably not interested in its architecture, but only in the impact of this on their concerns. However an architect needs to be aware of these concerns… 2.4.1 The enterprise life cycle and thus be able to explain the architecture to all stakeholders involved, who will often have A typical EA life cycle is provided at Figure 2.2. completely different backgrounds’ (p.2). Crucially, This illustrates the general steps that often take what EA recognises is that the successful adoption place in the development of an EA – the processes of an effective and flexible ICT infrastructure for initiating, developing and maintaining an requires the involvement of all stakeholders: architecture for the enterprise. It is important to senior institutional managers responsible for note the cyclical nature of the life cycle, the use policy and funding decisions, directors of corporate of baseline and target architectures, the need for information and ICT, registrars, librarians, senior executive buy-in from the very beginning researchers and other end users. In this way the of the process, and the early establishment process of undertaking EA can also help ‘raise of management control (or ‘governance’). The the game’ of the people working in the separate detailed life cycles of different methods will vary, domains because it has the effect of raising but most offer a similar overall view of the general general awareness of enterprise-wide issues. process. Whichever methodology is used, there are certain key characteristics of the process of undertaking EA. As we can see in Figure 2.2, there is a step-by-
  17. 17. 18 Doing Enterprise Architecture: Enabling the agile institution Obtain executive buy-in and support Establish Review the EA management structure and control Define an Maintain the EA Governance architecture process and approach Use the EA Develop baseline EA Develop target EA Figure 2.2 Simplified EA life cycle step procession through some form of life cycle, 2.4.2 ArchiMate: an emerging which is usually undertaken in an iterative fashion. language for EA EA is as much about undertaking a process as about producing a finished article. Indeed, it is important to keep in mind the idea that the A fundamentally important element of the ‘journey is its own reward’. During such a journey, architectural process is the communication members of the enterprise’s community will of ideas through the use of models. As we create, exchange and debate knowledge pertaining have seen in previous sections, different work to different topics (business, ICT, technologies, domains, groups and stakeholders exist across an etc.), which means that the actual process of organisation and have different views of the world, undertaking the architectural work generates which they communicate in different ways. In other benefits for the organisation itself, in the same way ICT and business fields, modelling languages have that the process of planning does. been developed to help with the formal process of describing and communicating elements of a model. In software development, UML is well known and widely used, and at the more business- orientated level, Business Process Modelling Notation (BPMN) and Language (BPML) dominate.
  18. 18. Introduction to Enterprise Architecture 19 Part of the work of the architect is to provide 2.4.3 Tools a ‘bridge’ between these different views of the world and between the models that they use. One EA brings together a wide range of information important way of doing this is to use a language from across an organisation or institution. This for modelling EA that focuses on integration and collection will include, for example, details of the relations between the different EA areas of software applications, models from different concern. architectural domains, business processes and details of organisational structures – and these There are a number of proprietary EA languages strands of information will probably have been and these are associated with particular EA created using a wide variety of tools. Thus, one modelling tools. However, most architecture of the key issues facing the architect is to be able languages focus on either the business or the to reconcile these different strands and in order technology side and thus fail to meet the EA to do this they need a central repository and requirement of cross-stakeholder communication. specialised architectural modelling tools so that There is one that does meet this requirement: the information can be accessed, manipulated and the ArchiMate language9 (Lankhorst et al., 2005), integrated easily. which emerged from work funded by the Dutch government and carried out by a consortium Choice of appropriate tools was important to of universities, government agencies and the pilot projects. They realised early on that commercial companies. This has well-defined basic tools such as Visio templates, whilst being semantics and a graphical representation and both easy to use and simple to learn, were not has been implemented in a number of tools. It sophisticated enough to perform modelling at has also been fully adopted by all the universities the enterprise level. For example, such basic in the Netherlands that belong to the SURF EA business modelling tools cannot be used to programme. create an integrated model: it is not possible to link up different components from different During the course of the EA pilot programme, the diagrams because the tools have no way of ArchiMate language was adopted by The Open representing or understanding these relationships. Group10 for standardisation and was trialled by the As a consequence, it is not easy to maintain projects. consistency, nor to determine the consequences of changing part of a model, as change is not propagated through the model. Also, because it is likely that, in the future, there may be several architects working together on the architecture, it is essential that the information be stored in some 9 http://www.archimate.org/en/about_archimate/what_is_archimate.html 10 http://www.opengroup.org/archimate
  19. 19. 20 Doing Enterprise Architecture: Enabling the agile institution “Of profound importance to the delivery of successful EA work is the role of the architect.” form of repository that supports multi-user access and tools of its architects, and give them the right and version control. position in the organisation’ (2005, p.313, italics added). Specialised EA tools provide a centralised data repository for the architecture and offer a wide variety of ways to visualise and structure the information. The use of such tools allows the architect to be able to present different views of the same information to different stakeholders. Some of the tools that were considered by the pilot projects included IBM Telelogic System Architect,11 Oracle Business Process Analysis Suite,12 Aris Business Architect13 and BiZZdesign Architect.14 15 2.4.4 The role of the architect Of profound importance to the delivery of successful EA work is the role of the architect. In larger commercial organisations this role is often undertaken by a dedicated professional architecture team led by a Chief Architect. The practices and products of the architect’s office must be embedded into the organisational life of the enterprise and even the most senior members of the organisation’s management need to engage with, and be informed by, the work of the architect. As Lankhorst notes: ‘To really profit from the strategic potential of enterprise architecture, an organisation needs to optimise the skills, methods 11 http://www.telelogic.com 12 http://www.oracle.com/technologies/soa/bpa-suite.html 13 http://www.ids-scheer.com/en/Software/ARIS_Software/ARIS_Business_Architect/3731.html 14 http://www.bizzdesign.nl/joomla/products/architect.html 15 Gartner publishes a regular edition of their Magic Quadrant for Enterprise Architecture Tools that reviews the market. The not-for- profit Institute for Enterprise Architecture Developments publishes a guide to tool selection that includes details of over 30 EA tools, see http://www.enterprise-architecture.info
  20. 20. Introduction to TOGAF and The Open Group 23 3. Introduction to TOGAF and The Open Group T his guide will introduce The Open Group 3.1 The Open Group and its work supporting the development of methodologies, tools and standards to The Open Group16 is an international, membership- support Enterprise Architecture (EA), in particular based, vendor-neutral consortium of suppliers The Open Group Architecture Framework (TOGAF). and buyers from industry, government and As part of the JISC Enterprise Architecture public sector organisations. It aims to provide an pilot programme a number of universities independent forum for the development and use of were provided with membership of The Open a range of ICT-related open standards and for both Group and explored the applicability of TOGAF the vendors and users of technology to exchange to their institutional settings. This introduction views on open standards development. The Open assumes the reader is familiar with the material Group is perhaps best known in educational circles contained in Chapter 2, ‘Introduction to Enterprise for its role as the certification body for the official Architecture’. definition of the UNIX® operating system, but in recent years the group has increasingly focused on EA-related work including developing and promoting TOGAF. The Open Group undertakes a wide range of activities, including: • Facilitating consensus to define, develop, refine and promote the adoption of ICT- related open standards and interoperability • Developing and promoting open standards policy and best practice • Test development • ICT conformance through certification including well-known standards and technologies such as CORBA, POSIX, UNIX, TOGAF, ITAC and Wireless Application Protocol (WAP) • Strategy and hosting services for other consortia • Publication of white papers, case studies and technical documentation 16 http://www.opengroup.org
  21. 21. 24 Doing Enterprise Architecture: Enabling the agile institution • A regular series of international wishing to develop EA using TOGAF; raising conferences and workshops on open awareness and promoting EA tools; developing standards-related issues case studies and white papers and organising events. Its core mission is structured around a central vision of integrated and timely information flows in and between organisations which support efficient 3.1.1 History of The Open Group business and organisational processes through the use of open standards. This is referred to as The Open Group’s roots lie in the mid-1980s and Boundaryless Information FlowTM, a term originally European computer manufacturers’ worries derived from the organisational ideas of General about the potential platform dominance of IBM Electric’s Jack Welch (The Open Group, 2002). and its OS/360 system. These concerns led to What this means in practice for an individual the emerging concept of ‘open systems’ (which organisation’s information infrastructure will vary, focused on interoperability) and the formation of but the overall goal remains to deliver the right the X/Open Company and the adoption of the information at the right time in an appropriate X/Open Portability Guide. context. For The Open Group this is about paying careful attention to technology and business and The X/Open Company’s early history then their interactions and synergies. The watchword is followed the contours of the twists and turns of interoperability and The Open Group argues that the story of the UNIX operating system. By the the route to this must be based on open standards early 1990s there were a number of competing that are accepted and capable of being conformed variants of UNIX such as Berkeley Unix (BSD), to by a broad community of organisations. SunOS and System V. This caused considerable problems for computer users and the period is The Open Group largely functions through a often referred to by industry commentators as series of semi-autonomous fora that focus on ‘the Unix wars’. Various attempts were made to particular areas of standards and interoperability- standardise these variants into a single UNIX, based work. Examples of currently active forums perhaps most importantly through IEEE’s POSIX include: the Architecture Forum (for EA); the standard. Although the details are somewhat newly formed ArchiMate Forum; and the Security complicated, the end result was that the UNIX Forum. The Architecture Forum is responsible trademark and rights to certification of what was for guiding the development of initiatives related or was not UNIX ended up with what was then the to EA and handles the development of TOGAF. It non-profit X/Open consortium. In early 1995 the provides a range of activities including: training group released a unified standard – the single and certification for individuals and organisations UNIX specification, now at version 3.17 In 1996, the 17 Further information on the convoluted history of UNIX can be found at: http://www.unix.org/what_is_unix/history_timeline.html; see also Goodheart, B., Cox, J. (1999). The Magic Garden Explained.
  22. 22. Introduction to TOGAF and The Open Group 25 “Many of the overall goals of The Open Group offer potential synergies with JISC’s role of guiding the development of technology and standards within HE/FE” consortium merged with a competing non-profit participate in forum meetings and make use of the group called the Open Software Foundation (OSF) TOGAF framework in a real-life use case. to form The Open Group. In recent years The Open Group has moved way from such ‘platform’ related matters to concentrate on the development of its Boundaryless Information Flow concept and 3.2 developing standards and best practice in the related area of EA. EA frameworks and methodologies 3.1.2 The Open Group and TOGAF The process of developing an EA is challenging In the early 1990s, John Zachman’s work and is likely to entail an ongoing socio-technical had considerable influence on the USA’s process involving a number of internal (and Department of Defense, which went on to possibly external) stakeholders and senior develop the Technical Architecture Framework staff throughout an institution. For this reason for Information Management (TAFIM) in 1994. a number of structured methodologies and This spread Zachman’s ideas throughout the US frameworks for developing and maintaining an Federal Government and in 1999 the Federal architecture, or parts of an architecture, have Enterprise Architecture Framework (FEAF) was been developed by various organisations. These released. The work on TAFIM that took place seek to control and simplify the process of within the Department of Defense was eventually architecture development and ensure complete turned over to The Open Group who refined it coverage of all the related business and technical into The Open Group Architectural Framework issues. Although these methodologies vary widely, (TOGAF). they all tend to specify the various phases of the architectural cycle of development and define deliverables at each such phase. To date no 3.1.3 JISC and The Open Group accepted single industry standard for developing an EA exists and it is one of the goals of The Open Many of the overall goals of The Open Group offer Group to make TOGAF into such a standard. potential synergies with JISC’s role of guiding the development of technology and standards within TOGAF is therefore one of a number of HE/FE, in particular The Open Group’s method architecture frameworks in use today. Prominent of working through federated fora of interested other examples of such frameworks include: parties. JISC has been exploring the potential for a longer-term relationship with The Open Group • Zachman Framework: the original through a 12-month pilot programme involving information systems architecture framework, three universities: Cardiff University, King’s that later evolved to take account of the College London, and Liverpool John Moores enterprise University. Each university was supported to • Federal Enterprise Architecture Framework: join The Open Group’s Architecture Forum, used for interoperability, information sharing
  23. 23. 26 Doing Enterprise Architecture: Enabling the agile institution and architecture development amongst US by the Enterprise Continuum (a form of virtual federal agencies repository in which all the architectural as- • Enterprise Architecture Planning sets are stored) and the Resource Base (a set of background documents, best practice guides and The key difference here is that TOGAF is a non- templates), which both feed into the ADM. proprietary generic architecture development framework. The Open Group argue that most EA frameworks focus on the deliverables that 3.3.1 The Architecture architectural activity should produce and not on Development Method (ADM) the actual process (The Open Group, 2008). TOGAF, therefore, does not prescribe a specific set of deliverables. Instead it describes a set of fairly The basic structure of the ADM consists of a generic deliverables and focuses on a method number of phases, labelled A to H, that are (known as the ADM) by which these or other, more iteratively cycled in a step-by-step process. This specific, deliverables can be produced. In this way iterative process is important, not only repeating TOGAF can be used as an architectural framework around the full cycle, but also between phases that is capable of using deliverables described by and within phases. As phases are undertaken one of the other EA frameworks. and completed there is a strong emphasis on frequent validation of results against the original expectations and requirements. At the start of each full cycle of the ADM an institution should 3.3 make careful decisions about the scope of the architectural work, the level of detail to be TOGAF considered and the time horizons that are being taken into account. In this way, a process of TOGAF is a global, consensus-based, non- architectural refinement can be implemented by proprietary standard framework that helps repeated cycles of the phases A to H. organisations develop an EA. It currently stands at version 9, but since this was only released in The Preliminary Phase is considered to be February 2009, the pilot projects actually made use particularly important as it is the stage where the of the previous version (8.1). It is provided by The organisation gains ‘buy-in’ from senior managers Open Group free of charge. and defines how it is to go about undertaking the architecture work. There are three main aspects: TOGAF consists of three major elements: choosing a methodology, defining the architectural • Architecture Development Method (ADM) scope, and core architectural principles. Principles • Enterprise Continuum are general rules and guidelines for the way the • Resource Base enterprise will handle its architecture and the underlying implementation. Examples include: ‘the The key component is the ADM, a methodology that enterprise shall comply with the law’ and ‘data is provides a step-by-step process for developing an asset and is defined consistently throughout the an EA (see Figure 3.1). The ADM is supported organisation’.
  24. 24. Introduction to TOGAF and The Open Group 27 Prelim: Framework and Principles A Architecture Vision H B Architecture Business Change Architecture Management G C Implementation Requirements Information Governance management Systems Architectures F D Migration Technology Planning Architecture E Opportunties and solutions Figure 3.1 Architecture Development Cycle source: The Open Group18 Choosing a methodology includes undertaking • Which parts of our organisation should we the necessary work to adapt the ADM to the include as being part of the ‘enterprise’? needs of the particular organisation (for • Which architectural domains are we example some organisations use the ADM with describing? (In general, a complete EA is Zachman’s set of defined deliverables). Questions considered to be made up of four elemental as to the availability of sufficient resources to domains: business, data, applications and undertake the architecture process, and the technology) return on investment, will feature at this stage. • To what level of detail should the architecting Defining scope well is particularly important and processes go? considerable effort should be put in to get this • What timescale are we considering? right at the beginning of the architectural process. This preliminary phase is also the place where Questions of scope are likely to include: issues of governance and the control of the project 18 The Open Group, 2008
  25. 25. 28 Doing Enterprise Architecture: Enabling the agile institution should be sorted out and is when an Architecture includes networks, middleware, standards, Board is put in place to oversee the process. etc. Phase A is the start of the ADM cycle and is Each of these architecture domains is handled focused on developing an Architectural Vision. This in a different phase: the Business Architecture is the stage at which the organisation’s mission, is handled in phase B of the ADM; the Data and big picture strategic drivers and business goals are Applications domains are handled together in considered. The architecture project is formally phase C; Technology is handled in phase D. established and further refinement is also made to the scope. If not already available, detailed The first time that the ADM process is undertaken business principles, visions, goals and strategic the architect will start with the basic architecture drivers are developed and formally documented provided by TOGAF. This is known as the and clarified. This phase also includes a first Foundation and is explained below. Each of the attempt at outlining a high-level description of the phases A to H contains detailed steps that take the baseline (‘as is’) and target (‘to be’) architectures. architect through the necessary processes for that These are outline descriptions developed from a particular phase. In each phase the Baseline (the business and a technology perspective and are current, ‘as is’) architectural state is considered built on in subsequent phases. This stage also together with the Target, or ‘to be’ state. A detailed includes a process of building organisational description of these individual steps is beyond the consensus around the emerging vision. scope of this introduction, but as an illustrative example a small set of the steps undertaken in TOGAF addresses four elemental architecture phase C (for dealing with the Data domain) include: domains which correspond to similar domains that are often considered important by a variety • Develop a business data model (entities, of EA methods and frameworks. They equate to attributes, relationships) collections of different viewpoints from different • Draw entity-relationship diagrams to key groups of stakeholders in the organisation and illustrate views of data addressing different can be summarised as: stakeholders • Develop data management process models • Business Architecture: defines the business (eg data life cycle, security) strategy, governance, organisation and • Review and validate data principles business processes • Data Architecture: defines the structure of Most phases involve a considerable amount of an organisation’s logical and physical data modelling and generate a lot of documentation – assets and data management systems each one has a defined set of input documents and • Applications Architecture: defines the generates a defined set of output documents, many architecture of the IT applications being of which feed in to the next phase of the ADM as deployed and their interactions and inputs. relationships to business processes • Technology Architecture: describes the Phase E (Opportunities and Solutions) identifies software and hardware capabilities and major work packages and projects and is
  26. 26. Introduction to TOGAF and The Open Group 29 the first phase to be concerned directly with particular technique for requirements engineering, implementation. Phase F (Migration Planning) although it does recommend the use of business aims to sort these implementation work scenarios. packages into an order of priority and produce an implementation road map. The Implementation Governance phase (G) brings together all the necessary information for successful management 3.3.2 The Enterprise Continuum of the various implementation projects. Finally the ADM reaches phase H, which focuses on The Enterprise Continuum is a virtual repository determining the circumstances under which the EA of architectural assets – models, patterns, will change after implementation and establishing business descriptions etc. – taken from within the processes to control this. organisation and the wider computing industry. These are similar to reusable architectural Figure 3.1 shows the importance attached to building blocks. The use of the term ‘continuum’ requirements management by placing this process rather than simply ‘repository’ is deliberate at the centre. This is a continuous, dynamic as it emphasises the multi-dimensional role process that makes sure that each phase of the of the Enterprise Continuum as a structured ADM is fully in touch with any ongoing development information resource, which is there partly to aid in the organisation’s architectural, business or communication. Architectural assets within the strategic requirements. These requirements are Continuum are not simply deposited as they are in likely to be fluid because architecture is an activity fact perceived as being ‘set’ at a particular point that deals with uncertainty and change. Each that stretches from the very generic to the very phase in the ADM includes an output that relates specific. The Open Group argue that the continuum to these requirements [for example, phase A concept helps to provide a consistent language (Architecture Vision) includes the output of high- for use by architects (both within and outside the level business requirements, possibly generated organisation) and that: ‘knowing “where in the by a technique such as business scenarios19]. continuum you are”, avoids people talking at cross Requirements engineering – the formal process of purposes’ (van Sante et al., 2007, p.31). This is collecting and working with business and strategic best illustrated by looking at one of the two main requirements – is an active area of emerging continua: the Architecture Continuum (Figure 3.2). work associated with a number of tools (such as IBM’s RequisitePro and Borland’s Caliber) and What this shows is the way in which architectures procedures. The Open Group does not mandate any can be classified from the very generic through 19 Business scenarios is a technique used to help identify and understand business needs through a process of documenting a complete description of a business problem or process (including identifying the business objectives, the human actors involved, the critical steps and interactions within the business process, the business and technical contextual environment and the results of the process).
  27. 27. 30 Doing Enterprise Architecture: Enabling the agile institution Foundation Common Systems Industry Organisation Architectures Architectures Architectures Architectures TRM SIB Logical Physical Taxonomy Complete architecture specification Figure 3.2 Simplified TOGAF Architecture Continuum to the very specific. The architectural process provides a model architecture and a taxonomy. takes the architect from generic architectures (on The SIB provides a database of standards for the left-hand side), through a refinement stage, information systems and this is held online by to a more specific architecture. The enterprise’s The Open Group.20 These standards come from a particular needs and business requirements are variety of sources such as ISO, IEEE, W3C, etc. addressed in increasing detail as one moves from left to right. It’s important to note that the four In addition, the Enterprise Continuum also stages shown (foundation, common, industry and contains the Solutions Continuum, which sits in enterprise) are only some of the points in the parallel with the Architecture Continuum. The continuum – it is possible for many others to exist. Solutions Continuum provides a consistent way to describe and understand the actual solutions, In order to make this process manageable the ie it defines the products, systems, software, architect will look for the more generic, reusable applications, and services that are available elements and assets from towards the left of the to provide implementations. The Architecture continuum. The Foundation Architecture, which Continuum guides and supports the Solutions sits at the far left of the continuum, represents a Continuum and vice versa. kind of fundamental building block on which other, more specific architectures can be based. The ADM process takes the architect from this Foundation through to an enterprise-specific solution. TOGAF provides its Foundation Architecture in the form of the Technical Reference Model (TRM) and the Standards Information Base (SIB). The TRM 20 Available at http://www.opengroup.org/sib
  28. 28. Introduction to TOGAF and The Open Group 31 3.3.3 The Resource Base 3.4 The final element of TOGAF is the Resource Professional development Base, a set of resources including guidelines, whitepapers, checklists, templates and and certification background information. These all help to support the architect through the process of undertaking The Open Group provides certification for the ADM and developing an enterprise-specific individuals who wish to demonstrate their architecture. Some key examples of the material knowledge of the architecture process and included in the Resource Base include: experience of using TOGAF. This can be obtained by attending a recognised training course or • Architecture Board: a set of guidelines for passing an Open Group examination. Vendors who establishing a governance board to oversee provide training and tools which relate to TOGAF the architecture process obtain certification through The Open Group. The • Architecture Skills Framework: guidelines Open Group has also developed and launched the that describe the skill and experience IT Architects (ITAC) certification which focuses on requirements for staff undertaking more general architectural work and is agnostic as architecture work to the methodology used.21 • Architecture Principles: guidelines for developing a set of guiding principles for the EA • Glossary 21 Further details are available at http://www.opengroup.org/certification
  29. 29. 32 Doing Enterprise Architecture: Enabling the agile institution References Lankhorst, M., et al. 2005. Enterprise Architecture at Work: modelling, Armour, F., Kaisler, S., Liu, S. 1999. communication, and analysis. Building an Enterprise Architecture Step by Step. Springer-Verlag: Germany. IT Pro magazine July/August 1999, pp 31–38. IEEE: New York. Maier, M., Emery, D., Hillard, R. 2001. Software Architecture: Introducing IEEE Standard Boys and Ford (eds). 2007. 1471. The e-revolution and post-compulsory education: Computer magazine, Volume 34, Number 4, using e-business models to deliver quality pp 197–109. education. IEEE: New York. Routledge: UK. Ross, J., Weill, P., Robertson., D., 2006. Cabinet Office. 2005. Enterprise Architecture as Strategy: creating a Transformational Government. foundation for business execution. HMSO: Norwich, UK. Harvard Business School Press: Available online at http://www.cio.gov.uk/ Boston, Massachusetts. documents/pdf/transgov/transgov-strategy.pdf Sante van, T. et al. 2007. FEAR. 2007. TOGAF, The Open Group Architecture Framework, Overview of Enterprise Architecture work in 15 A management guide. countries. Van Haren Publishing: Netherlands. Finnish Finance Ministry: Finland. Available online at: http://www.jyu.fi/it/laitokset/ The Open Group. 2002. An Introduction to titu/projektit/kaynnissa/fear/in_english Boundaryless Information Flow. Open Group white paper. Hillard, R. 2000. Available online at http://www.opengroup.org/ IEEE–std–1471–2000: Recommended Practice for bookstore/catalog/w033.htm architectural description of software intensive systems. The Open Group. 2008. Available online at: http://www.enterprise- TOGAF 2007 edition (incorporating 8.1.1). 8th edn. architecture.info/Images/Documents/IEEE%20 Van Haren Publishing: Netherlands. 1471-2000.pdf JISC, 2008. Study of Shared Services in UK Further and Higher Education. JISC: Bristol, UK. Available online at: http://www.jisc.ac.uk/ whatwedo/programmes/programme_jos/ssprev. aspx
  30. 30. Case studies 35 Case studies W hen JISC made its call for institutions to join the Enterprise Architecture (EA) pilot programme it was prepared to fund up to ten projects. In fact, only a small number met the stringent requirements criteria with regard to EA ‘readiness’ and the programme initially funded only three projects: at Cardiff University, King’s College London (KCL), and Liverpool John Moores University (LJMU). This appendix contains three case studies, one from each of the participating institutions. Before the pilot programme began, although the project teams had varying levels of theoretical knowledge of EA, it’s fair to say that each had a fairly low level of practical understanding of what this really meant. These case studies have therefore been written as both a record of the pilot process and an evaluation of EA and TOGAF, but also as the insider perspective that project staff felt would have helped them when they first embarked on the process of ‘doing EA’. As such, they are written from the perspective of their own institution with the aim of drawing conclusions that have wider applicability across the sector.

×