The Enterprise Architecture IT Project

The enterprise Architecture IT Project This page intentionally left blank The Enterprise Architecture IT Project T...

Author: LongA©pA©

654 downloads 2474 Views 12MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

The enterprise Architecture IT Project

This page intentionally left blank

The Enterprise Architecture

IT Project The Urbanisation Paradigm

Christophe Longepe

Schlumberger

London and Sterling, VA

First published in France in 2001 by Dunod entitled 'Le projet d'urbanisation du systeme d'information. Demarche pratique avec cas concref. First published in Great Britain and the United States in 2003 by Kogan Page Science, an imprint of Kogan Page Limited Apart from any fair dealing for the purposes of research or private study, or criticism or review, as permitted under the Copyright, Designs and Patents Act 1988, this publication may only be reproduced, stored or transmitted, in any form or by any means, with the prior permission in writing of the publishers, or in the case of reprographic reproduction in accordance with the terms and licences issued by the CLA. Enquiries concerning reproduction outside these terms should be sent to the publishers at the undermentioned addresses: 120 Pentonville Road London Nl 9JN UK www.koganpagescience.com

22883 Quicksilver Drive Sterling VA 20166-2012 USA

© Dunod, Paris, 2001 © Kogan Page Limited, 2003 The right of Christophe Longepe to be identified as the author of this work has been asserted by him in accordance with the Copyright, Designs and Patents Act 1988. ISBN 1 9039 9638 4

British Library Cataloguing-in-Publication Data A CIP record for this book is available from the British Library.

Printed and bound in Great Britain by Biddies Ltd, Guildford and King's Lynn www.biddies.co.uk

Contents

Preface I Preface II Acknowledgements

xi xiii xvii

Part I: Foundations

1

1 The issues 1.1 The stakes for the enterprise 1.2 Identifying the changes necessary for the implementation of the strategy 1.3 Safeguarding coherence and improving the efficiency of the IT system 1.4 Quicker installation of quality systems 1.5 The responses made to these stakes

3 3

5 8 10

2 The metaphor of the city 2.1 Why dwell on this metaphor? 2.2 The parallel between urbanism of the city and that of IT systems 2.2.1 The Land Use Plan: a key element in urbanism 2.2.2 Breakdown of the city into sub-sets 2.2.3 Urbanism rules 2.2.4 Procedure for drawing up the LUP 2.2.5 Monitoring respect for the LUP 2.2.6 The infrastructure 2.2.7 Businesses 2.2.8 A basic tool: cartography

13 13 13 13 15 18 19 19 20 21 22

3

vi

The Enterprise Architecture IT Project

3 Concepts and rules 3.1 The basic principles 3.2 The metamodel and concepts 3.2.1 Introduction 3.2.2 The metamodel 3.2.3 Definitions of the metamodel concepts 3.3 The different perspectives 3.3.1 The four levels of the reference framework 3.3.2 The sequence for a future urbanisation 3.4 Urbanism rules 3.4.1 Urbanism rules for modelling the strategy (Ishikawa diagram) 3.4.2 Rules of good practice for modelling the strategy 3.4.3 Urbanism rules for the business architecture 3.4.4 Rules of good practice for business architecture 3.4.5 Urbanism rules for the functional architecture 3.4.6 Rules of good practice for functional architecture 3.4.7 Urbanism rules for the software architecture 3.4.8 Rules of good practice for software architecture 3.4.9 Urbanism rules for the technical architecture 3.4.10 Rules of good practice for technical architecture

23 23 27 27 27 29 37 37 39 40

Part II: Illustration of the approach: the tour operator

49

4 The case study 4.1 Introduction 4.2 The tour operator 4.3 General presentation of the tours 4.4 The organisation department 4.5 The marketing department 4.6 The finance department 4.7 The travel agency 4.8 Financial results 4.9 Construction of the methodological solution 4.9.1 The stages of the approach and the choice of life cycle . . . . 4.9.2 Deliverables 4.9.3 The project's actors and authority

51 51 51 53 54 55 55 57 58 60 60 62 66

41 41 41 42 43 44 45 46 46 47

Contents

vii

5 Urbanism and strategy 5.1 Harnessing the strategy 5.2 Modelling the strategy 5.2.1 Presentation 5.2.2 The objectives model 5.2.3 The enterprise diagram 5.3 Case study: urbanism and strategy 5.3.1 Introduction 5.3.2 The strategic business objectives 5.3.3 Objectives of the IT system 5.3.4 Correspondence of business objectives/IT systems objectives 5.3.5 Conclusions on the understanding of the strategy 5.3.6 Enterprise diagram 5.3.7 Appendices

69 69 72 72 73 75 76 76 77 80

6 Urbanism and business processes 6.1 Introduction 6.2 Business processes cartography and the link with the strategy 6.2.1 Business processes cartography 6.2.2 The process/strategic objectives matrix 6.3 The process modelling 6.3.1 Introduction 6.3.2 The (organised) process diagram 6.3.3 Reusing the process 6.3.4 Breakdown or subcontracting 6.3.5 Coordination strategies in the case of an actor network architecture 6.3.6 Soft and hard process models 6.3.7 Urbanism rules for process models 6.3.8 The rules of good practice for process models 6.4 The evaluation and improvement of processes 6.4.1 Introduction 6.4.2 The evaluation of processes 6.4.3 The improvement of processes 6.5 Case study: urbanism and business processes 6.5.1 Introduction 6.5.2 The business cartography of the existing IT system 6.5.3 Target business cartography

97 97 98 98 99 100 100 100 103 103

82 85 87 90

104 105 105 106 107 107 107 109 111 111 111 121

viii


7 Urbanism and functional architecture 7.1 The link between functional architecture and business architecture 7.2 Transition of the business architecture to functional architecture . . . . 7.3 The urbanism rules 7.3.1 Reminder of the founding principles 7.3.2 Urbanism rules for functional architecture 7.3.3 Rules of good practice for functional architecture 7.4 Case study: urbanism and functional architecture

133

8 Urbanism and software architecture 8.1 The link between the software architecture and functional architecture 8.2 Existing software cartography 8.3 Transition from the target functional architecture to the target software architecture 8.4 The urbanism rules 8.4.1 Urbanism rules for the software architecture 8.4.2 The rules of good practice for the software architecture 8.5 Case study: urbanism and software architecture 8.5.1 Introduction 8.5.2 Case study: existing software architecture 8.5.3 Case study: target software architecture 8.5.4 Comments on the changeover from software architecture to technical architecture

153

185

Part III: The methodological approach

187

9 How do you define the target and the associated migration plan? 9.1 Introduction 9.2 Construction of the solution 9.3 The urbanisation process of an IT system 9.3.1 Planning the study 9.3.2 Business strategy gathering 9.3.3 Current enterprise architecture analysis 9.3.4 Strategy design 9.3.5 Migration plan design 9.3.6 Publication of the strategy 9.3.7 Strategy review and update 9.4 Summary of the finished products

189 189 191 191 191 194 202 216 228 236 238 240

133 134 136 136 137 138 140

153 154 157 160 160 161 161 161 161 170

Contents

ix

Part IV: The dynamic of the actors

243

10 The participants and their roles 10.1 The actors and bodies 10.1.1 The actors 10.1.2 The bodies 10.1.3 The roles of the actors at the time of the study 10.2 Skills, techniques and tools 10.2.1 Skills 10.2.2 Techniques 10.2.3 The tools 10.3 Take a new approach to the relationship between project ownership and project management 10.3.1 Background 10.3.2 The new challenge: the transition towards the insight era 10.4 The role and organisation of the urbanism focus group 10.4.1 The purpose 10.4.2 The missions 10.4.3 The pitfalls 10.4.4 Organisation

245 245 245 248 250 253 253 254 255

Conclusion Appendices Glossary Bibliography

269 273 275 291

Index

293

259 259 261 263 263 264 266 267


Preface I

I have worked in the IT business for thirty years and I have carried out numerous projects with my teams. I have always attached great importance to the fruit of these many experiences being structured to produce methodologies suitable for the formalisation of IT systems and project implementation. So, at the beginning of the 80s, I took part in the creation, then distribution, of the MERISE method. However, information technology evolved more rapidly than our capacity to usefully integrate them into our enterprises, and more generally, into society. A certain loss of synchronisation between the technology, IT system and maturity of the enterprise managers led to dramatic failures. This is why it is vital to formalise its knowledge in order to better communicate it. Christophe Longepe has lead this effort to structure, in a practical way, this art which consists of describing an IT system in an urbanised way. I encouraged him to do so, because he has the qualities needed: firstly, he has skills in IT systems engineering and, to this end, he has managed projects. But that is not enough to draft such a document; he teaches, and for this reason he can set up case studies drawn from real experience, but above all, he listens, is attentive and curious, which allows him to constantly improve his methodological ideas. The concept of urbanisation has developed gradually over the last ten years until it became totally illusory to replace one information system with another more recent system at one go. This concept was made practicable when the idea of objects became apparent, but particularly when the inter-object data exchange software became efficient enough for it to be possible to plan this organisation on a larger scale.

xii


The key element in the urbanisation approach, and one which is very clearly explained in this book, consists of establishing the traceability between the fundamental objectives of the enterprise and the corresponding process. Very often, and I have seen this on several occasions, the systems implemented are built over much longer periods than those initially planned, which leads to the loss of a large amount of functionality along the way which had particularly justified the purpose of the development of the system. I cannot encourage enterprises and major administrations enough to put this approach into practice, so they can focus their investments on the major stakes and thus preserve their previous investments while minimising risk with a controlled and gradual overhaul of existing systems. Rene Colletti Director General, France, Belgium, Switzerland, SchlumbergerSema

Preface II

I am very happy to promote the work of Christophe Longepe, whose talent I spotted many years ago. His mastery of the urbanisation of information systems and the remarkable effort he has put in to the structuring and formalisation of his ideas has lead me to entrusting him with the teaching of this subject at the Institut du Management de l'lnformation. His service affects and concerns a large number of enterprises insofar as it provides answers to three current sets of issues: 1. The enterprise, even if it has achieved excellence, can no longer succeed alone, but has to operate together with other partners in a more sustained cooperative fashion than before. 2. The life-cycles of technologies, organisations and strategies develop increasingly quickly, creating an urgent need for the ongoing development of associated information systems. 3. The enterprise is therefore confronted, on the one hand, by the need to redeploy its organisation and IT systems, which are increasingly integrated, and on the other hand, by the need to overcome the inconsistencies and "mecommunicability". of certain subsystems, which are the result of a long history. This work sets out, in fairly great detail, all the activities and tasks necessary for there to be a successful outcome to an Enterprise Architecture IT project. It provides answers to the challenges referred to above. The reader will find in it all the components which will allow him to progress towards the construction of the deliverable product by using the recommendations formulated by the author on the participants. dynamic plan (who does what, when, how?).

xiv


The urbanisation of IT systems must not be confused with a modelling technique such as UML. Any urbanisation project can certainly be carried out in UML by following the approach proposed in this book. An Enterprise Architecture IT project is the immediate extension of the evolving strategic blueprint. As I have been very much involved in this area since 1978, I would expect this book to make a great impact because its approach to urbanism has a starting point that targets enterprise migration. So, in a period dictated to it by the short-term situation, the enterprise must step back a little and align its IT systems to its strategy and organisation. This can no longer be carried out in a single stage because we no longer live in stable environments suited to regular planning. The consequences are therefore as follows: 1. Merise logic can no longer be relied on (more suitable to the 80s), as it consists of concentrating on a software domain (such as a "district" in a "town"), but not on the "whole town". Up to now, we have adopted dichotomous scenarios, in other words, it was decided to design a new application (or carry out its migration), or to look at the whole of the IT system ("the town"). Today, the context and acceleration rates in development restricts us, after viewing the whole of the "town", to keeping the sound parts and to very quickly repair or equally quickly redesign the fragile or obsolete parts. The urbanist works on the "town" level and not on the level of an isolated "building". The working out of the "town" cartography (i.e. the enterprise's IT system) and its target functional architecture will set the terms of reference for everything. Enterprises feel the urgent need for this. 2. This book is a real trailblazer in that Christophe Longepe writes with brio on the methodological plan. It can serve a major enterprise or small and medium-sized enterprises. It is a really flexible "toolbox" from which it is possible to select the chapters that will be most appropriate to the reader's set of problems. This approach covers most things (business, functional, software and technical architecture), describing what exists and the target. It is progressive. It is not necessary to run through all the stages in every project. With such a set of tools, it must be possible to assemble and install and adapt this approach to the specific context of the enterprise.

Preface II

xv

For example, for the acquisition of a software package, the author recommends restricting oneself to business and functional architecture (which, incidentally, constitutes an objective set of reference terms for the assessment of the various products on the market) while, for studying an existing IT system to be renovated, he recommends pushing the study further, also covering software and technical architectures. 3. This work contains the keys of a long-awaited methodological revival. The language used in it tries to eliminate any esotericism in order for it to be understood by the broader public. Nevertheless, as with any methodology, you cannot skip over the new terminology or the new glossary made available to the reader by the author. Every enterprise is a special case and therefore merits special attention. Besides the mastery of this "toolbox", the urbanist will be extremely vigilant as to the influence and management of the changeover. There are in fact rational "towns", well planned and well built, but little or poorly inhabited. A constant effort of alignment between the urbanisation project and the strategy of the enterprise must be in the mind of the reader. Communication is the result. In an uncertain environment, the community of the enterprise's members must advance in successive stages towards these targets. It is no longer a question of rushing into grandiose projects. To control the risks, there must be new approaches and a new dynamic from the participants adapted to the culture of the enterprise. In fact, this new way of acting and development as a unit opens up new perspectives compared with the traditional between the project management and the project owner. The art of managing complex projects, and on this Christophe Longepe is insistent, therefore lies in being able to combine a voluntaristic logic of migration and a logic of opening up and allowing for the continuous integration of all the variables which may contribute to the permanent adjustment of the system. The traditional division between the project management and project owner has therefore found itself transformed in order to go along the route of collaborative team relations. The reader will discover, for example, the new roles of the urbanism project steering committee among the other bodies in the enterprise and everybody's rights and duties in a project setting.

xvi


The implementation of an urbanism plan is closely linked to the governance of the IT systems department (ITD). Consequently, the discovery of this approach (which is an essential brick in the ITDs business) is consistent with an effort to find the overall vision that the reader should also undertake personally on the IT systems management level. I wish you a good read. Gerard Balantzian Director of the Institut du Management de L 'Information (Universite de Technologie de Compiegne)

Acknowledgements

This book would not exist without the encouragement of the IMI (Institut du Management de L'information - Universite de Technologie de Compiegne) where I have taught the urbanism of IT systems for three years, and whose spirit unquestionably contributed to the dawning of individuals and ideas. I would like to thank Gerard Balantzian, the Director of the IMI, for his encouragement, support and proofreading, which contributed to the quality of the book, and for his preface, which illustrated the IMI spirit. I would also particularly like to thank Rene Colletti, Director General of SchlumbergerSema France, who has been behind the work carried out at Sema for four years on the urbanism of IT systems, who proofread this book and benefitted us with his experience, and who has prefaced this book. I must also thank those people who have contributed by their proofreading, comments and/or suggestions as to the overall quality of this book. I am thinking particularly of Philippe de Raedemacker, Christian Druez, Eric Jeunieaux, Pascal Pare, Eric Vermeulen and Bruno Xoual.

To Patricia, Hugo and Marco

Part I

Foundations


Chapter 1

The issues

1.1 The stakes for the enterprise The IT system is today at the heart of the running of any organisation, and its efficiency influences its performance. The constant evolution of businesses and techniques has made the management of systems more complex. It is therefore vital for the enterprise to run its IT system strictly and coherently. A major difficulty in making an efficient IT system available for the enterprise or organisation is finding a balance between the following factors: • • •

identifying the changes necessary to implement the enterprise or organisation's strategy; backing up the coherence and improvement in efficiency of the IT system; quicker installation of quality systems while limiting the risks and costs linked to the communication between the various functions involved, the integration of new technologies, tools and methods.

1.2 Identifying the changes necessary for the implementation of the strategy The great challenge for managers nowadays is to move around in the vast chaotic world of the globalised economy in which the rules and dynamics are in perpetual evolution. The challenges are: • •

deregulation and the new economy are introducing new competitors into traditional markets; clients are becoming increasingly informed, demanding and selective;

4


•

the concept of the client has been extended to internal departments and functions, to partners and suppliers.

In order to identify these challenges, the enterprise's models are evolving from simple pyramid or hierarchical systems towards open systems built on a complex network of cooperative processes. In this context, one must continue to: • • •

identify and anticipate different actions for potential progress; make choices and set investment priorities; establish and follow the relationship between the IT systems and the organisation's strategy.

In order to improve their comprehension of the processes, managers today are led to building abstract representations of their organisation, the environment in which they are involved (other functions, clients, suppliers) and flows between actors. An effective model allows for the simulation of the impact of any change in the efficiency of the processes as a whole, and thus provides invaluable elements in aiding decision-making as to adapting organisations and flows to the changes. The process management methodologies are a means for identifying the changes necessary for the implementation of the enterprise or organisation's strategy. Process management allows for: • • • • • • • •

the analysis and modelling of existing processes in the enterprise; the identification of benefits which may be obtained in the short term, and also to give the first positive results very early in the project; the target organisation's business vision definition; the evaluation of the organisational and technical capacity to achieve the vision; the simulation of the impact the changes will have on costs, deadlines, customer satisfaction, etc.; the choice of a scenario; the modelling of the target processes; the implementation of these processes and their coordination with any subjacent computer projects.

The Issues

5

Process management is not a tool for determining the enterprise's mission, vision or strategy. These are assumed to be already defined and are used as such to work out the processes to be analysed. The strategy is modelled using a hierarchy of objectives. The objectives are therefore broken down into sub-objectives until all the objectives can be achieved by at least one process. The process management approach provides: • •

the detailed definition of the process operating ranges (i.e. the procedures) which allow for the enterprise or organisation's strategy to be underpinned; their coherence with the upper layers of the IT system (design aspects).

The process management approach can be used both in the context of the gradual improvement of a single process (TQM = Total Quality Management) and in the context of the fundamental re-engineering of all the processes in the enterprise or organisation (BPR = Business Process Reengineering).

1.3 Safeguarding coherence and improving the efficiency of the IT system The identification of the changes necessary for the implementation of the enterprise or organisation's strategy, and the growing information needs arising from this, definitely increases demand for development of them IT system. On the state of the art technology level, we have advanced from centralised systems built around relational database systems to systems distributed on networks. Research into technological architectures, platforms and tools to improve efficiency have brought about new trends like the Internet/intranet/extranet, component-based multi-level architectures, and others are emerging, such as massive parallelism.

6


So, past developments have contributed to the forming of an often incoherent "legacy system" which is due to the stratification of the software, the superimposition of different technological layers and the use of multiple development tools and languages. The purchase of large computer sites, represents a considerable investment which is no longer economically viable and it is often too risky to start again completely. Indeed, in the event of starting again completely, experience shows that the real added value of the new system compared to the old one is only evident in 20% of the perimeter of the system, most functions being replaced in an almost identical way, while the cost and risk affect 100% of the perimeter. The problem therefore lies in making the IT system as reactive as possible (i.e. capable of being rapidly updated to respond to new demands, so at the extreme, to be adaptable to a new economic situation) while preserving the enterprise information pool as far as possible. The introduction of new technologies is one of the responses to this problem. However, poor use of these technologies undermines the shift between the means supplied by the IT system to deal with the needs of the enterprise or organisation and the users, and leads to overspending which is difficult to control. To safeguard the coherence and efficiency of the IT system, a complex combination of reusing a purchased system and implementing technical architectures, platforms and tools to improve efficiency must be carried out. This requires analysing the components of the existing system and the clarification of the interdependent links between the sub-systems. This is the objective of existing systems cartographies. The urbanisation approach is the key means of safeguarding coherence and improving the efficiency of the IT system. The urbanisation approach allows for concentration of effort on the development of new functions with a high added value and the reuse of the existing system for the most part.

The Issues

7

The urbanisation of towns requires in particular: • • •

a LUP (Land Use Plan) for buildings and housing; an infrastructure (networks, shared services, equipment); operational principles (input, output, continuity, connection and interconnection).

In the same way, an urbanisation project applied to IT systems involves: • • •

the dividing up of the IT system into zones, districts or plots; the creation of an infrastructure as the unifying axis of the IT systems; the formalisation of the construction laws for software applications that are independent of the infrastructure in order to manage the interoperability of the systems.

The auditing of existing blocks allows for the undertaking of redevelopment or demolition, limited to certain plots, districts or zones, without involving all of them. The insertion of a new block comes down to: • • • •

structuring the content of the new software application; identifying the location within the LUP where it should be inserted; maintaining services that are already available and reusable; developing the remaining specific services.

IT systems being complex, efficient urbanisation approaches are often difficult to implement. The practical approach given in this book allows enterprises or organisations trying to safeguard the coherence and efficiency of their IT system, while minimising costs and risk, to move on from theory to practice. The method is a proven approach, patiently perfected, and incorporates: •

an industrial methodology;

8


•

the use of currently proven technologies. For example, EAIs (Enterprise Application Integration) are used in defining the urbanisation infrastructure of the IT system for managing flows of messages between software applications. This kind of message management allows for the connection of any old, new and tailor-made applications, or even new package-based applications, in a shared infrastructure.

1.4 Quicker installation of quality systems Some studies (Ovum, Standish Group) tend to show that today, 80% of projects are abandoned, over-budget or out of time. The study by the Standish Group referred to was carried out in the USA in 1995 and updated in 1996 from a sample of 365 companies and 8,380 projects. The success of a project is characterised as being delivered on time, at a cost within the budget and completely meeting its specifications. The failure of a project is characterised by the stopping of the project and its abandonment before completion. Lastly, the semi-success or semi-failure of a project is characterised by the late delivery of a system which only partially fulfils its specification, notably in terms of perimeter covered, and at a cost which may be as much as 200% of the initial budget. The diagram below illustrates the results of the study.

Fig. 1.1 Success rate for software projects

The Issues

9

Of these 8,360 projects, only 16% were a success, 53% a semi-success or semi-failure and 31% failed. The proportion of abandoned projects, overbudget or out of time, was therefore 84%. Of course, these studies are a little out of date, but experience shows that, today, these statistics have probably not altered in any significant way. This proves that the rapid installation of quality systems remains a real challenge. The rapid installation of quality systems is carried out, depending on the case, by the selection and installation of software packages available off-theshelf or by specific development. For the latter, the technologies may vary from central systems technology to object-orientated technology and associated architectures, including the client server. In order to reduce development time, the traditional V development cycle, which starts with the specifications and ends with the validation of the software, is set against a spiral cycle which is inspired by concepts such as RAD (Rapid Application Development). The robustness of the V-cycle has proved itself, while the spiral cycles have the advantage of frequently involving all those taking part in the project (in particular the users) in the validation of prototypes and, consequently, of taking the changes into account earlier in the life cycle of an overall project. However, each type of cycle generates its own risk of drift, depending on the context in which it is implemented, ie: • •

"tunnel" effects of V-cycles, the users lacking visibility of the future application before its delivery; validation of misunderstood diagrams or performance problems with the final system when assembling the sub-sets for spiral cycles.

The setting up of quality systems comes about by making the appropriate choice, firstly of a specific approach as against a package approach, secondly, by the determination of the relevant type of life-cycle for the context. Finally, an overall IT system urbanism plan clearly defining the location of a system and its interfaces with the rest of the IT system also contributes greatly to the more rapid installation of applications.

10


Each project is unique. It has its own restrictions of size, deadlines, costs, performance, environment in terms of newness, reuse of modules already developed internally or bought in the market, qualifications of users such as data processors and associated risks. In order to set up quality systems more rapidly, a methodology is needed which covers all the standard stages of an analysis, design, development and installation of applications-orientated components projects: • • • • • • • • • •

gathering and analysis of the requirements of all types of users (end users, but also software system operators); design of the software architecture; design of the technical architecture; design and construction of the software application; detailed design and construction of the technical architecture; test and integration of the software; conversion of the system; installation of the system; acceptance of the system; deployments of the system.

1.5 The responses made to these stakes In this book, we are trying to describe the IT system urbanisation approach in detail, i.e. an approach that allows for improving the efficiency of the IT system while maintaining its coherence. Process management will not be covered in detail and could in fact be the subject of a book of its own. It is, all the same, touched upon, because the alignment of the IT system to the enterprise strategy involves, firstly, understanding the enterprise or organisation's strategy, and secondly, analysing the existing processes and target process definitions to be aligned to the strategy. The modelling of existing processes and target process definitions to be aligned to the strategy is therefore an essential stage of the IT system urbanisation project. This being the case, the specific use of the methodological tool that makes up the process management in the context of the urbanisation project is described.

The Issues

11

Finally, the methodological approach to the development of a new tailormade application in a component approach is not dealt with in this book and could also be the subject of an entirely separate book. What is more, there are a number of books already published on this subject and, in contrast with the methodological approach to IT systems urbanisation, there are a great number of service companies that provide for this domain. More generally speaking, in order to respond fully to the stakes described in this chapter, and in particular the third one (setting up a quality system quicker), the use of methodological approaches to application construction is required. Indeed, urbanism certainly provides the overall plan, but each structure planned for in this overall plan needs to be carefully designed and put together. In order to do this, we must look at the methodological frame of reference of the market, including methods for installing software packages, tailor-made design and development of centralised systems and tailor-made design and development of component-based distributed systems. The commitment and feature of this book is therefore to concentrate on the IT system urbanisation approach, including the essential control of process management.


Chapter 2

The metaphor of the city

2.1 Why dwell on this metaphor? The metaphor of the city, and more specifically the vocabulary, rules and principles of the urbanism of towns has been widely used in the IT systems field because of the similarity of the initial set of issues: how to overhaul, modernise and judiciously profit from technological advances without erasing the past, within the cost limits set, and do so while continuing to live in the city while the work is carried out? The novice can however ask himself if, beneath the surface similarity, there are more common points hidden deeper and if, finally, the use for IT systems of designs which come from the urbanism of towns corresponds to a real similarity at the substance level, and is not just a clever marketing simile. A development of the concept of the urbanism of the city is therefore necessary in order to show that the resemblance between the two fields is significant and that the lessons to be drawn for IT systems fully justify the use of this metaphor.

2.2 The parallel between urbanism of the city and that of IT systems 2.2.1 The Land Use Plan: a key element in urbanism One of the key elements in the urbanism of cities is the Land Use Plan (LUP). This is an urbanism document, generally on the scale of an urban district (occasionally a group of urban districts or a part of one), setting the general rules of use of land which are imposed on all.

14


The LUP is also the main element in the urbanism of IT systems. It is nearly exclusively on the scale of an enterprise or organisation, sometimes on the scale of a domain of the enterprise or organisation, even if from a theoretical point of view there is nothing to stop a LUP from being used for a group of enterprises or organisations. The LUP of the IT system of the enterprise or organisation sets the rules for use of space in the IT system which are imposed on all. The main purpose of LUPs is to precisely define the rights attached to each parcel and also to organise the urban fabric by defining the destination of the constructions, the densities and occasionally the applicable formulae, to localise the positions reserved for the amenities and to protect natural or agricultural spaces. The purpose of the LUP of an IT system is also to define, as accurately as possible, the services and responsibilities attached to each sub-set, and also to organise the IT system overall, by defining: • • •

the purpose and, as it were, the mission of the applications that make it up; the groups of software applications into coherent sets; the perimeters reserved for future software applications yet to be built, in particular, for transverse applications.

LUPs must be compatible with the orientations of the development plan and sector plan and, in the absence of such diagrams, with the spatial planning directives and, lacking this, with the development and urbanism laws. The LUP file must contain: • •

•

a presentation report comprising the exposition of motives, i.e. which gives an account of and justifies the options used; graphic drawings with the cadastral survey at the bottom of the plan, which accurately localises the zones in which the various rules respectively apply, the constraints and prescriptions or provisions from other documents which are applied to third parties; rules which must at least determine the main allocation of land per zone, specifying the principal usage that may be made of it and the type of activities which may be prohibited or subject to special conditions, and state the regulations pertaining to the installation of constructions in relation to roads, separation limits and other constructions;

The Metaphor of the City

•

15

appendices, which must at least contain the opinions of the people consulted, the list of locations reserved for public amenities (and their precise installation), the list of declared public utility operations, the sanitary facilities (water and drainage networks, waste disposal), the public utilities rights, and where necessary, the national development directives and the airport noise exposure plan, as well as the list of sites for which the urbanism rules have been used.

The IT system LUP must not only be compatible with but also aligned to the enterprise or organisation's strategy, and lacking a specific strategy, it must reflect the most likely scenarios for the development of business needs. The IT system LUP file must comprise: • •

• •

a presentation report summarising the structuring orientations and justifying the options used; a set of the cartographies (graphic drawings and associated annotations) showing precisely the different subdivisions of the IT system and showing which sub-set(s) of the IT system have an urbanism rule allocated; the urbanism rules and the definition of the mission and services of each zone, district and plot; and, of course, the LUP of an IT system also comprises a number of appendices such as interview reports, the list of people and entities involved and interviewed, as well as sundry other lists.

2.2.2 Breakdown of the city into sub-sets The main aspect of the LUP is zoning, for which the regulations state the rules and the graphical drawings accurately locate (by parcels). The following are distinguished: •

The urban zones, i.e. zones where the capacity of the existing public amenities or those in the course of being built allow for the immediate building of constructions. They are generally divided into several zones, for example, the town centre, predominantly residential zones, which may be diversified according to the authorised density, predominant activity zones, zones set aside for a specific activity (for example, port zones or zones for polluting, dangerous or enviromentally difficult industries).

16

•


Green zones, with amenities or otherwise, in which urbanisation is forbidden.

To this list must be added spaces reserved for public amenities, listed wooded areas (the LUP may classify them), zones reserved for family gardens in urban zones, and occasionally, additional zoning (e.g. sector to be protected) or special zones (camping, caravanning, skiing and ski-lifts). The breakdown of the IT system into sub-sets (zones, districts and plots) located graphically within the cartography is also a major aspect of the LUP. In the IT system, the following are distinguished: • •

•

• • •

the exchange zone, which manages all the acquisitions/restitutions of the IT system vis-a-vis its external environment; the data silo zone, which includes all the dynamic and perennial information of the enterprise as well as the access services to this data and stores and recovers the enterprise's data pool, guarantees its coherence and allows it to be added to over time; the reference zone for the enterprise's data, which groups together all the shared information common to the different elements of the IT system for which the life-cycle is relatively stable; the decision-making zone,which groups together the blocks dedicated to the processes for running the enterprise or organisation and analysis; the operations zones. In general, there is one operation zone per principal business of the enterprise or organisation; the resource zone, which groups together the systems dedicated to the management of the enterprise's internal resources (human resources, general accounting, etc.).

The urbanism of towns proposes firstly a breakdown into zones, then districts and finally plots. The district represents a fraction of the area of a town, which has its own physiognomy and is characterised by distinctive traits giving it a certain unity and an individuality. The differentiation factors, and thus the delimitation criteria of districts are varied:


• • • • • •

17

the configuration of the sites and the upper and lower district topography; central district and outlying districts; north and south district, etc.; the period of the first construction and the historical, architectural and urban characteristics that result; predominant typology of the buildings: private hotels district, low-rise district, large group of apartment buildings, etc.; the functions they are mainly used for are: business, administrative, trading, residential, etc. districts; the distribution of social or economic groups: middle-class district, workers district, etc.; the separation of ethnic groups in certain towns: European district, Jewish district, black district.

There is therefore no unequivocal and invariable definition of the district. But there is no choice but to accept that the concept of the district imposes itself, most often, as the result of the morphological differentiation, economic and social mechanisms that affect urban spaces as towns are developed. The IT system district is a part of a zone which itself is a part of the IT system. A district is a group of plots and groups together components that are uniform with regard to the nature of the information processed. A district will typically correspond to what is commonly known as a sub-system. The IT system district therefore, like the district in the city, has its own physiognomy and is characterised by distinctive traits that give it a certain unity and an individuality (weak coupling and strong coherence). Also as with the city, there is no absolute definition allowing a clear and scientific distinction of a district in the IT system. The plot is the smallest unit of the urban space, and is entirely demarcated by roads (often called "pates de maisons" in contemporary French, blocks in Anglo-Saxon and Germanic countries, and cuadras in South America, etc.). Under the plot are found parcels that correspond to individual entities (bare land, houses, residential buildings, etc.). In all cases, the group of parcels make up a continuous canvas without empty spaces. The parcel, the portion of space, is also a unit of ownership and, to this end, is linked to the concept of the land register.

18


The plot is also the smallest breakdown level of the IT system (in the context of the urbanisation project). It is a replaceable entity of the software system likely to be developed or purchased separately. A plot covers an " activity ", which corresponds to a functional purpose and includes the processing and accessing of data for this purpose. Processing within the plot is carried out independently from the route taken by the information upstream or downstream of the plot. A plot produces standardised results that can be used by other plots. A plot will typically correspond to: • •

a software application or a major software application function (specific development); a software package or a module of a software package.

Under 'plot', there are software applications which are atomic units and which must have an internal architecture, but this is the task of the architect and not the urbanist. 2.2.3 Urbanism rules An urbanism rule is a legal provision that appears in the LUP regulations, which state: • •

•

either a ban, e.g. a ban on building or dividing into plots; or rules or limitations pertaining to land use: these rules may in particular concern private roads, network service rules, land characteristics (surface area, frontage space) for constructions, installation of buildings on the parcel (distances in relation to roads and the boundaries of neighboring parcels), ground use rules (ground use coefficient which is the maximum part of the parcel's surface area that can be built on), maximum height of the buildings and even their external appearance (materials, colours, fencing); or an instruction, e.g. an obligation to provide a certain number of spaces for parking or planting.

In computing, an urbanism rule is a rule that must be respected and is given in the IT system's LUP: •

some are banning instructions. For example, it is forbidden to access a block without going through its plug-in;


• •

19

some are rules or limitations. For example, an item of data must be under the responsibility of one block and one block only; some are prescriptions. For example, every block must have a plug-in.

2.2.4 Procedure for drawing up the LUP The procedure for drawing up the LUP is a joint procedure between the community and State. This procedure, under the mayor's authority, comprises six stages: • • • • • •

deliberation by the town council prescribing the drafting of the LUP and determining the methods of association for public figures other than the State; mayoral decree establishing the methods of association; deliberation of town council ruling on the LUP project; mayoral decree making the LUP public; mayoral decree setting up a public inquiry; deliberation of town council to approve the LUP.

The procedure for drawing up an IT system's LUP is similar to that of the City's LUP and typically comprises the following stages: • • • • • •

drafting and distribution of a launch note; drafting of the study's quality assurance plan; carrying out of the study; validation of the LUP by the study steering committee; distribution; validation by the IT system management committee.

2.2.5 Monitoring respect for the LUP Monitoring respect for the city LUP essentially concerns two items, building and demolition licenses: • •

the building licence is the prior administrative authorisation required before a construction operation can commence; the demolition licence is the prior administrative authorisation required before a demolition operation can commence.

The same concepts are used to respect for the IT system LUP.

20


2.2.6 The infrastructure The infrastructure designates all the installations built on the ground or underground that allow human activities to be carried out using the space. These principally comprise: • • • •

the transport infrastructures: public road network and parking; railways and underground; rivers, canals and ports; airports, etc.; the hydraulic energy and communications layouts; the various networks (water, drainage, electricity, gas, telephone); the communal spaces (parks, gardens, cemeteries, sports grounds).

The following are distinguished: • • •

the primary infrastructures, which have a role for the whole town or region; the secondary infrastructures, which concern a district or operation; the tertiary infrastructures, which concern a housing group, amenities, activities company, etc.

The equivalent is the technological infrastructure of the IT system, which represents all the hardware and software installations produced to allow the software applications to automate the business processes to be carried out under conditions that satisfy the user. These principally comprise: • • •

the local or long-distance networks; the hardware platforms; the basic software (operating system, DBMS, middleware, etc.).

The following are distinguished: • • •

the primary technological infrastructures, which have a role for the whole IT system; the secondary technological infrastructures, which have a role for a zone or a few districts of the IT system; the tertiary technological infrastructures, which have a role for a plot, or even an IT system software application.


21

2.2.7 Businesses An urbanist is a specialist in urbanism (the science, art and/or technique of the spatial organisation of human establishments), i.e. the practice of town planning. An autonomous profession or a professional specialisation? This question is the subject of a debate that reflects the multiplicity of activities that come under the term 'urbanism' and the diversity of those who have attempted to define urbanism as a specific field. Urbanism involves many different skills and types of knowledge which compete for dominance. The architect works on a parcel while the urbanist works on the level of a city, zone, district or a plot. The architect is someone who sets out the plans for a building, makes an estimate for it and takes charge of its construction. This art, when used for buildings, can be extended to the building of towns or town districts. This is the urban architect. One of the most famous French urbanists was Baron Hausmann. Hausmann, one of Napoleon Ill's prefects, changed the Parisian space in order to adapt it to the needs of the industrial era, and this resulted in the appearance of Paris as we know it today. He hewed it from the much damaged original fabric. But he executed the first overall plan of Paris with contour lines. The first to do this, he dealt with the town as a whole, planning it as group of interconnected systems: traffic systems, green spaces and water and sewage systems. As with the city, there is very often confusion between the urbanist and the architect. For our part, we shall differentiate the urbanist, who designs and develops the IT system from a global point of view, and drafts the LUP and the architecture of the whole, from the architect, who draws up the plans for a building and thus works in the general framework set by the LUP on a plot or even a parcel. Having established this difference, confusion sometimes remains, essentially due to the lack of IT system urbanists, which leads to this role being played by others, notably architects.

22


2.2.8 A basic tool: cartography Cartography comprises all the studies and scientific, artistic and technical operations involved from the results of observations or use of specifications, with a view to the drafting and establishment of maps, plans and other models, as well as their use. This definition, established by the International Cartographic Association, highlights the three fundamental dimensions of cartography: •

•

•

cartography is scientific in its foundations (the study of the Earth's form, etc.), as with its methods (observing facts, analysis and use of digital data and so on), using old (geodesy, astronomy, etc.) and new (computers, remote-sensing, etc.) scientific methods; cartography has artistic content: in order to convey selected information, the map uses methods of representation (signs, symbols, colours, etc.), which when combined, contribute to the efficiency, the design being both a purpose in itself, but also a means for facilitating sending messages; cartography is technical in the processes that it uses: photogrammetric surveys, the use of photography (on the ground, aerial or satellite), measurements on the ground, drawing (drawing of the map) and notably printing.

Cartography is at the heart of the steps to be followed for an IT system urbanisation project. There are four types of cartography (business cartography, functional cartography, applications cartography and technical cartography, which will be explained later in this book) which can be used to describe the existing system and/or the target system. As with the city, the cartography of an IT system is: • • •

scientific: is it not based on a metamodel? artistic: it is also about communication and, from that, the aesthetic is also a means to facilitate communications. technical: its execution is based on a certain number of techniques, such as the plot files shown in Chapter 8.

Chapter 3

Concepts and rules

3.1 The basic principles Urbanisation allows for: •

• •

federating the building blocks of an existing IT system around a whole architecture and following principles which will allow it to acquire the flexibility and reactivity necessary for it to be adapted to the constraints of the market or the environment; managing the rapid and efficient taking into account by the thus "urbanised" IT system of critical development demands, using a rationalised approach; concentrating development efforts on the new high added value functions and reusing ,for the most part, the existing system.

Once this has been successfully completed, the IT system has the capacity to receive any new structure which meets the established urbanism rules. The modifications made to parts of the IT system will have an impact which is both predictable and controlled. The aim of an IT system urbanisation project is to organise the taking into account of major developmental requirements (which require a total or partial overhaul) on an IT system, while minimising the risks incurred and maximising the safety of the information pool. The urbanisation approach proposes moving from an existing IT system to a target IT system by successive stages corresponding to the various versions. This approach can be set against a more radical approach, which consists of replacing the existing IT system with another one and changing to an instant time t.

24


The urbanisation approach works in favour of risk control by introducing controllable stages into particularly complex contexts, where the level of complexity engenders a high risk. It should be noted that an urbanisation operation may present an overall theoretical financial cost greater than the total change approach. However, the cost is one thing and the financial statement is another. In fact, the financial statement is the difference between the investment and the return on the investment, and in the case of a progressive evolution trajectory, some return will be seen on the investment after each stage, even if the overall cost is higher than a single stage approach, so the financial statement is better. To this must be added risk control, which is better executed when progressing in successive stages. To successfully complete this operation, the approach is based on a reference framework with four IT system visions: • • • •

the business vision, with the business cartography which describes all the activities that the IT system has to support; the functional vision, which describes the functions of the IT system supporting the business processes; the applications vision, which describes all the applications elements of a software system; the technical vision, which describes all the hardware, basic software and technologies used.

These four visions are explained using their vocabulary and the concepts used on the perimeter to be urbanised. The urbanisation approach offers a generic model which can be adapted depending on the context. Here we will use the terms of the generic model to present the methodology. The applications vision is at the heart of the urbanisation operation. Indeed, the urbanisation process is based on the description of the existing software architecture to obtain a suggested future software architecture, as well as the stages that will allow for moving from one to the other. The generic model offers three levels for describing software architecture (classed from most important to least important): • • •

the zone; the district; the plot.

Concepts and Rules

25

A generic term designating any of these three levels is the block. The urbanisation operation will comprise "reorganising" a software system where the boundaries between the blocks are not effective, to make this software system modular and able to be developed. In order to do this, we are using two ideas inspired by object-orientated concepts: •

•

The concept of the macro-object: a block is the "owner" of its data and processes, which is to say that the internal structures of the data and processes that it contains are hidden from the other blocks. One block can only access the data encapsulated in another by calling upon the services that offer this. A block is, as it were, a macro-object, because, like an object (in the sense of object-orientated technology), it groups together both the data and the processing allowing it to be manipulated. The concept of strong coherence/weak logical coupling: this concerns defining blocks for which the data and processing show a strong coherence, i.e. a strong relationship (e.g. integrity constraints among the data) and a weak coupling, i.e. a boundary well marked with closely related blocks (e.g. the data in the "owner" block from those that have no association with the data of closely related blocks).

Using an "anarchic" software architecture, it is a matter of dissecting, adjusting and clarifying the layout of the blocks with the aim of producing strongly coherent and weakly coupled sets from the lowest level possible. The separation of the IT system into blocks has these characteristics, which allows for: • • •

limiting the need for maintenance in the event of changing the data structure; making unnecessary, vis-a-vis the IT system, any modification to the processing in a block; making a total or partial progressive overhaul of the IT system possible.

Ideally, an urbanised system has blocks with fairly large meshing, the boundaries of which are "impermeable", and which communicate between each other by exchanging messages.

26


The diagram below illustrates this principle:

Fig. 3.1 Communication between blocks

At the boundary of each block, exchanges with the outside are made by means of public interfaces called "plug-ins". A plug-in is the means made available to the outside world by a block to offer its services. These can be services for accessing the data of which it is the owner or processing which it can carry out (calculations, etc.). The aim of an urbanisation operation is to break down a software system into independent and hermetically sealed entities, each making a set of public services called interfaces or plug-ins available to the outside world.

Concepts and Rules

27

3.2 The metamodel and concepts 3.2.1 Introduction One of the fundamental activities of urbanisation projects consists of representing the various visions of the IT system in forms which allow them to be used (a database or a software engineering case tool for example). To do this, we offer a generic model of the concepts, which can of course be adapted to the context of each project. The models must allow for the representation of both the current IT system and the target IT system. The model describes the concepts used in the suggested methodological approach, as well as the links joining them. A definition of each model concept is offered with some of the main properties. 3.2.2 The metamodel The concepts metamodel is represented by the diagram on the next page:

28


Fig. 3.2 The concepts metamodel It is recommended to use logging and traceability mechanisms in models produced to represent the cartography. These ideas are not represented in the model for reasons of simplification. The logging consists of storing a copy of the modified or removed elements prior to making the modifications. The models used should not allow pure and simple deletions. All the removed elements, as well as all the successive versions of an element, should be stored in order to keep track of all the system's evolutions. Traceability consists of keeping track of the reasons that gave rise to the removal or modification of an element in the system. It can be a simple text zone.

Concepts and Rules

29

These information elements are very important because it often happens that, having lost track of the reasons why one solution was chosen rather than another, a lot of time is lost looking for the cause of a situation, and sometimes it leads to the study having to be carried out again. The same frame of reference can serve to store the representation of the future and current IT system. In this case, the properties indicating whether an object belongs to the old or new cartography must be added. 3.2.5 Definitions of the metamodel concepts The concepts given in the metamodel are defined below: Activity The activity is the functional breakdown unit of the business process. It corresponds to a functional module independent of the functions upstream or downstream and may be reusable. Examples (from the case study) of activities: • •

availability control; deposit demand.

Some properties of the concept: • • • • •

activity code; activity name; general description of the activity; description (references) of documents produced; documentary references.

Actor Actor is understood according to the UML (Unified Modelling Language) definition. It represents what exists outside the system and interacts with it. An actor may be a person or a machine. It carries out transactions with the system, and each sequence of transactions can be defined in a use case. An actor is different from a user: • •

a user is someone who actually uses the system; an actor is an external agent that represents something for the system.

30


Some properties of the concept:

• • •

actor code; actor name; text description.

Block A block designates one of three breakdown levels of the functional architecture or software architecture: the zone, district or plot. It is an individual and autonomous unit separate from the execution. A block is described by: • • •

a general descriptive text; the services it carries out; its basic principles.


block code; block name: block version; text description (objectives, services carried out, basic principles); documentary references.

Data This describes the data used in the current system and the target system. The description of the data for the current system may be used at the time of the impact analysis. The description of the future data will be made macroscopically at an early stage. It will include information as to the planned migration processes, the conversion rules to use, etc. Some properties of the concept: • • • • • •

data code; data name; data format; text description; type; range of values.

Concepts and Rules

31

Database This is a storage unit in a database management system, a set of tables. Some properties of the concept: • • • • •

database code; database name; DBMS name; DBMS version; database size.

District This groups together plots that are uniform with regard to the nature of the information processed. A district will typically correspond to what is commonly known as a subsystem. Examples (from the case study) of districts: • • •

management of payments; management of tariffs; management of tours.

Some properties of the concept: the district is a block, it therefore inherits the properties of the block. Event An event is a signal which can be recognised by a given actor and indicates that an act to which the data is attached has taken place. It has the following characteristics: • • • • •

it is something that happens at a given moment; it has no duration; it may precede or follow another event; it may be used by several blocks simultaneously; it gives rise to a data or material flow, the data flows being sent by messages from one block to another.

32


Some properties of the concept:

• • • • •

event code; event name; text description of the event; description of the conditions under which the event took place (appearance of date and time data, depending on the starting conditions); data carried by the event.

Flow A flow is an exchange of data between blocks. It may be continuous or triggered at certain times in the day (acounting for the night's account movements, etc.). A flow may be inside the system studied or come from or be going to an external system. There are material flows and data flows. Some properties of the concept: • flow code; • flow name; • text description; • list of exchanged data; • description of the method of transmission; • description of the triggering conditions; • external or internal flow signal; • volume andfrequencyinformation. Message The message is the method of moving a data flow associated with a management event between blocks. It can be sent synchronously or asynchronously. A flow (message) may be inside the studied system or come from or be going to an external system. Some properties of the concept: • • •

message code; message name; text description;

Concepts and Rules

• •

33

data carried by the message; internal or external flow signal.

Objective The enterprise or organisation's strategy is stated in the form of their objectives and sub-objectives. With the aim of traceability, the description of the objectives and subobjectives can be recorded in the business cartography. It should be checked that each of the objectives is covered by a process, and each process activity by one or more blocks. In this way it is possible to keep track of the requirements covered by each element of the applications cartography. Some properties of the concept: • • •

objective code; objective name; description of the objective.

Operation An operation is a stage in a procedure that corresponds to the intervention of an actor from the organisation in the context of the enterprise's activities. Once started, the operation can be executed without waiting for any event other than the triggering event. The operation cannot be interrupted. Physical Node A physical node is a physical machine with its software environment associated from the system point of view (operating system, system guides, network guides, compilers, etc.). Care should be taken with documenting the compatibilities between physical nodes to allow for verifying the feasibility of technical solutions used. Some properties of the concept: • • • •

node code; node name; general description of the node; technical characteristics.

34


Plot This is a replaceable entity of the IT system likely to be developed or purchased separately. A plot corresponds to a functional purpose and includes the processing and accessing of data for this purpose. A plot produces standardised results that can be used by other plots. A plot will typically correspond to: • •


Examples (from the case study) of plots: • • • •

approval of payment by instalments; invoicing; management of immediate payments; management of payment by instalments.

Some design properties: the plot is a block, it therefore inherits the properties of the block, to which can be added the editor if it is a software package or a component. Primary core business class A primary core business class is a class which includes the basic concept of a business design. The glossary allows the primary core business class to be located among the types of classes offered. Procedure A procedure is an "organised process", i.e. the organisational dimension (the "who does what") is introduced in relation to the process. A procedure is broken down into operations. Process A process is made up of a network of activities whose purpose is to process an initial management event. Its purpose is to produce the flow of results defined in the time and quality conditions set to meet the internal or external third party needs. It is independent from the organisation.

Concepts and Rules

35

Examples (from the case study) of processes: • • •

reservation; payment; invoicing.

Some properties of the concept: • • • •

process code; process name; text description; type of process.

Site A site is a geographic location considered from the point of view of one or more activities. Examples (from the case study) of sites: • •

Marseille branch; Paris head office.

Some features of the concept: • • •

site code; site name; site wording.

Site type A site type is characterised by a group of actors according to a reference structure and has geographic sites. Several site types can be located in the same geographic site. The concept of a site type concerns both the expression of the organisation and its geographic deployment. Examples (from the case study) of site types: • • •

main branch; branch; head office.

36


Some properties of the concept: • • •

site type code; site type name; wording of the site type.

Software block An executable software module that has an identity, offers services and has a well-defined plug-in. In the same way as the block that designates a zone, a district or a plot for the functional architecture, the software block can be an applications zone, district or plot, depending on whether it corresponds in terms of the granularity in a zone, district or plot. A software block is described by: • • • •

a general descriptive text; a text describing its objectives; the functions it carries out; its basic principles.


software block code; software block name; software block version; text description (objectives, services carried out, basic principles); documentary references.

Table This is a database table or a file. If a file contains different types of records, there will be an equal number of table descriptions. Some of the properties of the class: • • • •

table code; table name; text description; list of associated data.

Concepts and Rules

37

Zone This corresponds to the most basic breakdown level of the IT system and more often the highest level of the software organisation. A zone will typically correspond to what is commonly called a design and construction department or a system. Examples (from the case study) of zones: • • •

exchange zone; operation zone; reference zone.

Some properties of the concept: •

The zone is a block, it therefore inherits the properties of the block.

3.3 The different perspectives 3.3.1 The four levels of the reference framework The IT system can be defined as being the set of means used to store, process, generate and reproduce the information necessary for the proper running of an enterprise or organisation. The software system is one of the components of the IT system. In order to describe the IT system in the domains useful to an urbanisation approach, we will use a reference framework. This is a model of the enterprise centred around the IT system which allows for the formalisation of the representation of the set of components of any enterprise or organisation, particularly its IT system, as well as the connections between its components. It is structured according to four description levels: • • • •

the business architecture; the functional architecture; the software architecture; the technical architecture.

38


The diagram below illustrates these four description levels:

Fig. 3.3 The four description levels of reference framework

Business architecture This is the structuring of the IT system by the enterprise or organisation's business activities vis-a-vis its processes. The description of these activities can be made using business processes, if their description is available, or by means of the concepts used by the users concerned. Most often, the description of the activities is made within a hierarchy, which will be from a fairly large domain (e.g. client management) at the simplest level (e.g. "create a client") going through a varying number of intermediary levels. Functional architecture This is the structuring of the IT system into communicating functional blocks.

Concepts and Rules

39

The concepts of the functional and business architectures are linked. It is important, when doing the functional cartography, to show the links between the zones, districts and plots, and the business activities that they carry out (or will carry out in the case of designing the future IT system). This information will allow for measuring the impact of functional modifications and for repairing parts of the software applications which may be reusable. Software architecture This is the structuring of the IT system into communicating software blocks. This is the description and organisation of the software applications (data and processing) as well as the messages exchanged by these applications. The software architecture is described by the applications zones, districts and plots, as well as by the messages exchanged between these different elements. Technical architecture This is the structuring of the technical infrastructure means to be implemented to computerise the enterprise or organisation's activity. It is therefore the description and organisation of the various hardware means (CPU, server, position, etc), the basic software (operating systems, DBMS, etc) as well as the means of communication between them (networks). 3.3.2 The sequence for a future urbanisation A future urbanisation consists of designing a software architecture (zones, districts, plots software) supported by the adopted technical architecture (CPUs, servers, positions, networks) and which is coherent with the business architecture, which is itself aligned to the enterprise or organisation's strategy. The urbanisation design will be carried out using functional elements and bearing in mind the technical constraints. This sequence is illustrated by the diagram on the next page:

40


Fig. 3.4 Future urbanisation sequence

3.4 Urbanism rules Urbanism rules can be established for each of the four architecture visions. We will suggest them for the four visions of the reference framework. They are each broken down into: • •

urbanism rules; rules of good practice.

It should be noted that the rules at the functional architecture level are the most universal. The rules at software architecture level and above all the technical rules are much more subject to adaptation within each enterprise or organisation. Lastly, the urbanism rules at software architecture and/or technical architecture level are urbanism rules valid for the whole IT system. They cannot therefore be expected to replace, particularly in terms of exhaustiveness, the norms and standards of applications and technical architectures which must exist in each computer department and be applied for the construction of each building.

Concepts and Rules

41

3.4.1 Urbanism rules for modelling the strategy (Ishikawa diagram) Rule no. 1: Each objective appears only once in the diagram. Rule no. 2: If an objective is broken down into sub-objectives, the list of subobjectives must be exhaustive to achieve the objective. Rule no. 3: A more precise objective must be able to be associated with one or more realistic and significant KPIs (Key Performance Indicator). 3.4.2 Rules of good practice for modelling the strategy Rules of good practice for the Ishikawa diagram Rule no. 1: An objective starts with a verb. Rule no. 2: The wording of an objective does not include "and" which could obscure two objectives Rules of good practice for the enterprise diagram Rule no. 1: Use clarity and readability. Rule no. 2: Show, in the commentary that goes with the diagram, the flows between primary level processes which have not been shown on the diagram for reasons of readability. 3.4.3 Urbanism rules for the business architecture Rule no. 1: Any change in the properties of an object is an activity, even if it is simply the age of the object that changes, as in the case of protecting an object between two transactions linked to this object. But in a standardised diagram, an activity can only involve a single object, even if it is a composite object. Rule no. 2: A basic activity cannot be interrupted, which shows that once an actor is allocated to an activity, it cannot be re-allocated before it has finished executing its activity or the interruption of this for abnormal reasons. Rule no. 3: The end of the execution of an activity causes the simultaneous ending of the execution of all activities falling within the impact perimeter of this event, whether indirect or induced impacts.

42


Rule no. 4: Any activity may have an abnormal purpose, but also time or rejection events. Each of these events constitutes a particular event. 3.4.4 Rules of good practice for business architecture Rules of good practice for business processes cartography Rule no. 1: The operational processes and support processes are separate. Rule no. 2: Each operational process is represented by several symbols, each symbol corresponding toa sub-process which may itself be the subject of a process model. Rule no. 3: Each support process is represented by only one symbol so to avoid repetition in the diagram. Of course, if it were a study principally concerning the support processes, the opposite rule would be applied. Rules of good practice for processes Rule no. 1: A process stage corresponds to a type of transformation of an object expressed as its state. Rule no. 2: Any activity purpose generates an event which corresponds to the fact that the transformation has been completed or interrupted. Rule no. 3: The occurrence of an event carries within it the purpose of the transformation of other objects which are linked to the main object. This is true, either because there are multiple representations of the same actual fact (indirect impacts), or because the management rules involve the re-evaluation of other activities (induced impacts). An activity, object or event may however start the stage. All other impacts are indirect or induced by this main event, because the activity involves several objects. Rule no. 4: An event may be activated by several triggered events, at least one for each object concerned. Rule no. 5: Each triggering is associated with a decision which may drive one activity or another. Rule no. 6: One activity may need one or more triggerings if some activities have to be synchronised.

Concepts and Rules

43

3.4.5 Urbanism rules for the functional architecture Rule no. 1: Block uniqueness rule. A plot belongs to a single district, a district belongs to a single zone, therefore a plot belongs to a single zone. At functional architecture level, a block must therefore not be duplicated. Rule no. 2: Rule for asynchronism of plots. After having processed an event, a plot can immediately process another without having to be concerned about what happens with the processing report of the previous event. Rule no. 3: A block must have a plug-in (external interface). It is able to activate the services of the block and to manage the block's incoming and outgoing communications. Rule no. 4: Any of the block's incoming or outgoing communications go through its plug-in. These plug-ins offer the following advantages: • •

•

• •

•

they centralise the service calls and limit the number of interfaces; add an additional level of encapsulation: the inner block is considered as being a black box by the outside; in object development, a class already shows the first level of encapsulation, the principle is to take this to the upper level plots, districts and zones; mutualise the services: a single public service to respond to similar needs formulated by the various callers belonging, where appropriate, to distinct blocks, districts or zones; this also shows the principle of reuse; increase modularity; reduce to a strict minimum the impact following the development of a plot whose public services are requested by a variety of callers and make it easier to determine the impact chain; facilitate the implementation of progressive maintenance.

Rule no. 5: Only plug-ins communicate with the message manager. Plug-ins are only allowed to communicate with the message manager.

44


Rule no. 6: An item of data is the responsibility (whatever the type of access: creation, modification, deletion, display) of a single plot alone. One of the objectives of urbanism is the portability of the plots while respecting the rules of autonomy and asynchronism. In order to achieve this objective, it is necessary to have data structures aligned to the plots, because the adding, replacement or removal of a plot can take place with minimum impact on the IT system. 3.4.6 Rules of good practice for functional architecture Rule no 1: All functional architecture has an exchange zone (acquisition/ restitution) which is in a manner of speaking the IT system plug-in. The acquisition transforms external organisational flow events into functional flows carrying all the information necessary for their processing downstream by the function concerned. It also guarantees the conformity of the enriched functional flow with the undertakings made to the sender partner and with the conditions of execution determined by the enterprise. The restitution adapts the results from the composition function to the information supports and communications channels, and customises the emission flow according to the partner and channel. Rule no. 2: All functional architecture has a data silo zone. This zone holds all the enterprise's dynamic and perennial information, as well as the access services to this data. It stores and uses the enterprise's data pool, guarantees its coherence and allows for its future enrichment. Rule no. 3: All functional architecture has a data reference zone. This zone groups together all the information common to the different elements of the IT system for which the life-cycle is relatively stable. A frame of reference contains the reference data concerning the products and services, administrative and accounts management rules of the company, its business and its organisation apart from private clients and access services to this data.

Concepts and Rules

45

Rule no. 4: All functional architecture has a unique decision-making zone. This zone groups together blocks dedicated to control and analysis processes which use aggregated and recorded information. Rule no. 5: All functional architecture has one operation zone (or an IT system) per main business of the enterprise. All functional architecture has one operation zone per principal business of the enterprise or organisation; The IT system of an enterprise or organisation that has only one business therefore has only one operation zone. In contrast, if the enterprise or organisation has several lines of business, the IT system must have an operation zone for each of them. For example, the IT system of a company operating in the P & C (Property & Casualty) insurance, life assurance and banking domain will have a P & C operation zone, a Life operation zone and a Bank operation zone. Rule no. 6: All functional architecture has a unique resources zone (or IT system). This zone groups together the systems dedicated to the management of the enterprise's internal resources (human resources, general accounting, etc.). 3.4.7 Urbanism rules for the software architecture Rule no. 1: The data in data silos must be recorded. The shared data must be recorded in order to allow it to "replay" a process if necessary and guarantee the coherence of the content and its performance. Rule no. 2: The data in data silos must have an update publication date. The data in data silos must have an update publication date so that the old values are not lost and their values can be quickly found. Very old values can be exported to archived data management modules. Rule no. 3: Reference data must have an update publication date (as with the data in data silos) but also an effective date.

46


In order to allow for time versions, the data silo reference data must include: •

•

an update publication date so that the old values are not lost and their values can be quickly found. Very old values can be exported to archived data management modules; with an effective date.

Rule no. 4: Duplication of data. Within a block, the data can be duplicated between the context data and the data in data silos as this corresponds to two shared levels and very different life cycles. In fact, the data is isolated and temporary for the context while it is shared and permanent for data silos. The data silo level must remain in control. Synchronisation within a block is done by publication of the context while respecting the integrity rule of the data silos (urbanism rule for the technical architecture). Rule no. 5: A block that offers a service is the service quality manager. This is a service-offering block that must check that it offers the best quality of service, including continuity of service. 3.4.8 Rules of good practice for software architecture Rule no. 1: All software architecture has a management zone (scheduling) which provides the interface between the front office, back office and middle office. More specifically, this zone: •

• •

translates, schedules and manages requests from the front office. A service request from the front office is expressed as a set of services called in a certain order at middle office and back office level; manages the internal processes of the IT system; manages priorities.

3.4.9 Urbanism rules for the technical architecture Rule no. 1: Transactional integrity of sensitive flows.

Concepts and Rules

47

In order to ensure the transactional integrity of sensitive flows (i.e. financially and/or legally committing the company), communications between all the systems concerned must be synchronous during the data silo update storage phase. This is in fact the only case where synchronous communications are compulsory. Rule no. 2: Integrity of the data silos. Any updating of data silos and any outward sending of critical flows must respect the following principles: • • • •

isolation in one context during the transaction; atomicity (all or nothing) of the update of the data context in the data silos and in the sending of flows; coherence at all times of data silos; durable nature (not automatically reversible) of the publication if it succeeds.

Rule no. 3: Batch/Transactional Processing competition. The batches must be constructed so as to be executed in such a way as to compete with Transactional Processing processes under the control of transactions with respect to the integrity rule for data silos. Rule no. 4: Single source. Software components that do not need any variation, for reasons linked to their category, must only be written once. The possibility or obligation to use them on different technological platforms in no way justifies a multiplicity of sources. 3.4.10 Rules of good practice for technical architecture Rule no. 1: Centralisation of the data silos. Data silos must be centralised, i.e they must be located on a central platform, which is secure and accessible from any other platform.


Part II

Illustration of the approach: the tour operator


Chapter 4

The case study

4.1 Introduction Each of Chapters 5 to 8 include a describtion of the "how to" using a case study corresponding to the various phases of the urbanisation approach to IT systems described in Chapter 9 (i.e. the "what to do"). The aim of Chapter 4 isto present this fictitious case study for illustrative purposes. The phases and activities of the IT system urbanisation project approach are not all involved: the only ones selected are those useful or necessary to support the example given. Similarly, in comparison with the use of the methodological framework in a real project, most of what is required to be delivered is not as complete or exhaustive as it ought to be. However, the basic elements are given, and they are accompanied by explanations to make it easier to understand them. The subject deals with a tour operator that offers its clients several types of tours throughout the world. The study concerns the management of the company, and in particular, the reservations for one or more journeys.

4.2 The tour operator The current organisation of the tour operator is illustrated by the diagram on the next page:

52


Fig. 4.1 Organisational structure of tour operator

The organisation of the tour operator revolves around the following departments, attached to the head office run by the CEO and managers of each of the following: • • • • • •

finance department; organisation department; marketing department; commercial department; operations department; human resources department.

Finally, the organisation includes the IT department, attached to the finance department, with its departmental head.

The Case Study

53

The commercial department is organised around a network of exclusive travel agencies. There are 211 agencies distributed around the world (about twenty countries). They do not offer products marketed by other tour operators. There are on average about ten agencies per country concerned, one of which is the main agency. The organisation department is responsible for coming up with and organising each tour, and shows all these tours in a brochure. The tours are only sold to clients through agencies that make up the commercial department. The finance department is responsible for all the company's accounting, presents and manages payments by instalments should clients not wish to pay immediately. The marketing department is responsible for carrying out any promotional operations with the media (press, radio, etc.) and the publication of a brochure. In order to simplify this case study, the holiday-village and/or hotel management section (which is the responsibility of the operations department) will be excluded from the perimeter.

4.3 General presentation of the tours Tours are organised throughout the world. There are three types of destination: the sea, mountains and tourist towns. In the latter case, what is being considered are large towns or famous towns, located close to the sea or mountains. At each location, three types of accommodation are on offer: hotel, bungalow or apartment. Clearly, not all kinds of accommodation are available at every location (it is a little difficult to find bungalows in New York!). All the tours offer several activities. The current list of activities available at a given location is limited to all or some of the following activities: swimming, diving, tennis, golf, sailing, water-skiing, climbing, freefall parachuting, skiing and cross-country cycling. The organisation department may decide to add to this list. The length of a tour is set at one week . the whole week in the same place, in the same accommodation. A customer who wants to stay longer can, of course, reserve several weeks, but the price stays the same anyway!

54


The price includes the journey from a given departure point (which can be an airport, a railroad station or a bus station) to the location of the accommodation (transport included), the rental price, free activities offered and, at the end of the holiday, the return journey, from the accommodation back to the starting point. The prices, given in Euros, are adjusted and set for four periods (one per season: winter, spring, summer, fall). There is a reference price from which the actual price of each tour is calculated (one tour = one week for one person). A customer may ask to pay for his trip immediately or to pay by instalments.

4.4 The organisation department The organisation department has two responsibilities: • •

the management in real time of the tours: accommodation available, current state of the reservations, taking reservation bookings, etc.; the general organisation of a tour: creation of a tour, choice of accommodation, organisation of activities, etc., and, similarly, all the points of negotiation, such as the price to set with the airline companies, hotels, etc.

Each travel agency receives a fax from the marketing department every day showing the number of places available for each tour, which lets the sales staff know which destinations are still free when talking with a customer. The department has a central software system and a fairly large "telephone switchboard", comprising 80 people (for an annual cost in human resources of 5 million Euros). These people are able to answer questions from all the agencies, for example, the number of places available with regard to accommodation for a trip offered on a given date, etc. They are also responsible for pre-reservation requests from the travel agencies (provisional reservation: allocation of a pre-reservation reference number), which involves updating reservation status and the management of available places. The information necessary for recording a pre-reservation is the basic information, namely the identification number of the agency making the request, the holiday and location identification number (accommodation reference). All the information relating to the tour reservation is managed by the finance department (customer identification number, method of payment,

The Case Study

55

etc.). The organisation department receives the order allowing it to proceed with a final reservation from the finance department. All the holidays are described in a brochure published by the marketing department, in accordance with the information sent by the organisation department. The organisation department submits any proposals aiming to improve the current tour structure to the head office: • •

adding new countries to the brochure; new sites in the existing countries.

The organisation department applies the decisions made by the head office.

4.5 The marketing department Twice a year, the marketing department publishes a brochure showing the current tours. This brochure is sent to each travel agency and to customers whose addresses are known by the tour operator's head office. The brochure offers an attractive description and some photographs of each of the tours, shows the destinations, the accommodation and the activities offered. A supplement showing the prices is published each quarter. The brochure and the price leaflet may be distributed to customers or used by the sales staff at the travel agency. Depending on the information sent by the organisation department, the marketing department keeps or gets rid of the brochure as it is. For example, it may revise the description of a tour, replace a photograph with another more attractive one, add rooms to a given location, organise new activities there, etc.

4.6 The finance department Apart from the payment of employees, the finance department manages all financial flows, and in particular, payments made by customers.

56


This department already has a software system to process its operations, but it is not connected to the organisation department's system. The finance department also has a blacklist of "bad payers", in other words, of customers who have had, on several occasions, problems with payment or who have not fully paid for their previous holidays. This department is responsible for all the financial aspects of a tour: • •

approval of deferred payments and any similar payments; management of immediate payments.

In the event of a request for payment by instalments, an application form is sent by the travel agency, providing all the required information: customer identification number, description of pre-registration references, price, etc. Then the finance department checks the blacklist. If the customer fulfils the conditions, the payment by instalments is approved and the information is sent to the organisation department in order to proceed with the final reservation of the holiday. The finance department has a maximum of eight days to give its response, either to the travel agency, or directly to the customer, as to whether it has approved or declined the application. Payment by instalments takes place over six months, however much the tour costs. This amount represents the real price of the holiday, less the deposit. Repayments begin at the end of the tour. Each payment (immediate or by instalments) has a due date. In the case of an immediate payment, there are two key dates: • •

payment of the deposit for any pre-reservation; payment of the balance on a final reservation eight days at the latest after paying the deposit.

In the case of payment by instalments, there are seven due dates: • •

the first when paying the deposit; the next six by monthly payment, as from the month following the end of the holiday.

The Case Study

57

For each due date, an invoice is sent to the customer. As for the deposit, this is up to the travel agency (immediate drafting of the invoice). In this case, the reservation form also serves as the invoice. For all other due dates, the finance department sends the invoice directly to the customer. A deposit is taken by a travel agency; any other type of payment is dealt with by the finance department (payment sent by the customer to the company head office, to the finance department). The deposit is at least 10% of the price of the tour. If the customer asks to make payment by instalments but does not meet the conditions for this, his request is turned down and he has no other solution but to pay the price in full (settlement). In the event of a refusal, the deposit is paid back to the customer, less the application fee (2% of the price of the tour), and the pre-reservation is cancelled (the corresponding information is sent to the organisation department). The same rule applies to an immediate payment: if the customer pays immediately (the deposit) but does not settle the balance within eight days as from the payment of the deposit, the deposit is returned to the customer, less the application fee (2% of the price of the tour), and the pre-reservation is cancelled (the corresponding information is sent to the organisation department). The finance department is responsible for reimbursing customers.

4.7 The travel agency A salesperson helps a customer to chose their tour, by consulting the brochure and taking into account several parameters, such as the country, the season, choice of destination, type of accommodation, level of comfort, number of people, price, etc. Once the customer has chosen a tour, he may ask for a quote and/or a prereservation (provisional reservation). To make a pre-reservation, the salesperson must telephone the organisation department to confirm the availability of the tourt requested, then make a pre-reservation. This is recorded when the customer pays the deposit. The reservation becomes final when the customer pays the full amount due. The customer may ask to pay for his holiday immediately or to pay by instalments In the first instance, he first of all pays a deposit (at least 10% of the total price) and pays the balance within eight days, or the reservation will be cancelled. The final reservation is only made after payment of the full amount.

58


If a customer chooses to ask to make payment by instalments, the salesperson must open the corresponding application and ask the customer for certain information (address, profession, copies of his latest pay slips, etc.). After the customer has paid the deposit, the salesperson sends the application (by post) to the finance department. The latter immediately sends its response back to the travel agency and the customer, saying whether an application has been approved or declined. In all cases, the customer pays the deposit directly to the travel agency, but must send (himself) the balance or any other payment to the finance department located at the company's head office. Deposits can be paid using any payment method, i.e. cash payment, by check or credit card. But all other payments are always made by cheque. A deposit is always paid to the agency; all other payments are always made to the finance department. A reservation form is given to the customer when the deposit is paid and also serves as an invoice. The 211 agencies distributed in the 22 countries concerned are broken down into 22 main agencies (one per country) and 189 small agencies. These main agencies have computer skills, but the small agencies do not. The manager of the main agency in each country carries out statistical studies on the sales in his country which he regularly sends to the central finance department, for example, once a week. The opening times of the agencie are 9 a.m./12 noon.-2 p.m./7 p.m. with an activity point between 6 and 7 p.m. at 20% compared to the other hours of the day. The time spent by the salesperson on each customer varies between twenty minutes and half an hour. On average, 42 customer requests are dealt with per day at the main agency.

4.8 Financial results In France, the tour operator is one of the main actors in its sector of activity. It has been the market leader for the last two years, but is now in second place and is continuing to lose its market share. The financial results are summarised on the next page.

The Case Study

59

Table 4.1 Financial results of tour operation 1995 183

1996 213

1997 259

1998 297

1999 300

2000 305

No. of reservations (in thousands)

390

468

565

643

650

660

Profit before tax (in millions of Euros)

36

43

51.5

60

60

59

Turnover (in millions of Euros)

The CEO was asked for his views on the main problems as to the current reservation system. He gave us his thoughts on the matter: "At the moment, 68% of customers who go into one of our agencies make a reservation. This rate of turning contacts into reservations is too low, particularly when compared to the competition. About 8% of reservation requests we receive cannot be met because we have run out of places on the tour requested. We could reduce this rate if we knew in real time which tours had not been booked, because in this case, we would be in a position to guide the choice of a customer towards an available tour. The impact of reducing this rate would have a significant effect, because we know that, if the first request cannot be satisfied, there is a 20% probability that the customers will leave the agency without making another request. At the agency, the salesperson is submerged by administrative tasks (sending and receiving faxes and letters), which creates queues in all our sales offices. This waiting causes us to lose many sales because some customers do not like waiting at all. A salesperson has to call the switchboard of our organisation department in order to find out about the availability of tours in the brochure and proceed with the reservation. This means that the agencies are dependent on the opening hours and days of the central switchboard. Greater flexibility is needed, which will allow the agencies to choose their opening hours and days according to local culture and needs. Some costs are probably too high, like telecommunications costs.

60


It would be possible to improve our image by offering, as some of our competitors do, Internet access to our brochure. We must also, while maintaining our network of exclusive agencies, which is and will probably remain in the long term our main distribution channel, open new distribution channel and have our products sold by third parties. We must also improve our profitability by selling additional third-party products in our agencies. Finally, we can improve our cash flow if we speed up invoicing."

4.9 Construction of the methodological solution The elements given here pertain to the adoption of the standard methodological approach (as shown in Chapter 9) in the context and objectives of the tour operator's IT system urbanisation project. These elements will typically make up the substance of the project's quality assurance plan. 4.9.1 The stages of the approach and the choice of life cycle The stages of the approach The approach used in the case of the tour operator is illustrated in Fig. 4.2.

The Case Study

61

Fig. 4.2 The tour operator's approach to designing the target IT system and roadmap

All the phases proposed in the standard approach are given in the work plan, except the strategy update phase as this is repeated regularly, but only in the implementation phase of the urbanism plan. In the case of our tour operator, it is a matter of running a study which allows for the definition in less than twenty weeks, of the target and the associated convergence trajectory; the updating of the strategy cannot therefore be carried out during the study. Finally, even if it does not appear on the diagram above, which is limited to phases, the operational procedures, expertise, current and targeted skills of the IT systems department have been excluded from the perimeter of the study as they are the subject of a specific project which takes place in parallel.

62


Certain parallelisms should be noted, and in particular: • •

•

the current enterprise architecture analysis starts before the end of the business strategy gatherings; the enterprise architecture definition starts in parallel with the current enterprise architecture analysis, because, in the case that concerns us, the approach consists of coming up with, at least in the first place, an ideal target. It is better therefore not to wait for the end of the current enterprise architecture analysis so as not to restrict thinking; the migration plan design can start in parallel with the latest iteration on the target.

Choice of the life cycle adapted The life cycle is overall sequential (even though many parallelisms have been introduced in the planning), with the exception of the enterprise architecture definition phase, which is carried out repeatedly. This option allows for the rapid: • •

development of a first target vision and to compare it critically; familiarisation of all the participants with a methodological approach and occasionally a way of thinking up the until then unknown.

4.9.2 Deliverables The major choice in terms of deliverables is the choice of existing and future cartography to be produced in the context of the study. Fig. 4.3 illustrates the choices made in our case study.

The Case Study

63

Fig. 4.3 Choosing deliverables in case study In fact, only the technical cartography (existing and future) has been removed from the study work plan, because there is a current reliable technical cartography, and the target technological infrastructures studies have already been started. The project will therefore provide its conclusions to these studies, which are needed anyway to complete them. Finally, bearing in mind the objectives of the tour operator's urbanisation project, the choice of deliverables to be included in the work plan has been made and is shown in the following table in which the deliverables used are in grey characters. The characters which are both grey and in italics are in the study work plan, but there are no examples of this in this book (it is, for example, the case in the Quality Assurance Plan - QAP).

64


Table 4.2 Choices of deliverables in case study Phase/Activity PLANNING THE STUDY

Finished products QAP Launch note Procedures Operational tools

BUSINESS STRATEGY GATHERING

Model of strategic business objectives Note on the strategic business direction Diagram of the future enterprise Model of the IT system strategic objectives Note on the IT system strategic objectives Business objectives/IT system objectives traceability matrix Diagram of the target enterprise

Understanding the enterprise business strategy

Model of strategic business objectives Note on the business direction requirements Diagram of the target enterprise

Future business vision definition

CURRENT ENTERPRISE ARCHITECTURE ANALYSIS

Current cartographies

Model of the IT system strategic objectives Note on the IT system strategic objectives Business objectives/IT system objectives traceability matrix Existing business cartography Existing software cartography Existing technical cartography Current operational procedures in the IT department List of current skills and expertise in the IT department Current status evaluation Note on technological opportunities Main direction of the IT system strategy Urbanism rules Existing business cartography Existing software cartography Existing technical cartography Current operational procedures in the IT department List of current skills and expertise in the IT dept

The Case Study Phase/Activity

Finished products

Current status evaluation


Technological opportunity analysis

Note on technological opportunities

Strategic intent and directions definition

Main direction of the IT system strategy Urbanism rules

STRATEGY DESIGN

Land use plan

Performance forecast

Organisation design

Evaluation of scenarios and choices

Target business cartography Target functional cartography Target software cartography Target technical cartography Target operational procedures in the IT department List of target skills and expertise in the IT department Outline of the migration plan design Table for the comparison of urbanisation scenarios Note on choosing an urbanisation scenario Target business cartography Target functional cartography Target software cartography Target technical cartography Outline of the migration plan design Table for the comparison of urbanisation scenarios Performance evaluation report Target operational procedures in the IT department List of target skills and expertise in the IT department Table for the comparison of scenarios Note on choosing an urbanisation scenario

65

66


Phase/Activity

Finished products

MIGRATION PLAN DESIGN

Urbanisation operation plan Note on the organisation of the urbanism pole Definition of the indicators Production procedure for indicators Procedure for updating the IT system frame of reference

Migration plan completion

Urbanisation operation plan

Monitoring strategy design

Note on the organisation of the urbanism pole Definition of the indicators Production procedure for indicators Procedure for updating the IT system frame of reference

PUBLICATION OF THE STRATEGY

Summary file for the IT system strategy

4.9.3 The project's actors and authority The actors For this project, the main actors are: • • • •

• • • • •

the head of the study; the head of the study project; the study team, including urbanists and business experts; the design and construction teams: these are teams in charge of IT systems design and construction. These teams apply their knowledge to what exists and their vision of the plan of action to migrate towards the target. They are also very useful in testing the target; the quality manager; the sponsor of the study: head of the management committee in charge of promoting the advancement of the urbanisation study. In the case of the tour operator, this is the commercial director; the users; the IT systems departmental head; all the business departments (financial, organisation, marketing, commercial, operations and human resources).

The Case Study

67

The authorities The authorities include those whose life time is limited to the duration of the study, while others have a limitless life. Perennial authority • The enterprise's management committee: this is the highest authority to orient work pertaining to the development and evolution of the tour operator. It comprises the Director General and his seven directors. • The IT system management committee: this is the highest authority to orientate work pertaining to the development and evolution of the IT system. It meets at the key stages of the study, then a quarterly basis is generally appropriate. It is the committee that approves the general direction of a technical, functional and financial nature (development plan - computer layout), distributes the budget by management domain, promotes and coordinates the options used in the enterprise at the highest level. It decides on the updates of the urbanism plan and migration plan design. The IT system's management committee is made up of the Director General or one of his representatives, the director of IT systems and business directors or their representatives. Non-perennial authority (whose life time is the same as that of the project) • The study steering committee: its responsibilities are as follows: - to have a launch note validated by the head office, then distribute it; - provide all the guidance needed by the study team for a successful conclusion to its mission, respecting the forecast schedule; - resolve difficulties, where they occur, that are linked to the availability of resources; -ensure high level arbitrage; - validate the deliverables. The committee is chaired by the sponsor of the study. A steering committee is provided for the study plan for each key phase of the study: - business strategy gathering; - current enterprise architecture analysis and repetition 1 of the enterprise architecture definition; - enterprise architecture definition repetition 2; - migration plan design and repetition 3 of the enterprise architecture definition. The end of the study is validated by the steering committee and confirmed by the IT system's management committee.

68

•


The study steering committee: its responsibilities are as follows: - to take stock of the difficulties encountered; - to manage the action plans needed to resolve these difficulties; - to determine the appropriate solutions and possibly inform the steering committee if it considers it to be necessary; - to organise the steering committees. This committee meets frequently (generally on a weekly basis) but for deliberately short times (typically one hour maximum). It defines the actions to be implemented to deal with the difficulties encountered and monitor their progress, but does not deal with basic problems. It is made up of the study director, the head of the study project, key personnel from the study team, design and construction manager and the study quality manager. Other people may join the committee, but on an occasional basis, depending on the circumstances.

The urbanism pole A new structure, the urbanism pole, will come into being at the end of the study and will play a considerable role in the implementation of the urbanism plan. The urbanism pole keeps the IT system in the established trajectory, and is responsible for the following: • • • • • •

investigation of building licence applications; conformity control of systems delivered in relation to the building licence; maintaining the IT system frame of reference; production of procedural documents; advice following the project managers and owners; updating the urbanism rules.

Chapter 5

Urbanism and strategy

This chapter describes the "how to" for the business strategy gathering phase of the methodological approach to the urbanisation of an IT system.

5.1 Harnessing the strategy This is a matter of putting the IT system urbanisation project in the general context of the enterprise or organisation's strategy in such a way as to define a target for the IT system which is in phase with the business processes, which themselves are in phase with the enterprise's strategy. The gathering and comprehension of the strategy are therefore essential upstream from any IT system urbanisation approach. An enterprise or organisation may be regarded as following a top down approach as shown in Fig. 5.1.

70


Fig. 5.1 Scope of IT urbanisation

So the enterprise or organisation is visualised according to five complementary points of view: • • • •

the mission, which is in fact the reason for its being an enterprise or organisation; the vision, comprising all the high level objectives of the enterprise or organisation; the strategy, which is the means for carrying out the vision and which is expressed by a set of strategic objectives and sub-objectives; the IT system, which includes: - the business processes which support the strategic objectives, - the software system which implements the business processes.

Urbanisation, and consequently, the practical approach proposed does not include a method to determine the enterprise's mission, vision or strategy. These are considered as being defined and are used as they are. The strategy is modelled by a hierarchy of objectives which are broken down into sub-objectives. The breaking down of the objectives into sub-objectives is stopped when all the objectives can be achieved by at least one process.

Urbanism and Strategy

71

IT systems urbanisation projects have their origins in strategic decisions taken by the enterprise or organisation. The activity of comprehension of the enterprise's strategy is intended to define a reference framework common to the enterprise's managerial staff, IT managers and the team responsible for the urbanisation study of the general enterprise or organisation's strategy. This is a matter of showing the strategic choices most constructive for the IT system. This activity allows for the understanding and validation of the various strategic orientations of the IT system, taking into account: • • •

the point of view of the IT department; the point of view of the departmental heads; the point of view of the users.

Using this shared framework, the team responsible for the urbanisation can clearly define the limits of using urbanisation. Once the limits of the scope of the study are defined and shared among the actors, the team responsible for the urbanisation will establish, along the broad lines of the first conclusions, that it can find the enterprise or organisation's strategy in terms of developing the IT system. More specifically, the objectives of the harnessing of the strategy are as follows: • • • • • • •

to take in and understand the general policy and enterprise or organisation's strategy; to provide the study team with a deeper understanding of the enterprise's choices and directions; to get the management to formalise and/or specify default choices; make the IT managers aware of the strategic stakes of the enterprise; evaluate their consequences in the short, medium and long term at the level of its IT system and software system; explain the short, medium and long term vision of the IT systems development; find out about any major malfunctions in the current situation.

During this phase of the approach, the management and the IT managers must explain through discussions, meetings or documents that are already available, the main principles under which the study is taking place.

72


The enterprise or organisation's strategy has short, medium or long term consequences on the IT system and software system. So it is desirable to keep the distinction between each group of impacts. This classification will be used when establishing the hierarchy of updates and the scheduling of the implementation of the urbanisation. In this phase, development requirements independent from the strategy will be shown, which arise from external constraints, like, for example, changes in the regulations of the business studied (new liability to VAT, loss of bonus/penalty for automobiles insurance etc). The management must be involved in the approach. It must at least formally approve the documents produced.

5.2 Modelling the strategy The objectives diagram is based on the Ishikawa diagram. This shows causes and their effects. The first element is a central arrow corresponding to the main effect looked for, while the causes engendering this effect are represented by arrows pointing towards the central axis (arrow indicating main effect). The arrow indicating the cause is in its turn considered as being an effect to be achieved, and the causes bringing about this effect are represented by arrows pointing towards this arrow of cause/effect, etc. Here we are using the Ishikawa diagram to model the enterprise's strategy, expressed in the form of main objectives and sub-objectives. 5.2.1 Presentation In this activity, the following actions should be taken: • • •

analysis of the available documents showing the enterprise's strategy; preparation of a discussions guide; holding of discussions. Discussions are held with: - management (strategic vision), - IT structures (methods, costs etc) managers, - user managers (vision with regard to service provided etc); • analysis of discussions; • consolidation of results; • first classification and establishment of requirements hierarchy.


73

The summary document drawn up after this task must include responses to the following matters: • • • •

what are the business developments planned? what developments are there in terms of IT services (specific software applications development, user support)? what are the quality objectives (delivery time for a piece of software, zero defects, etc.)? what are the lines of development envisaged for the technical infrastructure (new development tools and methods, new technical architecture, etc.)?

If the profession supported by the IT system has "on-site" restrictions (regulations linked to the business), an enquiry must be made to the governing bodies and the planned developments must be identified for the coming years. These improvements, which are sometimes major, may cause major structural modifications within the IT system. Any external restrictions not directly linked to the strategy but that must be taken into account must be learned of. The development requirements will be classified by order of priority. In particular, the development requirements in terms of performance of the key management events are made clear. If possible, a macroscopic estimate of the work load incurred is made. If any logical constraints are identified, they must be recorded. 5.2.2 The objectives model Objectives of the objectives model An objectives model is used at the start of a process reconfiguration project. Its purpose is to model the enterprise or organisation's strategy, which is supposed to constitute a starting element for the methodology. The description of the objectives is the natural complement of the objectives diagram. It generally comprises a few pages of text description.

74


Urbanism rules for an objectives diagram Rule no. 1: Each objective appears only once in the diagram. Rule no. 2: If an objective is broken down into sub-objectives, the list of subobjectives must be exhaustive to achieve the objective. Rule no. 3: A more precise objective must be able to be associated with one or more realistic and significant KPIs (Key Performance Indicator). Graphic representation of the objectives model

Fig. 5.2 Graphic representation of objectives model - Ishikawa diagram

Rules of good practice for an objectives diagram Rule no. 1: An objective starts with a verb. Rule no. 2: The wording of an objective does not include "and" which could obscure two objectives.


75

There are several ways of modelling the main and intermediary objectives of an enterprise or organisation. We suggest the Ishikawa diagram because it is both visual and synthetic (generally any model fits on an A4 format page), and both these characteristics make an excellent tool for presenting and communicating a strategy. Nevertheless, other representations can be just as acceptable. 5.2.3 The enterprise diagram Graphic representation of the enterprise diagram

Fig. 5.3 Graphic representation of enterprise diagram - Ishikawa

Objectives of the enterprise diagram The enterprise diagram is an "aerial" view of the enterprise showing the various functional entities that make up the organisation (sales and trade, administration and finance, production and logistics, technology and research monitoring, marketing) and details the activities and information flows exchanged between these entities. A summary of customers and suppliers is also shown in this diagram, as well as partners; exhaustiveness is

76


not necessarily the objective sought, but rather clarity and comprehension "at first glance" and by the whole of the business activity in the enterprise. The enterprise diagram allows for: • • • •

proposing a synthesised vision of the enterprise's activity; showing and positioning customers, suppliers and partners, in relation to the organisation business activity; understanding the links between the internal functional entities; communicating to the managers and staff a kind of "process" orientated vision which is no longer straight from "diagrams".

It is recommended to produce such a diagram when harnessing the strategy and as a step prior to the control of business strategy coherence - functional organisation - enterprise-flows synthesis diagrams - business processes cartography. Rules of good practice for an enterprise diagram Rule no. 1: Use clarity and readability. Rule no. 2: Show, in the commentary that goes with the diagram, the flows between primary level processes which have not been shown on the diagram for reasons of readability.

5.3 Case study: urbanism and strategy This section shows the file for the end of the business strategy gathering phase of the tour operator's IT system urbanisation project. 5.3.1 Introduction The purpose of the tour operator's IT system urbanisation project can be expressed in a single phrase: "To redesign and align the architecture of the IT system to the enterprise strategy and to provide it with the means to progressively evolve through independent projects."


77

The objectives that correspond to this purpose are to make target business, functional, software and technical architectures: • • •

aligned to the strategic stakes of the enterprise; allow for the progressive non-overlapping of the existing software; allow for he control of the evolutions in successive stages, using relatively independent projects which are mutually coherent and of a size reasonably within budget and duration.

In this framework, this business strategy gathering phase is intended to put the urbanisation project in the general framework of the enterprise strategy. The management and IT managers should explain the principal lines along which the study takes place. This activity has therefore been carried out on the basis of discussions, collection and analysis of documents (the list of people interviewed and analysed documents are attached to this document). This document shows: • • •

the restitution of the strategic business objectives; the setting of the IT system objectives and the definition of an initial list of KPIs (Key Performance Indicator); a diagnostic on the expression of the strategy as it is, and in particular, on the points to be specified.

The validation of this setting of the comprehension of the strategic lines by the study is important as it provides the starting point for working out the target which will be justified by its contribution to the expectations of these objectives. 5.3.2 The strategic business objectives Ishikawa diagram The strategic business objectives are represented by the Ishikawa diagram (Fig. 5.4).

78


Fig. 5.4 Strategic business objectives represented on Ishikawa diagram Notes on the strategic business lines To increase the number of contacts To become the leading tour operator in France again, sustained growth absolutely must be generated. This happens firstly by increasing the number of contacts, and secondly, by increasing the rate of turning contacts into reservations. As for increasing the number of contacts, more visitors must be attracted (current and future) to the distribution channels. The success of this objective cannot be left to chance and therefore takes a voluntary approach which requires a detailed knowledge of its customers and prospects in order to design and implement marketing plans that are well targeted and efficient. Increasing the rate of turning contacts into reservations The other means of speeding up growth is the improvement in the rate of turning contacts into reservations. Currently, this rate stands at 68%. An 80% rate would increase turnover by about 12%. In order to achieve this 80% target for turning contacts into reservations, the following must take place: •

direct the customers towards available products;


• • •

79

drastically reduce lost reservations due to customers leaving because of the size of the queues; allow the sales staff to focus on sales by reducing their administrative tasks to a minimum; process all requests in real time.

Develop alternative channels To deal with the increasing competition, the traditional distribution channel, even if it is likely to still remain the main source of sales, is not enough. Now it must: •

•

set itself up in e-commerce by using another brand name in order to win over another type of customer base which could be strongly developed in the near future; have products distributed by partners.

Apart from their contribution to the development of the market share the effect of these objectives will have a direct impact on profitability as an increase in the volume of business will allow for improving the profitability of the enterprise by virtue of the additional negotiation capacity that it would have vis-a-vis its suppliers. Reducing operating costs The stagnation in profits over the last three years and even the slight fall in 2000 is no longer acceptable to the shareholders. Furthermore, they mean the enterprise is losing ground to one of its competitors because the share price has been lower for over a year. The way out of this situation is through growth and gains in the market share already available, but also through good profitability in line with the best enterprises in the sector. What is needed here is the reduction of operation costs coupled with a continued quality of service. Four paths have been identified to achieve this reduction in operating costs: •

• •

optimising human resources at the at the head office switchboard, which is currently staffed by 80 people who make work without creating value for the tour operator. This therefore involves removing these activities and replacing them with activities that create value; the elimination of double entries, which not only lead to lost time, but also errors, which result in high costs; the reduction of communications costs linked to incessant telephone calls between the agencies and the organisation department and faxes sent daily to the agencies;

80

•


the distribution of the products of partners that complement what the tour operator has to offer and which needs no particular channel, or specialised skills, or management (which remains the responsibility of the partner).

Improve the cashflow Lastly, cash flow must also be improved, firstly by the real-time detection of bad payers so as not to start making reservations which could be given to good payers, and secondly by quicker invoicing. 5.3.3 Objectives of the IT system Ishikawa diagram The strategic business objectives of the IT system are represented by the Ishikawa diagram in Fig. 5.5.

Fig. 5.5 Strategic business objectives of IT system represented by Ishikawa diagram


81

Notes on the objectives of the IT system In order to properly respond to the business objectives, the IT system must have set the objectives described below. These objectives have been taken from the business objectives, and the link between the strategic business objectives and the IT system objectives is described in Section 5.3.4. Improve the productivity of the sales staff This involves making computers available to sales staff in the agencies or main agencies, freeing them from having to check daily faxes as to availability and making telephone calls to the head office to check availability in real time to make the reservations. Furthermore, the GUI (Graphical User Interface) will be particularly looked into so as to guide the customer as to the products available. Data concerning an existing customer can be recovered so as to avoid both lost time and the risk of error. Optimise the value of customers This is a matter of getting the maximum from customers and identified potential customers. The setting up of a loyalty programme aimed at making a customer spend more of his holiday budget on the enterprise's products, while currently it has been noted that the same customer may go on holiday three times a year but only go to the tour operator once. It must therefore move on from the ideas stage to that of certainty and be given the means for analysis to implement a targeted marketing which would allow this objective to be achieved. It must therefore record all its contacts (without harming the productivity of the sales staff) and install one of the best customer relations management tools on the market. Opening for sales 24 hours a day, 365 days a year The competition, the necessity to position oneself in e-commerce, and also the worldwide dimension of the tour operator, leads to the need for opening the sales system nearly 24 hours a day and 365 days a year. This opening essentially concerns the product and customer references and reservations. Allow direct sales Direct sales correspond to a market demand and allows for a significant reduction in management costs.

82


It covers: • •

sales on the Web; sales via a telephone call centre.

For the Web, it is a matter of opening a sales portal for some of the enterprise's products and partners' products, under a specific commercial brand name. As for the telephone calls centre, it is a matter of selling all the products of the enterprise under the usual commercial brand name. It is therefore an additional agency, but virtual. What is also involved is converting the organisation department administrators to a tele-consulting role. Of course, a specific training programme for this changeover will be designed and implemented for the changes of skills of these future tele-consulting administrators. Approval or declining in real time of requests for payment by instalments The approval in real time of applications for payment by instalments will mean the system will no longer be clogged up with pre-reservations which are later cancelled and will reduce operation costs. Integrate the products of third parties into the brochure The IT system must allow for the distribution of the products of partners that complement what the tour operator has to offer and which needs no particular channel, specialised skills, or management (which remains the responsibility of the partner). 5.3.4 Correspondence of business objectives/IT systems objectives Table 5.1 gives the overall view of the contribution of the objectives chosen for the construction of the future IT system to the strategic business objectives. It only shows the main objectives of the Ishikawa diagrams. An exhaustive correspondence table is given in Section 5.3.7.


83

Table 5.1 Contribution of objectives chosen for construction of future IT system Business objectives IT system objectives Improve the productivity of sales staff

Increase the number of contacts

Increase the rate of turning contacts into reservations

Develop alternative channels

x

Reduce running costs

X

Optimise the value of customers

x

x

X

Open for sales 24 hours a day

x

x

X

X

Allow direct sales

x

x

X

X

x

Approve or decline requests for payment by instalments in real time Integrate the products of third parties into the brochure

x

x

Improve the cash flow

X

X

X

84


Key Performance Indicators (KPI) The purpose of this section is to take a look at least one "performance indicator" for each of the objectives identified for the future IT system. These KPI will be monitored regularly to check if the objectives set have been achieved and thus measure the efficiency of the IT system development plan used to implement the enterprise strategy. The KPIs here are provided for illustrative purposes. In reality, each KPI must show at least the current performance and the forecast performance. Improve the productivity of the sales staff • Number of contacts recorded per agency sales staff per period. • Number of contacts recorded per main agency sales staff per period. • Number of contacts recorded per tele-consultant per period. • Number of reservations recorded per agency sales staff per period. • Number of reservations recorded per main agency sales staff per period. • Number of reservations recorded per tele-consultant per period. • Rate of converting contacts into reservations per agency sales staff per period. • Rate of converting contacts into reservations per main agency sales staff per period. • Rate of converting contacts into reservations per tele-consultant per period. Optimise the value of customers • Average number of trips per year per customer. • Rate of customers from year N-l also customers year N. Opening for sales 24 hours a day, 365 days a year • Availability of the reservation system to agencies. • Availability of the reservation system to main agencies. • Availability of the reservation system on the web portal. • Availability of the reservation system to the call-centre. Allow direct sales • Number of reservations recorded by the communications • centre. • Number of reservations recorded by the web portal.


85

Approval or declining in real time of requests for payment by instalments • Number of requests for payments by instalments not processed in real time. Integrate the products of third parties into the brochure • Number of third-party products in the brochure. • Turnover generated by the third-party products. • Margin generated by the third-party products. 5.3.5 Conclusions on the understanding of the strategy Generally speaking, the trend observed at the time of the interviews of the business strategy gathering phase is that the strategic objectives of the tour operator are known and shared between the actors interviewed. This observation is sufficiently remarkable to be highlighted. The current status evaluation and the target structure should make it easier; moreover, they will allow for the validation of the depth of this assertion to the operational levels of the enterprise. Besides this, the business strategy gatherings phase has brought to light a zone of uncertainty and debate which it is important to look into. Although the sale of third-party products is seen as an undisputed objective for its contribution to the strategy, its outline is even now too vague to be able to derive valid operational objectives from it for the future IT system. Not having been the subject of a detailed analysis, the results of the interviews carried out a priori show that this concept covers a mixed stock of potential products. It is essential that the perimeter that covers this concept of selling third-party products is clarified, because this may make significant impacts on the construction of the target. Failing this, the "third-party products sales" channels will have to be the subject of a separate "zone", without a strong link to the target IT system, to be built later. Hierarchical structure and prioritising of business objectives The people interviewed gave the following priorities for the business objectives selected:

86


Table 5.2 Interviewees stated priorities for business objectives Strategic business objectives To increase the number of contacts Develop a targeted marketing Develop a good knowledge of customers Increase the scope for opening for sales Increasing the rate of converting contacts into reservations Direct contacts towards available products Allow the sales staff to focus more on sales Reduce queues Reduce the administrative workload on sales staff Process all requests in real time Develop alternative channels Have products distributed by partners Set up in e-commerce Reducing operation costs Optimise human resources at the head office Reduce running costs Eliminate double entries and errors arising from this Distribute the products of partners Improve the cash flow Invoice more rapidly Detect bad payers in real time

Maximum priority

Average priority

Lowest priority

x

x x x x

x x x x x x

x x x

x x

x x x

x x

Hierarchical structure and prioritising of IT systems objectives The intersection matrix of business and IT system objectives and judgement have allowed for the easy deduction of the priorities of the IT system objectives using the priorities of the business objectives. The result is shown in the table on the next page:


87

Table 5.3 Result from intersection of business and IT system objectives IT system objectives Improve the productivity of the sales staff Propose a support application for efficient sales Propose a targeted and ergonomic GUI Recover customer data if an existing customer Check availability in real time Optimise the value of customers Set up a loyalty programme Set up targeted marketing Record all contacts Set up a customer relations management tool Open for sales 24 hours a day Allow access to product and customer references 24 hours a day Allow access to reservations 24 hours a day Allow direct sales Open a direct sales portal on the Web Change the call-centre exchange Approval or declining in real time applications for payment by instalments Automate applications for payment by instalments Integrate the products of third parties into the brochure

Maximum priority

Average priori^

Lowest

x

x x x x x

x x x x x

x x x x x x

x x

5.3.6 Enterprise diagram The diagram was produced for the current situation of the tour operator and the target situation. Enterprise diagram: current situation All the flows are information flows. The financial flows are indicated with dotted arrows. It should be pointed out that this diagram is not exhaustive. For example, the head office is not represented nor is its exchanges with the organisation department as to the validation of the brochure.

88


Fig. 5.6 The enterprise diagram (current situation) Enterprise diagram: target situation All the flows are information flows. The financial flows are indicated with dotted arrows. As with the enterprise diagram representing the existing state, it should be pointed out that this diagram is not exhaustive. For example, the head office is not represented nor is its exchanges with the organisation department as to the validation of the brochure.


89

Fig. 5.7 The enterprise diagram (target situation) The variance between the existing and target seems to be centred on the following essential points: • • • •

removal of pre-reservations and the direct making of reservations, which removes flows between the agencies and the organisation department; appearance of a virtual agency via the Web and a call-centre; processing of application forms for payment by instalments in real time; integration into the brochure of partners' products and making the tour operator's products available to partners for marketing. This point generates flows between the organisation department and the partners, and as for financial flows, they are also generated but this time between the finance department and the partners.

Aware of the stakes that computing represents for the achievement of this target, the Director General, has decided to create an IT systems department. The target flow chart is as follows and differs from the existing flow chart with the replacement of the IT department attached to the finance department by a real IT systems department.

90


Fig. 5.8 Replacement flow chart 5.3.7 Appendices Appendix 1: business objectives/IT system objectives correspondence The business objectives/IT system objectives correspondence table is shown in Table 5.2. Appendix 2: list of people interviewed The discussions that took place in addition to the analysis of the documents mentioned in Appendix 3 in order to acquire a complete vision of the strategic lines for the development of the tour operator involved the following: • • • • •

CEO; Financial Manager; Organisation Manager; Marketing Manager; Commercial Manager;

tTT

• •

Operations Manager; IT Systems Manager.

Table 5.4 Business objectives/ITsystem objectives correspondence table


95

Note: all those interviewed were managers. In the event of them being unavailable, they could be replaced by their immediate associates. However, even in this case, nobody in the field was interviewed, as it was not a case of making or reviewing the strategy, but more modestly, understanding and reproducing it. This is why the managers, or lacking them, their immediate associates, were the right people for these discussions. Appendix 3: list of documents used The list of the documents studied at the business strategy gatherings phase was as follows: • • • • • •

strategic business plan; reservation organisation audit report; current IT system audit report; work position architecture; flow chart; Year 2000 and Euro current projects study.


Chapter 6

Urbanism and business processes

This chapter describes the "how to" for activities linked to the existing or target business cartography of the methodological approach to the urbanisation of information systems.

6.1 Introduction It is advisable firstly to recall the definition of a process. A process is made up of a network of activities whose purpose is to process an initial management event. Its purpose is to produce the flow of results defined in the time and quality conditions set to meet the internal or external third party needs. It must be defined independently of every organisation and of all existing systems within the company, and correspond to the functional vision of the users. As for the procedure, also known as an organised business process, it is the representation process described within the framework of a structured organisation. It represents a sequence of operations carried out by effective actors concerning the data and controlled by management rules linked to markers. A procedure is triggered by a request and ended by the acceptance of a result.

98


6.2 Business processes cartography and the link with the strategy 6.2.1 Business processes cartography Objectives of the business processes cartography The business processes cartography allows for: • •

• • • •

having an overall "aerial" view of the processes; classifying the processes into sub-categories such as: - operational processes (processes having a direct impact on the performance of the enterprise or organisation), - support processes (processes having an indirect impact on the performance of the enterprise or organisation); the identification of the links that may exist between several processes; to establish an aid in the allocation of priorities for reconfiguration ; to allow the whole of the organisation at all hierarchical levels to "situate" itself in a descriptive logic stemming from the processes; the facilitation in the preliminary phase of the specification and establishment of a performance improving system.

Rules of good practice for business processes cartography Rule no. 1: The operational processes and support processes are separate. Rule no. 2: Each operational process is represented by several symbols, each symbol corresponding to a sub-process which may itself be the subject of a process model. Rule no. 3: Each support process is represented by only one symbol so to avoid repetition in the diagram. Of course, if it were a study principally concerning the support processes, the opposite rule would be applied.

Urbanism and Business Processes

99

Fig. 6.1 Graphic representation of the processes cartography 6.2.2 The process/strategic objectives matrix The alignment of the processes (or rather the procedures) to the strategy can be visualised in the form of a process/objectives matrix. The matrix columns are constituted by the objectives represented by the arrows in Ishikawa's diagram modelling the enterprise or organisation's strategy. All objectives and sub-objectives have a column, where a number of columns are equal to a number of arrows represented in the diagram minus 1 (for the principal arrow). The lines of the matrix are constituted by different processes. At the intersection of a line and a column, the contribution of the process to the achievement of the strategic objective has been indicated. This can be: •

lack of contribution;

1 00

• •


weak contribution when a malfunction in the process has an impact on achieving the objective without necessarily undermining the achievement of the objective itself; strong contribution when a malfunction in the business process is of a nature to question the aim of the objective itself.

This matrix allows the identification of: • • •

the processes not contributing to any strategic objective; the strategic objectives not sent by at least one process; the critical processes for effects of strategic objectives of the enterprise.

It should be noted that more sophisticated dimensioning scales can be established.

6.3 The process modelling 6.3.1 Introduction This section describes: • • • • • • •

the formality used for modelling the processes; how the processes can be re-used or designed with a view to their re-use; the problem of sub-contracting; coordination strategies in the case of an actor network architecture; the advantages and disadvantages compared between soft and hard process models; urbanism rules for process modelling; rules of good practice for the modelling process.

Finally, you will find a presentation of the practices and the rules of standardisation to be applied for producing a quality process model. 6.3.2 The (organised) process diagram The process model (organised or not) is the most important model for the representation of all the facets of a process. It describes the works circuit (activities) between the different actors (in the UML sense) and, consequently, a series of organisational choices (who does what? when? does it or does it not involve a human actor? etc.).


101

A process model comprises a process diagram and a process description. The description of the process is the natural complement of the process diagram. Very little textual information appears in the latter. It is therefore essential to provide complementary information in order to explain the different choices as clearly as possible. A process diagram is composed of all or part of the following elements: • • • • • • •

units or organisational actors; activities; events; data (electronic or otherwise); raw materials; product; software resources.

The organisational units or actors are the ones responsible for carrying out the activities which must be carried out effectively in order to attain the objectives of the enterprise or organisation. An activity is a task or action taken over an object within the objective in order to achieve one or more of the objectives set by the company. An activity may include pre conditions and post conditions. By 'event', we understand the fact that a business object benefits from a status linked to the task which controls or influences the remainder of the process. The events trigger the activities and may be the result of activities. The data represents all the data that is involved in the process; we make the distinction between the data which is available in electronic format and the data which is only available in paper format. The raw materials are the merchandise that the company purchases from the supplier in order to manufacture the finished products. The products are the finished products manufactured by the company's production unit (a factory, for example, if we are in the industrial sector). The software resources group together all the information processing resources. This comprises computers, networks, software, data warehouses, etc.

102


Fig. 6.2 Graphic representation: example of a process model — IT services management of monthly project reports

Urban ism and Business Processes

103

6.3.3 Reusing the process One of the major advantages of a defined description of a process is the option of re-using it. This can be done: • •

from a current process which is modified; by creating a general process and by deriving the responsibilities, by giving the specific values to a set of parameters.

As in all cases, we call the process from which another is constructed a reference model. Whichever the process model, it can be used as a reference model. We are concerned here with the concept of the inheritance of object-orientated analysis, which constitutes one of the principal techniques allowing for the reduction of development costs. It is also possible to create optimised strategies when standard problems are recognised in the process model, which will facilitate the reconfiguration tasks to a great extent. 6.3.4 Breakdown or subcontracting One element crucial to the choice in the design of a process is its resolution level or the degree of refinement of its representation: • •

a process activity may be broken down without creating a new process. The process model is then simply refined; an activity can be subcontracted to another actor (not involved with the process). This signifies the sending of a message to another process which is described by another process model. One of the principal aspects of the subcontracting is the fact that the subcontracted activity may be carried out with or without time control. If no time control is considered, the sending of the message signifies that it will be carried out as a last resort. In case of a timed order, the dispatch process must include a waiting activity which will end at the desired moment or which will be cancelled if the order is carried out. The act of subcontracting also comes down to communicating a situation which induces a triggering by the subcontracted actor;

1 04

•


an activity may also be controlled by an actor situated outside the limitations of the company process model, with or without delay control. The interruption transmitted by an actor is the signal that the activity has been carried out. This does not interrupt the execution of other activities.

It is important to note that: •

•

the dispatch of an instruction to an actor always consists of the transmission of a situation. It is then the responsibility of the actor for the analysis of the message and the triggering of the desired performance. It is at least the hope of the sender who will then have to check it! the only significance of the messages which pass through the interfaces of a transmission process are situations resulting from the execution of activities.

6.3.5 Coordination strategies in the case of an actor network architecture A process is an activities network leading to an objective. But who is responsible for the execution of all the coordinated activities? A good process design can pass over this question. In fact, this problem has three distinct aspects: •

•

Who is responsible for the execution? An organisation or a member? - For a low level of resolution, it is the organisation that is responsible for everything. - For a higher resolution, the process must be more accurate and indicate which specific person is responsible for it. - If the potential actors are defined, the question is then to know who gives the instructions to these persons. Who takes the decision? The manager or the performer? - A performer contents himself with doing what his manager has ordered him to do and he is aware that the manager is in a position to coordinate the network efficiently. Here we are referring to central coordination. - An assistant having a higher degree of authorisation only needs a launch signal. He himself becomes active under the impulse of this signal and takes the desired decision and carries it out. He then gives a report to the manager. Here we are referring to devolved control. This concerns the highest level of assistant's responsibility (of authorisation).

Urban ism and Business Processes

105

-

Who decides the impact perimeter and who decides the alerts and impulses? - This responsibility may fall upon the manager, who acts more as a team trainer than a boss. His task is rather to stimulate than direct. We will now consider decentralised coordination. - This responsibility can also be entrusted to members of the team. They respond to a new situation and determine if something needs to be done and, if needs be, determine the impact area, define what action to take and then take that action or send a message to a more competent member of the team. This concerns genuinely decentralised coordination. 6.3.6 Soft and hard process models A hard process model is extremely complex and must be limited to a single transaction. This includes basic activities, impacted and inferred activities, the derivation rules and the conditions for their triggering. In order to make a process model more comprehensible, numerous simplifications must be considered: • • •

everything concerning the appointment of actors before the triggering of a transaction can be eliminated; everything concerning the treatment of errors and anomalies can be deleted; all indirect and induced impacts can be omitted, but only to conserve the basic chaining. Impacted objects without condition changes are default.

These simplified process models, which have little respect for syntactic and semantic constraints, are easier to read, but less clear. In general, they are not sufficiently accurate to allow for the evaluation of a process, and can give quite a false impression of the enterprise's process model. 6.3.7 Urbanism rules for process models The application of the more important specified practices will allow for the production of the soft process model. In this way its usage will be aimed at experienced persons. The aim of these diagrams is not accuracy (for example, certain activities can be global and require numerous actors; interrupted activities, linked to the end of an activity, can be omitted; certain management rules can be vague or even uncertain), however, the general appearance is that of a process model.

106


Even if they are useful for comprehension, communications and design, these models could not be used by a computer. If the execution of a process is purely manual, the soft description can lead to some surprises when it is used by inexperienced persons. The standardisation of process models is aimed at applying the practices in a more restricting framework so as to produce hard diagrams, this means: • • •

non ambiguous; exhaustive; coherent.

Hard diagrams that can be interpreted by a computer or an inexperienced yet intelligent human operator must respect other constraints. Rule no. 1: Any change in the properties of an object is an activity, even if it is simply the age of the object that changes, as in the case of protecting an object between two transactions linked to this object. But in a standardised diagram, an activity can only involve a single object, even if it is a composite object. Rule no. 2: A basic activity cannot be interrupted, which shows that once an actor is allocated to an activity, it cannot be re-allocated before it has finished executing its activity or the interruption of this for abnormal reasons. Rule no. 3: The end of the execution of an activity causes the simultaneous ending of the execution of all activities falling within the impact perimeter of this event, whether indirect or induced impacts. Rule no. 4: Any activity may have an abnormal purpose, but also time or rejection events. Each of these events constitutes a particular event. 6.3.8 The rules of good practice for process models A process can use the concepts of the process model in different ways. The description may be more or less complete, but if it is completely exhaustive as in the specifications of an automated process, it is recommended to observe the following rules: Rule no. 1: A process stage corresponds to a type of transformation of an object expressed as its state.


107

Rule no. 2: Any activity purpose generates an event which corresponds to the fact that the transformation has been completed or interrupted. Rule no. 3: The occurrence of an event carries within it the purpose of the transformation of other objects which are linked to the main object. This is true, either because there are multiple representations of the same actual fact (indirect impacts), or because the management rules involve the re-evaluation of other activities (induced impacts). An activity, object or event may however start the stage. All other impacts are indirect or induced by this main event, because the activity involves several objects. Rule no. 4: An event may be activated by several triggered events, at least one for each object concerned. Rule no. 5: Each triggering is associated with a decision which may drive one activity or another. Rule no. 6: One activity may need one or more triggerings if some activities have to be synchronised.

6.4 The evaluation and improvement of processes 6.4.1 Introduction This part provides certain information on the evaluation of the processes. Furthermore, it presents the alternative that makes up the total management of quality, which is an approach of slow and continuous improvement in relation to the reconfiguration of the processes, which is a breakthrough improvement approach. It also describes the seven traditional lines that can be used to improve the processes. 6.4.2 The evaluation of processes Once the processes have been analysed, the following phase consists logically in evaluating them and identifying the means of improving their profitability. This can sometimes lead to the modification of the previously defined needs.

108


The improvements can be insignificant or drastic. The approach involving slow and continuous improvement of processes corresponds to the total management of quality. The breakthrough approach corresponds to the genuine method for the reconfiguration of the processes. Note that total management of quality and the reconfiguration of the processes are, by nature, complementary. Total management of quality provides the cultural framework necessary for the reconfiguration of the processes. In particular, it highlights the necessity to change the behaviour and attitudes regarding customers. This change in turn allows if some activities have to be synchronised for the creation/generation of an environment suitable for implementing the various strategies for the process reconfiguration. Note also that the methodological tools suggested in this chapter for the processes may be used both for the reconfiguration of processes and for total management quality. The evaluation of a process involves the determination of the costs and quality of the products and services provided by this process. The quality is principally evaluated by determining to what extent the primary and secondary objectives of the enterprise or organisation are achieved. The cost of poor quality will be measured when the process concerned is used to provide products and services. Reasons for this poor quality are generally as follows: • • •

late delivery; non-conformity to the specifications; lack of flexibility and thus non-satisfaction of customers needs.

For example: an Internet sales company for fresh products has filed for bankruptcy due to a logistics failure involving the delivery of already perished products and unhappy customers. Poor quality in the delivery process has produced high costs which led to the company's demise.


109

Costs will be evaluated from the use of resources by the process activities: personnel, equipment and consumables. If the organised process is standardised, each activity is performed by a single actor and the cost can therefore be calculated on the basis of: • • •

the unit cost of the actor; the quantity used and the duration of the task; the frequency of use per output element.

6.4.3 The improvement of processes Any improvement is the result of cost reductions in the activities. This can be linked to the removal of an activity or the execution of an activity by another type of processor or even a better coordination of activities. As a result, the seven lines allowing for the improvement of a process are: • • • • • • •

automation of activities; more careful management of activities; extension of the impact perimeter; anticipation of needs; the development of various execution scenarios; reduction of manual interfaces and reconciliation operations; improvement in technology.

Automation of activities This means that another type of processor is used by way of reducing costs and producing in a repetitive way. A typical example is of course the replacement of man with a machine to perform the activity. More careful management of activities This concerns the careful managing of activities in such a way as to better understand the details of the execution, thereby being able to detect problems more rapidly and more accurately. This then allows you to inform the other people concerned.

110


Extension of the impact perimeter This concerns the extension of the impact perimeter so as to immediately understand all the consequences of an event, and thereby better organise the use of processors. For example, in a shop selling electrical goods, if you go to the department to order a product, the checking of availability and the order are made in the department yet the impact of the event to the warehouse moves in such a way that when the customer presents himself at the counter for the collection of the merchandise after having paid, his merchandise is already prepared or is at least being prepared. The effect is, in this case, a significant reduction of waiting time at the counter and this has a direct impact on the customer's satisfaction. More efficient anticipation of needs in the long term This concerns better anticipating the needs in the long term and, therefore, the capacity to plan better the use of material resources and/or staff in the long term and to reduce unused resources. The development of various execution scenarios; for a given activity This concerns the forecasting of different variants of execution for the same activity in such a way as to be more flexible for the consideration of the personal needs from the product or service expressed by the customer. Integration of a single actor This concerns the performing by the same actor of all the activities linked to the management of the different phases of the lifecycle of an entity. This in fact eliminates manual interfaces and the reconciliation operations which are the frequent cause of non-performance within processes. Improvement in technology Improvement of technology allows the replacement of materials and/or logistics by those of better performance, in terms of speed of processing, accuracy or the rate of error. It is also a source of improvements to the processes.


111

6.5 Case study: urban ism and business processes This section presents the visions of the existing business architecture and the target business architecture of the tour operator's IT system urbanisation project. 6.5.1 Introduction This document shows: • • •

The current business cartography produced within the framework of the analysis phase of the existing IT system of the methodological approach; A diagnostic of the current situation; The target business cartography produced within the framework of the strategy design of the methodological approach.

6.5.2 The business cartography of the existing IT system The analysis of the existing IT system processes has allowed for the highlighting of the existence of seven operational processes and three support processes. The processes classified in the operational process category are those that contribute directly to the margins of the company while the others (classified in the support process category) only contribute indirectly: •

•

operational processes: - marketing, - reservations, - payment, - payment by instalments, - invoicing, - tour design, - product management; support processes: - administration, - accounting, legal, - finance.

112


Fig. 6.3 Processes cartography (current situation) Opportunity to analyse the processes The tour operator has been the market leader in his country for twenty years. But for the last two years, it has found itself relegated to second place and continues to lose market share. The Director General wants to implement a new strategy which would allow it to become leader in its sector again.

Table 6.1 Business objectives/processes objectives correspondence table

/: low contribution, H: high contribution

114


The matrix allows the forging of a link between the strategic objectives and the following business processes allowing for the highlighting of the sensitive processes for achieving the aforementioned objectives. Also, the modelling of the processes, both for the existing IT systems and the target, have been limited to the following operational processes, because they are important processes in relation to the strategic objectives of the tour operator: • • • • •

marketing; reservation; payment; payment by instalments; invoicing.

Of the five processes, the marketing, reservation and process for payments by instalments are the most important for achieving the strategic objectives. It is very important in this type of study to limit the perimeter, firstly, to conduct the study within a set time and within a reasonable budget, and secondly, to focus on the analysis of the processes likely to lead to a real creation of value for the enterprise. Cartography of the current processes The cartography of the current processes have been established in such a way as to have an overall view. However, it does not provide for the visualisation of the links between the processes. A model of the links between the operational processes has therefore also been produced. Links between the current processes The diagram of links between the current processes is given in Fig. 6.4.


Fig. 6.4 Links between current processes

115

116


Models of the current processes The process models are models of the organised process because, bearing in mind the problem to be resolved in the case of the tour operator, we need to go down to this level of detail. In particular, one of the problems encountered being the sales staff's administrative load, it was necessary to concretely represent the activities of the sales staff actor, thus showing the actors, and thus moving on to the level of the organised processes. This is not always the case, notably when there is no modification to be made to the processes. However, even if it formally concerns the organised processes rather than the process, the level of detail for the description of the organisation remains very macroscopic. In practice, either it is the urbanisation project of the IT system that contains an improvement to the processes, and so you are almost automatically obliged to go down to the level of the organised processes, or this is not the case and the process level often suffices. The production of these models needed the interviewing of two to three people per process. Finally, it should be noted that these process models are soft process models, as it is often the case with IT systems urbanisation projects in order to provide clarity of reading, the speed of the study and to meet with the project objectives which is neither a process reconfiguration project, nor a systems development project.


Fig. 6.5 Current marketing process

117

118


Fig. 6.6 Current reservation process


Fig. 6.7 Current payment process

119

720


Fig. 6.8 Current process for payment by instalments

Fig. 6.9 Current invoicing process


121

6.5.3 Target business cartography Cartography of the target processes The cartography of the target processes has been established in such a way as to have an overall view. You will note the appearance of a new process for reservations via the Internet and/or the calls centre and the disappearance of the process for payment by instalments. Payments by instalments have not been removed, but the existing process for payments by instalments managed the instruction for the applications for payment by instalments, which, within the target, is included in the automated activities of the reservation process at the agency.

Fig. 6.10 Processes cartography (target situation) Investment file The main benefit expected will allow the tour operator to become number one in the market again.

722


Other forecast advantages: • • •

increase in profit margin; improved image; comparison with the competition.

Financial analysis and KPIs (Key Performance Indicators) It is possible to obtain substantial profits by increasing the information request/reservation request ratio, which stands at 68%, to reach at least 72% and a maximum 88%. An 80% rate would increase turnover by about 12%. It would be possible to reduce costs significantly by replacing a large proportion of the people working at the organisation department's exchange with a new system. This would also allow for the reduction of communications costs. The size of the potential profits are as follows: Table 6.2 Potential profits Investment

Costs in millions of Euros

Profit in millions of Euros

Development of the new system

6

/

Acquisition of hardware and software

6

/

Training of users

1.5

/

Total

13.5

0

Table 6.3 Potential profits Operation (cost/year)

Costs in millions of Euros

Current costs in millions of Euros

Profit in millions of Euros

0.45

0.15

-0.30

Telecommunications

1.5

3.8

2.3

Salaries (telephone exchange)

0.3

4.9

4.6

Total

2.25

8.85

6.6

Maintenance of hardware and software


123

The payment process manages a very important monetary flow and, as a result, very rapid invoicing could have a significant effect on the cash flow. It is a point to study throughout the detailed analysis. The level of detail in the modelling of this process does not allow for the understanding of the causes of the problem. It would therefore be necessary to make the analysis of this process more detailed in order to understand the modifications needed for the payment process, which we will leave here. Summary of the financial analysis (in millions of Euros): Table 6.4 Summary of financial analysis

Investment Profit Returns on investments

2001 4.5

2002 9.0

2003 /

2004 /

2005 /

2006 /

/

/

13.6

14.1

14.9

16

-4.5

-9.1

13.6

14.1

14.9

16

NB: the profit threshold should therefore be reached by the end of 2003. Analysis of results The principal interest of the investment file is to allow for the increase of the reservation request/reservation ratio. This is why the team responsible for the project will study this question with particular attention. Thus, simulations with real customers will be organised with the aim of checking if the future processes will effectively allow the increase of this ratio within the forecast proportions. Risks There are several major risks involved with the planned redundancy scheme: • •

within the agency, sales staff will have less administrative work and will profit from appropriate training; at the organisation department's exchange, employees may fear redundancies. However, there is a plan that has been drafted for redeployment to other departments where the company has need to recruit, and, of course, this includes the communications centre (for direct sales).

124


On a technical level, there are also significant risks. Overview of the external environment The main competitor, currently the market leader, is called Club 2000. For two years, its agencies have been working with a reservations system in real time. Known information on Club 2000 is as follows: Table 6.5 Information on known competitor 1995 183

1996 213

1997 259

1998 297

1999 300

2000 305

Number of reservations (in thousands)

390

468

565

643

650

660

Profit before tax (in millions of Euros)

36

41

51.5

60

60

59

Turnover (in millions of Euros)

Definition of the scope of the project The scope of the project is as follows: • •

to analyse the five processes used; to design new processes which will allow for the achievement of company objectives.

Models of the target processes As the processes cartography provides no more for the target than for the existing vision of the links between the processes, a model of links between the processes used for the analysis has therefore been produced completely.


Fig. 6.11 Links between target processes

125

126


Fig. 6.12 Target marketing process


Fig. 6.13 Target reservation process in agency

127

128


Fig. 6.14 Target e-reservation process


Fig. 6.15 Target payment process

129

130


Fig. 6.16 Target invoicing process All objects in the target process models have been prefixed by a T (for target) so as to easily find ones' bearings between existing process models and target process models. The main differences between the existing processes and target processes are as follows: •

•

marketing process: addition of an order message for a brochure by an internet user, who must therefore leave his details in order to receive the requested brochure; reservation process: - appearance of two processes, one for reservation by the agency, the other for reservation via the Web or the call-centre, - activity for guiding the client's choice is carried out according to known availabilities and accessible in real time, - the return trips with the organisation department (checking of availability) have been removed,


•

•

•

131

- decisions concerning applications for payments by instalments are made in real time (for reservations at the agency), - reservations are made directly and there are no longer any prereservations, - for reservations via the Internet: - the visitor is able to order a brochure to be sent to his home, - the visitor is not able to apply for payment by instalments, - the visitor is able to settle his account by bank card (only means of authorised payment); payment process: this process is only very slightly modified. In fact, only the disappearance of the message about the previously paid balance sent to the reservation process is to be noted. This is no longer necessary as it is no longer necessary to transfer the reservation status from prereserved to reserved; process for payments by instalments: this process has disappeared since the study and the decision concerning an application to pay by instalments is now integrated into and automated within the reservation process at the agency and this method of payment is not authorised for payments over the Internet; invoicing process: this process is only very slightly modified. In fact, only the disappearance of the pre-reservation message that came from the reservation process is to be noted.

The link between these differences and the strategic objectives is clear and therefore does not merit any comment.


Chapter 7

Urbanism and functional architecture

This chapter describes the "how to" for activities linked to the target functional architecture of the methodological approach to the urbanisation of information systems.

7.1 The link between functional architecture

architecture and business

It should be remembered that one of the fundamental activities of urbanisation projects consists of representing the various visions of the IT system in forms which allow them to be used (a database or a software engineering tool reference framework for example).For this, a generic design model has been given in Chapter 3. At the level of this generic model, the link between the business architecture and the functional architecture is made by the link between the activity and block classes. An activity is linked to one or more business processes, which themselves allow for the achievment of one or more IT system objectives which will correspond to one or more strategic business objective. We have therefore the means of creating a link between an activity and the strategic business objectives. The activity is going to be automated by 0 to N functional blocks and a functional block will automate 1 to N activities. You have, therefore, via the activity, a link between the functional block (functional zone, functional district, functional plot) and the strategic business objectives that will contribute to achieving the activity. This link is very important in order to produce the investment files and for the instruction of arbitration decisions.

134


7.2 Transition architecture

of

the

business

architecture

to

functional

We firstly recall that the functional architecture is the structuring of the IT system into communicating functional blocks. This responds to the question: What? without taking into account the actors and the organisation. The transition from business architecture to functional architecture is both rigorous and artistic in the sense that there is a certain number of stage types and rules to respect which mark the urbanist's route, yet without however forming algorithms leading, if applied correctly, to the one and only correct result. These stages are described here and the rules are given in section 7.3. The first stage of the approach consists of applying the rules of good practice which allow for the prior definition of the following zones for the target functional architecture: • • • • • •

exchange zone; data silo zone; frame of reference zone; decision-making zone; operation zone; resource zone.

The second stage consists of using the business processes. The business processes allow for the identification of the primary core business classes. The description of the processes naturally allows for the identification of the manipulated business designs, and therefore, the classes allow for the description of business design which is independent of the organisation, i.e., the core business classes (see glossary). It should be noted that having described the processes which, by definition, do not describe the organisation, unlike the organised processes or procedures which, themselves, are the instantiation of the processes in a certain organisation, helping the identification of the core business classes. It is advisable next to distinguish from amongst the core business classes those that are essential (primary core business classes) from others (secondary core business classes).

Urbanism and Functional Architecture

135

A primary core business class describes a major business concept. A primary core business class is therefore a core business class with the essential idea of the corresponding business concept. A secondary core business class completes the definition of the business concept to which it relates. It is in principal in direct relation (association, aggregation) to the corresponding primary core business class. Most of the time, a secondary core business class can be a functional sub-set of the attached concept. In other cases, it may correspond to a concept of less importance which can have a different meaning from one context to the next. For example, the idea of an "address" may also be applied as much to a "customer" as to a "supplier". Each primary core business class gives rise, a priori, to: •

•

a district in the data silo zone which manages all the data pertaining to the only primary core business class in the district and to the secondary core business classes connected to this primary core business class; a district in the operation zone.

The third stage consists of completing the functional architecture outline according to the strategic objectives of the IT system. The fourth stage consists of identifying the sevices of the various blocks that form the functional architecture. For this, the basis is: • • •

the understanding of the existing IT system; the understanding of the urbanist; the existing models on the market (for telecommunications or IAA in insurance).

example

TOM

in

The fifth stage follows the use of the business processes. This involves leaving the management events, and performing the processes allowing for the processing of these events by checking for each activity of the process which functional blocks it can call on in order for the activity to be successfully completed and if the functional blocks in question contain the necessary services. The sixth stage is a feedback with regard to the strategic objectives of the IT system. This involves going over each development objective of the IT system one by one and asking oneself which functional architecture responds and which one brings a significant improvement in relation to the existing IT system.

136


The seventh stage is a feedback on the urbanisation rules for the functional architecture. Normally, these must have been respected; however, it is advisable to check them. For presentation needs, these seven stages are presented in a sequential manner; however, the design of a target functional architecture fulfils two points: •

•

it follows an iterative approach. Within the practice, three iterations are generally necessary, the first being the longest, the third being the shortest. At the end of the first two iterations, the perimeter of the following iteration is redefined and the decisions taken are documented; the order may be adapted to each context.

7.3 The urbanism rules 7.5.7 Reminder of the founding principles Before applying the urbanism rules, it would be advisable to check beforehand that the basic definitions have been respected. These are therefore recalled because they are the real founding principles for the functional architecture. The functional architecture is made up of three types of functional blocks: • • •

the functional zones; the functional districts; the functional plots.

The functional zone corresponds to the most basic breakdown level of the IT system and more often the highest level of the software organisation. A zone will typically correspond to what is commonly called a design and construction department or a system. The functional district is a group of plots. This groups together components that are uniform with regard to the nature of the information processed. A district will typically correspond to what is commonly known as a subsystem.


137

A functional plot is a replaceable entity of the software system likely to be developed or purchased separately. A plot corresponds to a functional purpose and includes the processing and accessing of data for this purpose. The services within the plot are carried out independently from the route taken by the information upstream or downstream of the plot. A plot produces standardised results that can be used by other plots. A plot will typically correspond to: • •


Each block (zone, district or plot) must present a high internal functional coherence and a coupling with the other blocks as low as possible. 7.3.2 Urbanism rules for functional architecture It should be noted that the rules presented here are simply being recalled, there is nothing new in them compared to those presented in Chapter 3. Rule no. 1: Block uniqueness rule. A plot belongs to a single district, a district belongs to a single zone, therefore a plot belongs to a single zone. At functional architecture level, a block must therefore not be duplicated. Rule no. 2: Rule for asynchronism of plots. After having processed an event, a plot can immediately process another without having to be concerned about what happens with the processing report of the previous event. Rule no. 3: A block must have a plug-in (external interface). It is able to activate the services of the block and to manage the block's incoming and outgoing communications. Rule no. 4: Any of the block's incoming or outgoing communications go through its plug-in.

138


These plug-ins offer the following advantages: • •

•

• •

•

they centralise the service calls and limit the number of interfaces; add an additional level of encapsulation: the inner block is considered as being a black box by the outside; in object development, a class already shows the first level of encapsulation; the principle is to take this to the upper level plots, districts and zones; mutualise the services: a single public service to respond to similar needs formulated by the various callers belonging, where appropriate, to distinct blocks, districts or zones; this also shows the principle of reuse; increase modularity; reduce to a strict minimum the impacts following a development of a plot whose public services are requested by a variety of callers and make it easier to determine the impact chain; facilitate the implementation of progressive maintenance.

Rule no. 5: Only plug-ins communicate with the message manager. Plug-ins are only allowed to communicate with the message manager. Rule no. 6: An item of data is the responsibility (whatever the type of access: creation, modification, deletion, display) of a single plot alone. One of the objectives of urbanism is the portability of the plots while respecting the rules of autonomy and asynchronism. In order to achieve this objective, it is necessary to have data structures aligned to the plots, because the adding, replacement or removal of a plot can take place with minimum impact on the IT system. 7.3.3 Rules of good practice for functional architecture It should be noted that the rules presented here are simply being recalled, there is nothing new in them compared to those presented in Chapter 3. Rule no 1: All functional architecture has an exchange zone (acquisition/ restitution) which is, in a manner of speaking, the IT system plug-in. The acquisition transforms external organisational flow events into functional flows carrying all the information necessary for their processing downstream by the function concerned. It also guarantees the conformity of the enriched functional flow with the undertakings made to the sender partner and with the conditions of execution determined by the enterprise.


139

The restitution adapts the results from the composition function to the information supports and communications channels, and customises the emission flow according to the partner and channel. Rule no. 2: All functional architecture has a data silo zone. This zone holds all the enterprise's dynamic and perennial information, as well as the access services to this data. It stores and uses the enterprise's data pool, guarantees its coherence and allows for its future enrichment. Rule no. 3: All functional architecture has a frame of reference zone. This zone groups together all the information common to the different elements of the IT system for which the life-cycle is relatively stable. A frame of reference contains the reference data concerning the products and services, administrative and accounts management rules of the company, its business and its organisation apart from private clients and access services to this data. Rule no. 4: All functional architecture has a single decision-making zone. This zone groups together blocks dedicated to control and analysis processes which use aggregated and recorded information. Rule no. 5: All functional architecture has one operation zone (or an IT sytem) per main business of the enterprise. All functional architecture has one operation zone per principal business of the enterprise or organisation; The IT system of an enterprise or organisation that has only one business therefore has only one operation zone. hi contrast, if the enterprise or organisation has several lines of business, the IT system must have an operation zone for each of them. For example, the IT system of a company operating in the P & C (Property & Casualty) insurance, life assurance and banking domain will have a P & C operation zone, a Life operation zone and a Bank operation zone. Rule no. 6: All functional architecture has a single resources zone (or IT system).

140


This zone groups together the systems dedicated to the management of the enterprise's internal resources (human resources, general accounting, etc.).

7.4 Case study: urbanism and functional architecture This section provides the view of the target functional architecture for the tour operator's IT system's urbanisation project carried out within the framework of the methodological approach strategy definition phase. As for the the functional architecture, this is only carried out for the target. Basically, it would be of little added value to artificially reconstitute an existing functional architecture which, furthermore, would leave a large part open to interpretation, and thus subjectivity. For the existing IT system, we start therefore with the cartography of the IT system with the software architecture. The first stage of the approach consisted of applying the rules of good practice which allowed for the a priorii defining of the following zones for the tour operator's IT system's target functional architecture, as illustrated by the following diagram: • • • • • •

exchange zone; data silo zone; frame of reference zone; decision-making zone; operation zone; resource zone.

At the end of this stage, the target functional architecture is shown as on the next page:


141

Fig. 7.1 Target functional architecture

The second stage consists of using the business processes. The business processes allow for the identification of the primary core business classes. Each of the processes has been reviewed. The process models (i.e. the diagrams and the associated commentaries) allow for the identification of the core business classes. A core business class is defined as a class allowing the description of a business concept for the enterprise independently of the organisation, as opposed to a business concept limited to the view of a user. Some appear explicitly in the analysis of the diagram as the reservation (for example, by visualising the reservation process at the agency), others need reading, and even the interpretation and textual descriptions associated with the diagrams. For example, the notion of the tariff does not explicitly appear in the process diagrams at the level of detail where they were produced. On the other hand, it appears quite naturally as soon as one clarifies in English what lies behind the activity "to guide the choice of the reservation process".

1 42


The analysis of the process models allowed for the early identification approach of the following primary core business classes: •

•

•

•

marketing processes: - brochure, - tariff, - customer, - agency; reservation process at the agency: - reservations, - deposit, - payment by instalments, - payment, - tariff, - location, - accommodation and type of accommodation - customer, - method of payment, - agent (vendor); e-reservation processes: - reservations, - deposit, - payment, - tariff, - location, - accommodation and type of accommodation - customer; payment process: - due date, - payment, - payment by instalments, - invoice; - invoicing process: - reservations, - due date, - invoice.

Next, it is necessary to distinguish between these core business classes, the primary core business classes and the secondary core business classes. Mostly, the distinction between these two types of classes is simple, but it sometimes a matter of the choice of design.


143

At this stage, it is also necessary to identify the primary core business classes which could escape us because they are not involved with the processes that we have modelled (we have not modelled all the processes). The processes not modelled for the target are processes which change little or not at all, you can therefore satisfy yourself with the modelling of the existing IT system, if any, or you can discover the primary core business classes by analysing the data model of the existing IT system which still exists in some form or other. For the tour operator, no process model being available, we have reasoned from the existing process model (approximately to the day) and we have worked with the system experts. It used to concern the identification of the essential objects in the design model for the existing data. This leads us to add the following to the list of primary core business classes: • •

the company structure; the accounting classification.

In the case of the tour operator we have therefore compiled the following list: •

•

primary core business classes: - person, - reservation, - payment, - payment by instalments, - invoice, - due date, - tour, - tariff, - schedule, - company structure, - accounting classification: secondary core business classes: - brochure, - agency, - deposit, - accommodation, - type of accommodation, - location, - method of payment, - agent (vendor).

144


At the end of this stage, the target functional architecture is shown as follows:


We note the following points: •

• •

the primary core business classes have given rise to either some districts, or to some plots for those which have arrived to populate the data reference district of the frame of reference zone; payment and payment by instalments have been grouped together; the secondary core business classes have not given rise to any districts or plots. This concerns the following classes: - brochure, linked to the tour primary core business class, - agency, linked to the company structure primary core business class, - deposit, linked to the payment primary core business class, - accommodation, linked to the tour primary core business class, - type of accommodation, linked to the tour primary core business class, - sales staff, linked to the company primary structure core business class, - location linked to the tour primary core business class, - method of payment, linked to the payment primary core business class.


145

The third stage consists of completing the functional architecture outline according to the strategic objectives of the IT system. The optimisation of the value of customers leads us to add (or confirm the interest in) the following districts: • • • • • • • • •

management of the service department; processing applications; processing problems; operational marketing; person; agency statistics; tour statistics; strategic marketing; management of people.



146


The opening for sales 24 hours a day, and therefore access to the product (holiday) and customer references 24 hours a day, leads us to add (or confirm the interest in) the following districts or plots: • • • • • • • • •

multimedia; person; tour; tariff; schedule; management of reservations; management of people; reservation; processing applications.

Of course, the existence of these districts is a necessary condition to be able to be open for sales 24 hours a day, and therefore access to the product and customer references, but it is not enough. The need for opening 24 hours a day will lead to other consequences on the technical architecture. At the end of this stage, the target functional architecture is shown as on the next page:


147


To allow for direct sales via the Internet and the call-centre lead us to add (or confirm the interest in) the following districts or plots: multimedia; management of the service department; processing applications; processing problems; management of reservations; reservation; management of people; person; tour; tariff; schedule.

148




Approve or decline applications for payment by instalments in real time which leads us to add (or confirm the interest in) thefollowing districts: • •

approval of payment by instalments; management of approval of payment by instalments.

At the end of this stage, the target functional architecture is shown as on the next page:


149


The fourth stage consists of identifying the sevices of the various blocks that form the functional architecture. For this, the basis is: • • •

the understanding of the existing IT system; the understanding of the urbanist; the existing models on the market: e.g. TOM (Telecom Operations Map) in telecommunications or IAA (Insurance Application Architecture) for insurance.

The fifth stage follows the use of the business processes. This involves leaving the management events, and performing the processes allowing for the processing of these events by checking for each activity of the process which functional blocks it can call on in order for the activity to be successfully completed and if the functional blocks in question contain the necessary services.

150




The sixth stage is a feedback with regard to the strategic objectives of the IT system. This involves going over each development objective of the IT system one by one and asking oneself which functional architecture responds and which one brings a significant improvement in relation to the existing IT system. The seventh stage is a feedback on the urbanisation rules for the functional architecture. Normally, these must have been respected, however, it is advisable to check them.

Urbanism and Functional Architecture Finally, the target functional architecture is shown as follows:


151


Chapter 8

Urbanism and software architecture

This chapter describes the "how to" for activities linked to the existing software architecture and target software architecture using the methodological approach to urbanisation of the IT system.

8.1 The link between the software architecture and functional architecture It should be remembered that one of the fundamental activities of urbanisation projects consists of representing the different visions of the IT system in forms that allow for them to be used (a database or a software engineering tool repository for example). For this, a generic design model was given in Chapter 3. At the level of this generic model, the link between the functional architecture and the software architecture is made by the association between the software block class and the block class (functional). Ideally, a functional block would correspond to a software block. However, in reality, it is only exceptionally that this kind of bijective correspondence occurs, due to considerations of implementation, installing software packages whose outline never corresponds to the functional blocks imagined, etc. Therefore the correspondence between the functional blocks and software blocks must be controlled. A functional block may give rise to a 1 to N software blocks, a software block may contribute to the implementation of 1 to N functional blocks. Beyond this, the link with the functional block allows for traceability to the strategic business objectives as explained in Section 7.1.

154


8.2 Existing software cartography This activity consists of representing the structures describing the IT system in a useable form for subsequent processing (notably for carrying out impact studies when designing the redevelopment of the software system). This task is very important. In fact, any project, of any type whatsoever, is destined to achieve satisfaction of the needs or the resolution of problems (current or future). It is therefore essential to know how to assess the current situation, to be able to diagnose it and make a prognosis. The objectives of the current software cartographies are as follows: • • •

to learn about the current software architecture; to describe the current software architecture; to assess the performance of the IT system and suggest some lines for improvement.

In practice, this must be based on current knowledge by the enterprise or organisation's design and development teams. The first stage consists, for the IT system urbanisation project team, of adapting the plot file (software) given below. In fact, firstly, the information requested must all be useful for the study, secondly, moreover, information already available must not be asked for and finally, the information asked fo must be checked that it has a chance of being collected bearing in mind the context. The more the questions are dealt with the better it is. So it is advisable to establish the list of possible values under the following headings: • • • • •

organisational entities concerned; existing actors; existing class concepts; existing business processes; existing site types.

The second stage consists, for the IT system urbanisation project team, of presenting the design and development teams with the results obtained. This stage allows for the teams to bond and check the proper understanding of each heading of the plot file.

Urbanism and Software Architecture

155

The third stage is the stage in which the requested design and development teams complete the files by taking advantage of the coaching from the IT system urbanisation project team. Typically, the list of plot files in question must be reviewed fairly rapidly, so as to check that a plot's level of granularity has been fully understood, and so must the first files, so as to check that the various headings have also been understood. The fourth stage consists, for the IT system urbanisation project team, of using the files. During this stage, some return trips to the compilers of the files are necessary, and the information is stored in the tool used for the cartography. It is therefore necessary to have a top-down approach as opposed to the bottom-up approach used up until now. In fact, to determine the districts and plots by analysing the plot files and working them out by the flows between plots is, firstly, a painstaking task, and secondly, gives no better result than determining beforehand (based on the knowledge of the design and development teams) what the zones and the main districts are, and trying to put the plots into these zones and into these software districts. The fifth stage consists, for the IT system urbanisation project team, of asking for the validation of the current software cartographies thus produced. The design and development teams, having completed the files, give their opinion to the steering committee to validate it or not. Finally, this software cartography shows: •

•

the various software that makes up the current software system. Its granularity corresponds to the identification of the zones, districts and plots as defined in the glossary; the flows between these software applications (direction, real time, deferred time, automated, manual, functional description of the content of the exchange, classification according to the typology used).

156


For each plot, there is the following descriptive file:

PLOTX Part 1: business description 1. Contribution to the business processes 2. Organisational entities concerned 3. Actors concerned, including third parties (number, type) Part 2: functional description 4. Objectives 5. Classification (Critical, Important, Useful) 6. Input 7. Output 8. Functions 9. Primary core business classes controlled 10. Interfaces Part 3: software and technical description 11. Year of development 12. Volumes processed (Max, Min, Av) 13. Availability 14. Reliability 15. Hardware 16. Operating system(s) 17. DBMS or file management system 18. Middleware 19. existing site types. Part 4: first diagnostic elements 20. Degree of urbanisation (external) 21. Degree of urbanisation (internal) 22. Main strong points 23. Main problems 24. New requirements


157

8.3 Transition from the target functional architecture to the target software architecture We remember firstly that the software architecture is the structuring of the IT system into communicating software blocks. The transition from the functional architecture to the software architecture is both rigorous and artistic in the sense that there are a certain number of stage types and rules to be respected which mark the route of the urbanist, but without, however, putting together any algorithms succeeding if they are applied correctly to the one and only correct result. The software architecture responds to the question: How? (Who? When? Where?). In contrast with the functional architecture, it takes into account the actors and the organisation. New ideas are therefore added, in particular ideas about software busses, front office, middle office, back office, copies, bodies, sites and communications arteries appearing. The message manager (or software bus). Once the breaking down of the IT system has been carried out, it is a matter of allowing communications between the various blocks. In an urban environment, this is shown by setting up lines of communication, public road networks, sewage networks, etc. In the IT system, it is the role of the message manager to provide these exchanges by means of specialist components (inter-applications message systems, software busses, etc.) on the basis of a standardised format, in a transparent manner for the software applications. At this stage, we are talking about the message manager because, from a logical point of view, it is unique, but this in no way prejudges the physical implementation for which different software busses may be installed, possibly using different products. It allows the software applications to communicate without being concerned about: • • •

the physical location of the sender or receiver software applications; the physical means and protocols used to communicate; the form expected by the recipient.

158


The message manager system provides four major functions: • • • •

the routing of messages (flows) from the sender to the receiver; the storage of messages with schedule of repayments and threshold management; the activation of software applications on expiry date (date, time, threshold) or for online transactions; the transformation of the messages: enrichment and formatting.

The plug-in is the means made available to the outside world by a block to offer its services. A plug-in comprises data structures and one or more operation names that can be used in this block. The functional blocks are then implemented by the software blocks which communicate through messages exchanged via the message manager software (or more than one physical point of view but only one logical point of view). The message is the mode of propagation between software blocks of adata flow resulting from a management event. It therefore represents a flow travelling within the enterprise or exchanged between the enterprise and its environment It may be sent synchronously or asynchronously. The front office is all the customer orientated services which can be activated directly by the external actor in contact with the customer or by the customer himself. The back office is all the product orientated services which cannot be activated directly by the external actor in contact with the customer or by the customer himself. The middle office is all the services which cannot be activated directly by the external actor in contact with the customer or by the customer himself allowing: • •

direct interaction with the customer; correspondence between the customer (front office) and product (back office) views.


159

The transition stages from the functional architecture to the software architecture are as follows: The first stage of the approach consists of specifying the functions expected from the message manager. The second stage consists of producing the mapping between the functional architecture and the software architecture. For this, we must start with the existing software architecture. For the functional blocks, which are relatively unchanged in relation to what existed before, the existing software applications are reused whether or not any maintenance operation has to be carried out. For the new functional blocks or those which have been significantly developed in comparison with the existing ones, it is rarer to reuse existing software applications with few modifications. The implementation of the target functional blocks must be planned as a combination of major maintenance on the existing software applications, installation of software packages or new specific developments. The more one aims towards new specific developments, the more it is possible to have a simple correspondence (even one-to-one) between the functional blocks and software blocks. It should be noted that for blocks in data silo and reference zones, correspondence between software blocks and functional blocks is generally one-to-one. The third stage consists, for each of the software blocks, of describing its plug-in and its functions. The fourth stage consists of arranging this software architecture in the course of being put into the organisation. It is in this way that the actors and the various site types are determined, and the software blocks are worked out before being instantiated in a multiple fashion. The fifth stage consists of giving a dynamic view of this software architecture and of identifying the major communications arteries.

160


8.4 The urbanism rules 8.4.1 Urbanism rules for the software architecture Rule no. 1: The data in the data silos must be stored. The shared data must be stored in order to allow for the "replaying" of a process if necessary and to guarantee the coherence of the content and its proper use. Rule no. 2: The data in the data silos must be accompanied by an update publication date. The data in the data silos must be accompanied by an update publication date so that the old values are not lost and so their value can be found again quickly. The three old values may be exported to the archived data management modules. Rule no. 3: The data reference data must be accompanied by an update publication date (as for the data in the data silos) but they must also have an effective date. In order to allow for the time version, the reference data in the data silos must be accompanied by: •

•

an update publication date so that the old values are not lost and so their value can be found again quickly. The three old values may be exported to the archived data management modules; an effective date.

Rule no. 4: Duplication of data. Within a block, the data may be duplicated between the context data and the data in the data silos as this corresponds to two shared levels and very different life cycles. In fact, the data is isolated and temporary for the context, while it is shared and permanent for the data silos. The data silo level must remain in control. Synchronisation within a block is ensured by the publication of the context while respecting the integrity rule for data silos (urbanism rule for technical architecture). Rule no. 5: The block that offers a service is responsible for the quality of the service.

T It is the block that offers a service which must ensure that it offers the best quality service, including continuity of service. 8.4.2 The rules of good practice for the software architecture Rule no. I: All software architecture has a management zone (scheduling) which provides the interface between front office, back office and middle office. More specifically, this zone carries out: •

• •

the translation, scheduling and management of requests from the front office. A request for service that comes from the front office is translated into a set of named services in a certain order at the level of the middle office and back office; the management of the IT system's internal processes; the management of priorities.

8.5 Case study: urbanism and software architecture 8.5.1 Introduction This section presents the view of the existing software architecture and the target software architecture of the tour operator's IT system urbanisation project, produced respectively in the framework of the current enterprise architecture analy is phase and the Land Use Plan activity of the "to be" enterprise architecture definition phase of the methodological approach. 8.5.2 Case study: existing software architecture During the first stage of the approach, the IT system urbanisation project team adopted the standard plot file. An example of a duly completed plot file is provided below for the reservation software application plot. Reservations plot specifications sheet Compiler Compiler: Christian Dufour Date compiled: 2/1/01

162


Part 1: business description (a) Contribution to the business processes Process Reservation

Contribution of the block to the processes x

Payment Payment by instalments Invoicing Tour design Marketing Product management Administration Accounting and legal Financial (b) User organisational entities Organisational units Head office

User organisational units of the block

Marketing department Financial department Commercial department Organisation department Operations department Human resources department Main agency Agency Actors concerned, including third parties (number, type) The eighty staff of the organisation service.

x

Urban ism and Software Architecture

163

Part 2: functional description Objectives To manage tour pre-reservations and reservations and means of transport. Classification (Critical, Important, Useful) Critical: This is the heart of the system. If this does not function, the enterprise cannot function. A stoppage, even if temporary, has financial consequences. Input • Reservation file: - identification of the payer, - identification of the travellers, - destination, - duration of holiday, - mode of transport, - town of departure and return, - method of payment. • Notification of payment of the balance. • Notification of non-payment of the balance. Output • Confirmation of pre-reservation. • Confirmation of reservation. • Notification of cancellation of a pre-reservation. Functions • Availability check. • Blacklist check. • Recording of a holiday pre-reservation. • Recording of a transport pre-reservation. • Change of status from a pre-reservation into a reservation or cancellation according to whether or not the balance has been paid.

164


(c) Primary core business classes controlled Creation x

Person

Modification x

Removal x

Visualisation x

Tour

x

Transport

x

Price

x

Location

x

Payment Payment by instalments Invoice x

Brochure Reservation

x

x

x

x

(d) Interfaces Name

From block

Type of flow

To block

Management

Exchanged elements

Business

None Part 3: software and technical description. Year of development 1989 Volumes processed (Max, Min, AV) Activity saw significant seasonal variations, which explains the very significant differences between the Minimum and Maximum volumes.


No./days Number of prereservations

M1N 500

AV 2,000

MAX 8,000

Number of prereservations

450

1,800

7,200

Number of prereservations cancelled

50

200

800

Availability From 8 a.m. to 10 p.m., French time, 7 days a week. Reliability Very good. Hardware System HP 3000. Operating system(s) Unix system V. DBMS or file management system Oracle V8. Middleware N/A. Site types concerned Head office. Part 4: first diagnostic elements. Degree of urbanisation (external) No interface therefore not applicable. Degree of urbanisation (internal) Monolithic software application

165

166


Main strong points • Reliability of the software application. • Very secure software application. Main problems • Insufficient availability, particularly for agencies located abroad and from the viewpoint of opening a direct sales portal (on the Web and via the calls-centre). • Use limited to organisation department staff. New requirements • To provide access to sales staff at agencies. • To drastically increase availability so as to aim at 24 hours a day for agencies and at direct sales on the Net. • To approve or decline payments by instalment in real time. The second stage consisted, for the IT system urbanisation project team, of presenting the design and development teams with the results obtained. This stage allowed for the teams to bond and check the proper understanding of each heading of the plot file. The third stage was the stage in which the requested design and development teams completed the files by taking advantage of the coaching from the IT system urbanisation project team. The fourth stage consisted, for the IT system urbanisation project team, of using the files. During this stage, return trips for the file compilers was necessary. The architecture of the existing software applications was clearly not built according to the explicit urbanisation rules proposed today in the framework of the study, but following an implicit logic of rationalisation which, moreover, was able to be developed over time. In order to piece together the model of the existing one in the form of an urbanism diagram, the plot files collected were grouped together according to the principles that categorise the implicit urbanism rules: •

the plot files were collected by the tour operator's team's working groups, then classified into sub-indices corresponding to these groups; even though this breakdown is very close to a work organisation, it is a first line of research for the districts and zones;

Urbanism and Software Architecture • • •

167

a sub-index with a limited number of plots (e.g. a dozen plots) may first be assimilated into a district; a sub-index with too many plots is a zone that must first be broken up into districts; the breaking up into districts of such a zone is done by grouping together plots which fulfil similar functions (printing of lists) or cooperative functions (strong functional coherence).

These rules have allowed for having a preliminary outline of the breakdown into zones and districts. To obtain a more detailed cartography, criteria such as the isolation of districts for reasons of ease of maintenance, perimeters of reurbanisation plans in progress or planned in the short term were taken into account. Finally, the software cartography produced is represented by the following diagram:

Fig. 8.1 The existing software cartography

168


The flows between software applications have been represented by means of a matrix with the help of a spreadsheet, otherwise they would make the previous diagram unreadable. The tour operator's software system was therefore broken up into four major software applications zones: the the the the

IT system-Organisation zone; IT system-Financial zone; IT system-Statistics zone; IT system-Administration zone.

These zones have a strong internal functional coherence and a minimal coupling. The system only has a single centralised computer site located at the head office. The construction of this architecture was the subject of several meetings with the tour operator's teams and was thus the subject of a consensus of opinion. The current cartography as presented corresponds to: • •

construction principles which are the "implicit urbanism rules" that the study team pieced together based on its observations; a more detailed analysis of the concerns for the future in terms of: - the needs and priorities for the reurbanisation of the existing systems, - the ease of maintenance of keypads which will have to be kept in the medium term.

Consequently, it is important to note that this subsequent reconstruction of a current "urbanised" cartography is an exercise guided by the search for its coherence and is therefore supposed to provide an ordered interpretation of the reality. It is therefore both normal and no great surprise that this exercise gives a fairly positive image of the current situation. However, it must not be forgotten that the construction of the target is carried out according to the urbanism rules of another nature which are clearly more restrictive than those which led to the construction of the "current town".


169

The view of the either line of development must not be forgotten: • •

to maintain the existing one using the capitalisation acquired on the reconstruction of its urbanisation into blocks inherited from the past; to (re)construct certain blocks according to the new principles and a timing that takes into account the strategic objectives.

A status evaluation was then produced, whose main elements were as follows: It is obvious that the current architecture corresponds largely to a management zone (an IT system) and that these IT systems communicate little with each other. The current problems may arise from two categories: those linked to the way the system was urbanised and those linked to problems inside the plots identified (as it were, those of the buildings constructed in the town). Seen from the angle of urbanisation, the main problems of the existing one and their possible consequences may be summarised as follows: •

•

Non-existence of a single message manager (from a logical point of view): the absence of a message manager is inherited from the systems design. It has been proved that this situation causes: - communications problems, as and when the media accessing the exchange zone increase (telephone, fax, Web, mail, calls-centre, etc.): the communications in pairs between media and production engines increasingly creates a network of inextricable exchanges, which are difficult to control and "noisy"; - from which arise problems with managing and controlling data, which has a tendency to duplicate at different places in the system for reasons of performance, accessibility or availability. Communications between blocks via mixed flows and multiple plugins: this meshing of plots that sometimes communicate in pairs will certainly pose problems for the implementation of a progressive reurbanisation by pieces. In fact, great care must be taken when planning the reurbanisation of sub-sets of blocks in order to properly identify the communications with the remaining blocks. One solution would be, maybe, to progressively design multi-flow interfaces or interfaces specialised by type of flow to isolate the blocks by making them communicate through these interfaces, before migrating the sets of blocks to the target.

170 •

•

•

The Enterprise Architecture IT Project Absence of a single responsibility for a plot on a primary core business class: this is probably one of the most important problems. It should be noted that it is placed at the macro level and not at a data design model object or programmes level. The analysis of the plots/data matrices is nevertheless a very useful tool for a preliminary approach to the impact perimeter of a modification. Absence of the frame of reference zone: this is of course a significant restriction that limits the flexibility of the system (approval in real time of applications for payments by instalments). Absence of a data silo zone: in the case of data processed in the back office, the major impact of this architecture option is the impossibility of making this data available 24 hours a day 7 days a week, other than by duplication in the front and middle offices. Moreover, this duplication presents the risk of a conflict between control data and replicated data.

The fifth stage consisted, for the IT system urbanisation project team, of asking for the validation of the current software cartographies thus produced. This did not pose a problem since the whole cartography was done with the experts on the existing IT system, and the validation was carried as and when required. 8.5.3 Case study: target software architecture The first stage of the approach allowed for the defining of the functions expected from the message manager. Communication between the basic elements of the IT system must be provided independently of the location and specificities of these different elements. The message manager will group together all the processes providing the "link" between all the components of the urbanised system. In fact, in a correctly urbanised system, each block has two standardised anchorage points (one anchorage point for events to be processed, and one anchorage point for reports). In order to ensure the cohesion of the exchanges between all the blocks, a message manager system must be implemented. As the blocks are no longer directly connected to each other, it is easy to replace one block with another. By acting as an "expansion joint", the message manager allows the system to undergo numerous changes while ensuring coherence of the whole.


171

The message manager will therefore ensure all the communications between the various blocks of the IT system. Its various functionalities are described in the following table: Table 8.1 Functionalities of message manager Blocks Functions Take the message into account Identify the sender Control doublets Message packaging Analyse the message Enrich the information Change formats Group/Split Transport Security, integrity, storage and traceability Queue management Find the recipient Transport

Administration of exchanges

Router

Queue management

Interpreter

This zone is typically implemented using the market middleware (e.g. EAI, transactional monitors, etc.). Let us remember that these tools allow for facilitating coherent communication in a distributed environment but is not responsible for the application of the business rules. These latter are in fact under the influence of the various software applications in the management zone. At this stage, the target software architecture is as follows on the next page:

172


Fig. 8.2 Target software architecture

The second stage consists of producing the mapping between the functional architecture and the software architecture. For this, we must start with the existing software architecture. For the functional blocks, which are relatively unchanged in relation to what existed before, the existing software applications are reused, whether or not any maintenance operation has to be carried out. For the new functional blocks or those which have been significantly developed in comparison with the existing ones, it is rarer to reuse existing software applications with few modifications. The implementation of the target functional blocks must be planned as a combination of major maintenance on the existing software applications, installation of software packages or new specific developments. The more you aim towards new specific developments, the more it is possible to have a simple correspondence (even one-to-one) between the functional blocks and software blocks. The results are illustrated by the diagram on the following page:


173

Fig. 8.3 Target software architecture

This diagram shows that: •

new developments or reconstructions must be undertaken for the following blocks: - the message manager zone, completely new and essential to the implementation of the principles of urbanism, - the exchange zone, new and necessary for taking into account the virtual agencies (Web and calls-centre), - the management zone, also new and needed to ensure the good quality of customer service, - the strategic marketing district, which must be created to best use the potential of prospective and actual customers,

174

•

•

The Enterprise Architecture IT Project - the management of people and reservations, which must be entirely rebuilt as they must firstly undergo major functional modifications, and secondly, they must not overlap, - the plot for approval of payment by instalments in the payment management district of the operations zone, which must itself be reconstructed because the number of functional modifications makes a reconstruction cheaper than a development. Its consequence is the construction of a new plot for approval of payment by instalments in the rules reference district of the reference zone; the following blocks may be constructed using existing software applications to be developed: - the tour management and tariff management districts and the cash payments management, schedule of repayments management, payments by instalments management and invoicing plots of the operations zone, - the payment, invoice and schedule of repayments districts in the data silo zone, - the tour, tariff and schedule plots of the data reference district of the reference zone; the whole resources zone, the agency statistics and tour statistics districts of the decision-making zone, the people and reservations data silo zone and finally the company structure reference zones and accounting classification must be able to be re used without modification (or with slight modifications).

The third stage consists, for each of the software blocks, of describing its plug-in and its functions. The example of the applications processing district illustrates this stage: •

Objectives: the purpose of the applications processing district services is to gather the information necessary for the downstream processing of requests from external actors. They provide the validation and enrichment of the elements gathered by calls to other services of the IT system. They provide the external actors with the significant information on the state of progress of the process.

Urbanism and Software Architecture •

175

Functioning: the applications processing district produces a graph for each request showing the stages to be carried out and the possible transitions from among these stages to acquire information from external actors. If not all the transitions are shown, this indicates that the order in which the request from an external actor is processed requires forcing. For each transition the services to call (validation more especially) to ensure the validity and exhaustiveness of the data may be mentioned. The call to a service of another block in the IT system gives rise to the sending of a functional flow (message) which will be recorded by a functional block in the workflow district. Once processed, the request also gives rise to the establishment of a functional flow to the same district. The objective of the applications processing district services therefore consists of guaranteeing the conformity of the final message sent, if it needs calls to other services.

The fourth stage consists of arranging this software architecture in the course of being put into the organisation. It is in this way that the front office, middle office and back office, as well as the various site types are determined, and the software blocks are worked out before being instantiated in a multiple fashion.

176


Thus the following target software architecture is obtained:

Fig. 8.4 Front, back and middle office of the target software architecture

At this stage, four site types have been identified (the head office, main agency, agency and virtual agency), but as the target technical architecture is centralised, there is no reason to break software architecture down by site type. An extract from the file associated with this target software cartography illustrates the work carried out in this field with the tour operator. Exchange zone The exchange zone is the zone through which all the flows that come from or are going to an external actor (customers, partners, other companies, etc.) pass to the tour operator's IT system.


177

It groups together all the services intended to: •

•

record the flows from actors outside the IT system in order to change them into valid functional flows ("business" messages) in relation to the subsequent processing conditions; send the information to actors outside the IT system; to this end, the software applications in the zone offer services that manage the various communications channels and the integrity of the transport; it does not process the contents of the information. They adapt and personalise the results according to the different media and actors who are to receive them.

Multimedia district The multimedia district groups together all the services which allow for distinguishing of the flows exchanged with the external actors. Remember that the management affects bidirectional flows, which both come into the IT system from an external actor and leave the IT system to an external actor. Presentation The presentation plot allows for modifying the "layout" of information exchanged depending on the type of actor or media through which the information was transferred. For example, there are services which allow for adapting a flow to a media used for "talking" to the actor, changing the flow of information into a HTML page, printing the contents of a flow, etc. Personalisation This plot modifies the content of the information exchanged depending on the type of actor and media. For example, there are services allowing for: •

carrying out data code conversions: the flows exchanged in a correctly urbanised IT system are standardised (e.g. "use" of a standard business reference framework). But if the company addresses an external actor, it cannot be based on the supposition that it is able to manage these standardised flows. A flow code conversion must therefore be provided to make them comprehensible by the external actor concerned (and the other way around);

178 •

The Enterprise Architecture IT Project to add all the information needed to personalise the exchange to the flows exchanged. For example, adding the logos of the recipients, a marketing message depending on the recipient.

Routing This plot contains the services that allow the information to be routed to the right destination. For example, it has services that: • •

•

sort the mail to identify the management actions to be executed; group together a set of flows sent to a single actor. For example: grouping together flows of information so as to print them and send them in a single batch; breaking up a flow going to several actors.

Management zone The target architecture is resolutely "services" orientated. These latter are offered by different blocks in the IT system. The processing of a functional flow sent by the exchange zone will therefore cause the logical sequence of the various services. These "management" functions of a request will therefore be covered by the blocks in this zone. As we will see later, these functions are essentially constructed with the aid of a workflow engine and its reference framework. The functions of this zone are not to be confused with those of the message manager zone. The latter mainly provides the functions of connecting and formatting the messages exchanged between the blocks. Workflow district Translation, scheduling and managing of processes: •

A service request has several origins: - the exchange zone (e.g. the valid functional messages from the interactive software applications); - other blocks in the IT system in the context of execution of internal processes (e.g. requests made internally via batches).

The various requests must be changed into a set of calls to services of other blocks in IT system (concept of management).


179

The scheduling of these calls and the validation of the coherence of the transaction in its entirety are part of the activities in this district. •

•

Management of priorities: the management of priorities groups together the services that provide the automatic scheduling of the work of the sales staff. There the management of commercial or administrative events (e.g. the sending, receiving of documents, follow-up items, etc.) is carried out.

The fifth stage consists of giving a dynamic view of this software architecture and of identifying the major communications arteries. For this, using the processes, the types of sequences for these events are identified and, for each of them, the sequence of services of the software architecture is traced, which allows for the proper processing of the processes initial management event. Remember that one of the urbanisation rules requires that a block has to have a plug-in (external interface). This plug-in is able to activate the services of a block depending on the information contained in the incoming flow and to manage the incoming and outgoing communications of this block. The activation of the services is standardised. The results of the processes carried out (or reported) are also standardised. The structure of the reports covers: • • • • • •

the identification of the sending block (the one that carried out the service); the service to be carried out; the context of the service to be carried out (identification of the service caller block, date and time of the request); the identifiers of the objects concerned (e.g. reservation); the information needed for the processing; the results of the processing.

We note that, in a correctly urbanised IT system, the plug-in of a block publishes all the services that it offers to the other blocks in the IT system. All the blocks in the IT system can therefore access all the services through the message manager (unique from a logical point of view).

180


To model all the flows of the IT system would therefore come back, in the end, to identifying the exchanges between all the blocks. This sort of model would make the diagram unreadable and would have no added value (theoretical modelling) since it is the processes carried out that define the services used and therefore the exchanges that exist practically. It is therefore preferable to present the flows, i.e. the dynamic, of the software architecture on the basis of a few typical cases (exhaustiveness is neither possible nor desired), and then use them to work out the communications arteries. A communications artery is a message manager body dedicated to a flow type and that corresponds to its characteristics of fluidity (flow direction, availability, response time) and volumetrics. The following example describes the way in which the blocks of the IT system will interact in a tour reservation process at the agency with an application to pay by instalments. In our case, the triggering event for a new reservation is a reservation request at the agency. This event is received by the IT system in the form of an incoming message which will be transferred to the management plot of the multimedia district in the exchange zone. This plot will in turn send a flow to the applications processing district in the exchange zone. The applications processing district will allow for the interactive guiding of the management of the request. The incoming reservation request message will trigger the activation of the reservation request service which will pilot the stages to be carried out by the external actors to process the request. In the case of a new reservation, among other things, what must be shown is: who the travellers are, the dates of departure and return chosen, the place of departure, etc. This service will thus lead the dialogue with the external actor. At each stage, the logical description will be shown on a screen to be shown to the user to key in or view the data. It will be sent in the form of logical screens to the multimedia district. Between each stage, the call to the IT system services or other services may be programmed.


181

Fig. 8.5 Logical screen description flows

The logical screen description flows (management flow) will be intercepted by the personalisation plot. Their contents will be enriched with personalisation data according to the external actor (e.g. with the logo of a partner). The personalisation plot will then send a new flow to the presentation plot, which will be responsible for converting the logical screen into the physical screen according to the media used. As the processing of the request progresses, and more specifically, at the time of the transitions between the stages (screen sequence), this district will send flows to other blocks in the IT system. For example, it might be that after having entered the travellers, a validation might want to be carried out before moving on to the next stage. A call to the person validation service (are they blacklisted?) must therefore have been programmed for the transition between the stage of entering those involved (travellers and payers) and the following stage.

182


The validation service for payments by instalments is in the plot for approval of payment by instalments. This plot interprets and uses the rules to be applied to the data which was sent to it by the workflow district. Once the validations have taken place, the plot will send an execution report to the applications processing plot via the workflow block.

Fig. 8.6 Validation service for payments

If necessary, at the time of entering the data pertaining to the reservation, draw up a list of possible starting points; the applications processing plot would have made calls to a tour plot service in the data reference district which would have returned the information requested to it. Remember that all service requests between blocks are made through the message manager.


183

Once the interactive part of the request process has been carried out and all the data necessary for making the new reservation has been entered, the work carried out in the exchange zone is ended. It remains to back up the data in the data silos and possibly to carry out other actions that do not need interaction with an external actor. The management of these operations is carried out in the workflow district of the guidance zone according to the description parameters of the service for preparing a new reservation. This service will be called when leaving the applications processing district.

Fig. 8.7 Workflow district of guidance zone

It might be that it has to link up several business processes such as validating the reservation as a whole, calculating the next due date etc. The linking of services to be carried out is also programmed.

184


The calls will be made in the same way as those described above: • • •

to validate the reservation as a whole, the validation service must be called for a request for immediate payment; to calculate the next due date, it will call the due date calculation service in the invoicing plot of the payment management district in the operations zone; etc.

This approach, repeated for about twenty typical cases, has demonstrated the communications arteries needs in the target IT system. In the case of the tour operator, this allowed for the identifying of five arteries, as illustrated in the following diagram:

Fig. 8.8 Communications arteries in target IT system A data/reference framework artery for accessing the reference zones and data silos. This artery must offer movement in both directions and offer toplevel characteristics in terms of availability, response time and security. The traffic along this artery is very heavy and practically permanent, particularly during the agencies' opening times.


185

A front office/middle office-back office artery for the link between the front office and the rest of the IT system (i.e. both the middle office and the back office). This artery must offer movement in both directions and offer toplevel characteristics in terms of availability and response time. The traffic along this artery is very great and practically permanent, particularly during the agencies' opening times. It is through this artery that all the flows outside the IT system pass. A business artery for the link between the management zone and operations zone and for communications within each of these two zones. This artery must offer movement in both directions and offer top-level characteristics in terms of availability and response time. The traffic along this artery is very great and practically permanent. A resource artery for the link between the resource zone and the rest of the IT system. This artery must above all offer movement in the incoming direction of the resource zone and offer low-level characteristics in terms of availability and response time. A decision-making artery for the link between the decision-making zone and the rest of the IT system. This artery must above all offer movement in the incoming direction of the decision-making zone and offer low-level characteristics in terms of availability and response time. 8.5.4 Comments on the changeover from software architecture to technical architecture The identification of the arteries and movement direction must be completed by the volumetric elements as these are the basic elements for defining the requirements for the technical infrastructures that support the IT system. The technical architecture level for the reference framework, as described in Chapter 3, concerns the technological infrastructure of the IT system, which represents all the hardware and software installations produced to allow the software applications that automate the business processes to be carried out within conditions that satisfy the user. They comprise notably: • • •

the local and long-distance networks; the hardware platforms; the basic software (operating system, DBMS, middleware, etc.).

186


There are:

• • •

the primary technological infrastructures which have a role for the whole of the IT system; the secondary technological infrastructures which have a role for a zone or some districts in the IT system; the tertiary technological infrastructures which have a role for a plot, even a group of plots in the IT system.

In the context of an IT system urbanisation project, it is advisable to focus on the primary technological infrastructures, and perhaps a few basic points for the enterprise or organisation concerning the secondary technological infrastructures. But overall, the secondary and tertiary technological infrastructures is more to do with the technical architecture (i.e. concerning a plot or, at a pinch, a district) than the technical architecture level of the reference framework for urbanism (i.e. concerning the whole of the IT system). The technical architecture dimension of the urbanisation project which is not covered by our case study must allow for: • • •

defining the main lines as to the technical infrastructure; categorising the layouts of the arteries, platforms and networks on the basis of the volumetric elements collected at the software level; drawing up recommendations for tools for the technological infrastructure which allow for migrating towards a broader standardisation.

Finally, the changeover from software architecture to technical architecture starts with a model changeover phase intended to provide enough data sufficient for the drafting of the technical appendices to the specifications which will allow for the sending of requests for information and/or proposal requests to technical architects and/or systems integrators.

Part III

The methodological approach


Chapter 9

How do you define the target and associated migration plan

9.1 Introduction This chapter describes the methodological approach to the urbanisation of IT systems. This is based on the concepts described in Chapter 3. It covers the phases and activities necessary for developing an evolution strategy for the IT system and the IT systems department. This is illustrated in Chapters 4 to 8, which give the "how to" via a case study on the sub-set of the approach from which the method originated, namely, the urbanisation of IT systems. The methodological approach is shown in the form of a set of phases broken down into activities: •

Each phase is described by a file comprising the following headings: status of the phase in the process; objectives; presentation; incoming elements and finished products; outgoing conditions; roles needed to achieve the objectives; major risks; skills; techniques; tools; activities diagram; special considerations.

190

•


Each activity for this is described by a file comprising the following headings: - objectives; - presentation; - actions to be taken; - incoming elements and finished products; - responsibilities (the important responsibilities are indicated). The various experts who may be consulted as the need arises are not shown in the activity tables. On the other hand, they are listed under the heading "roles needed to achieve the objectives" in the phase descriptive files); - special considerations.

The methodological process is illustrated in Fig. 9.1:

Fig. 9.1 Methodological approach to urbanisation of IT systems

The Target and Associated Migration Plan

191

9.2 Construction of the solution The process proposed is not a rigid method, but a set of methodological components constructed to be selected and integrated into the aim to form the best solution to a given need in a specific situation. In order to limit its complexity and to reduce the effort of the head of the study in the context of the construction of the solution, these methodological components have already been given in a sequence corresponding to the most common situation. For example, in the typical situation, the current enterprise architecture analysis precedes the "to be" enterprise architecture definition while in some contexts, if one can imagine, at least in a first instance, an ideal target, the "to be" enterprise architecture definition starts at the same time as the current enterprise architecture analysis and progresses in parallel and in a relatively compartmentalised way. In other words, the tasks (phases and activities) to be carried out and the progress cycle for these tasks must not be confused. In this chapter we show the phases and activities without concerning ourselves with the progress cycle which, itself, must be adapted in the context of each project.

9.3 The urbanisation process of an IT system 9.5.7 Planning the study Status of the phase in the process

Fig. 9.2 Planning the study

192


Objectives • To bring together the conditions for the success of the study. • To define the study cycle, the rules and procedures. • To manage the resources, plan and allocate the work. • To formalise the study quality assurance plan. Presentation This phase of planning the study corresponds to: • • • • •

• • •

the definition of the methodology adapted to the context and objectives pursued; the drafting of the study plan and the collection plan for the necessary elements input to the study and the first discussions to hold; the formalisation of the organisation proposed and, in particular, of the study management and validation structure; the putting into place of the study's start-up conditions and, in particular, the logistical plan; the drafting of the quality assurance plan that formalises: - the approach - the description of the deliverables, - the plan, - the launch note; the organisation of a launch meeting; the distribution of a launch note; the appropriation by the study team of standards useful for the operation.

Table 9.1 Incoming elements and finished products Incoming elements Request


Outgoing conditions • Validated work plan. • Validated quality assurance plan. • Tools needed for the operational study.


193

Roles needed to achieve the objectives • Study sponsor. • Study manager. • Project manager. • Quality manager. • Business project manager. Major risks • Instability of the scope of the study. • Projects coming into conflict with the study. • Inappropriate or too weak sponsor. • Unquantifiable risks. • Vague or unrealistic objectives of the study. • Essential resources and skills unavailable or insufficiently available. • Support of any inexperienced people. Skills • Project management. • Quality management. • Development of SI/IT strategy. Techniques • Project planning. • Risk analysis. Tools • Project management tool. • Risk management tool. Activities diagram This phase is not broken down into activities. Special considerations It is important to reach an agreement and understanding among all the people responsible for defining the study's scope of action and its progress logic in a clear and precise way.

194


The quality assurance plan must formalise: • • • • • • • •

the objectives; the perimeter; the launch note; the approach; the deliverables; the plan; the resources; the management structures.

9.3.2 Business strategy gathering Status of the phase in the process

Fig. 9.3 Business strategy gathering Objectives • To obtain and understand the general policy and strategy of the enterprise or organisation. • To evaluate their consequences in the short, medium and long-term at the level of its IT system and software system. • To verify or carry out the alignment of the IT system's development objectives to the strategic business objectives.


• •

195

To carry out the formalising or specify the choices involved. To find out about the major malfunctions of the current situation.

Presentation This phase is aimed at putting the urbanisation study into the general context of the enterprise's strategy. The computer department and managers must therefore explain the principal lines along which the study is to be carried out. This activity is basically carried out on the basis of discussions and meetings on the collection and analysis of documents. Table 9.2 Incoming elements and finished products Incoming elements Enterprise strategy

Finished products Model of the strategic business objectives Note on the business development lines Model of the strategic objectives of the IT system Note on the strategic objectives of the IT system Traceability matrix of the business/IT system objectives Diagram of the target enterprise^

Outgoing conditions The finished products are validated. Roles needed to achieve the objectives • Project manager. • Study manager. • Study team. • Management committee. • Business department. • User. • IT system department. • Quality manager. • Study sponsor. • Business project manager.

196


Major risks • Unavailable or too vague business strategy. • Conflicting requests. • Conflicts of interest. • Unquantifiable risks. • Not noticing hidden points. • Drifting in relation to the initial perimeter. • Conflicting projects. Skills • Development of SI/IT strategy. • Holding of discussions. • Drafting of reports. Techniques • Holding of meetings. • Ishikawa diagram. • SWOT (Strengths, Weaknesses, Opportunities and Threats). Tools No particular tool.

Fig. 9.4 Activities diagram for the business strategy gathering phase


197

Special considerations 1. The enterprise or organisation's strategy may have short, medium or long-term consequences on the IT system and software system. It is therefore desirable to maintain the distinction between each group of impacts. This classification will be used when establishing the hierarchy for the redevelopment and scheduling of the implementation of the urbanisation. 2. This phase is essentially carried out on the basis of discussions, meetings and the collection of documents. 3. This phase will also show the development needs independent from the strategy, but arising from outside constraints, such as, for example: - taking into account the currencies involved; - changes to the regulations for the business studied (new taxes, international procedures, etc.); etc. 4. The documents drafted in this phase must be drawn up in close collaboration with the head of the urbanisation study. The management must be involved in the approach. They will at least formally approve the documents produced. 5. The business departments are directly concerned and involved, as the purpose of this phase is to understand the business and its development needs. 6. The management must formally approve the documents in order to verify that the strategic lines taken are properly understood. Understanding the enterprise business strategy Objectives • To provide the study team with a full understanding of the the enterprise's choices and orientations. • To get the management to formalise and/or specify the choices involved. • To make the IT managers aware of the enterprise or organisation's strategic stakes. Presentation Urbanisation interventions have their origins in the strategic decisions made by the enterprise or organisation. The strategy comprehension activity is intended to define a reference framework common to the managers, IT managers and the team in charge of the urbanisation study on the enterprise or organisation's general strategy. It is a matter of showing the most constructive strategic choices for the IT system.

198


This activity allows for the understanding and validation of the different strategic orientations of the IT system, bearing in mind: • • •

the computer department's point of view; the point of view of the management of the enterprise or organisation or the entity studied; the point of view of the users.

From this common framework, the team in charge of the urbanisation can clearly define the limits of the involvement of urbanisation. Once the limits of the scope of the study are defined and shared between all the actors, the team in charge of the urbanisation will establish, broadly speaking, the first conclusions that it can take from the the enterprise's vision in terms of the layout of the IT system. Actions to be taken • Gather and analyse the documents concerning the enterprise's description and strategy. • Prepare for the discussions on the basis of the analysis of documents previously collected. • Hold a limited number or targeted discussions. • Analyse the discussions. • Consolidate the results and design the strategic business objectives model. Table 9.3 Responsibilities Responsibility Actor A Project manager R Study manager A Study team I Management committee Business department C C User C IT system department C Quality manager I IT system management committee C Study sponsor C Business project manager R: is Responsible for. A: is Actor (i.e. carries out the operation). C: is Consulted. I: is Informed.


199

Table 9.4 Incoming elements and finished products Incoming elements Enterprise strategy Model of the strategic business objectives Note on the business development needs Diagram of the target enterprise

Finished products

X X

X

X

Special considerations 1. The documents produced are approved by the management and cosigned by the IT systems department. 2. The note on the development needs includes: the key threats and opportunities; the upper level requirements; the key restrictions, the investment rules and budgetary dependences visa-vis third parties; the barriers to change; the KPIs and CSFs. Future business vision definition Objectives • To explain the short, medium and long-term vision of the development of the IT systems. • To find out about the major malfunctions of the current situation. • To verify or carry out the alignment of the IT system's development objectives to the strategic business objectives. Presentation In this activity, the following actions should be carried out: • • •

•

Analysis of any documents that may be available that show the enterprise's strategy. Preparation of a discussions guide. Holding of discussions. The discussions are held with: - the management (strategic vision); - the IT structures management (means, costs, etc.); - the user managers (vision as regards service provided, etc.). Analysis of discussions.

200 • •

The Enterprise Architecture IT Project Consolidation of results. First classification and putting needs into a hierarchy.

Actions to be taken • Understand the development needs. • Analyse the impact of the business strategy on the IT system: gather information on the IT system (notes, files, etc.); analyse the suitability of the IT system to the enterprise's strategy. • Define the strategic objectives of the IT system. • Check or carry out the alignement of the IT system's development objectives to the enterprise or organisation's strategy. Table 9.5 Incoming elements and finished products Incoming elements Model of the strategic business objectives Note on the business development needs Model of the strategic objectives of the IT system Note on the strategic objectives of the IT system Traceability matrix of the business/IT system objectives

Finished products

X

X

Table 9.6 Responsibilities Responsibility Actor A Project manager R Study manager A Study team I Management committee C Business department C User IT system department C C Quality manager I IT system management committee C Study sponsor C Businessjproject manager R: is Responsible for. A: is Actor (i.e. carries out the operation). C: is Consulted. I: is Informed.

X

X

X


201

Special considerations

1. The note on the strategic objectives of the IT system must include the response elements to the following subjects: - what are the lines of development envisaged for the business, functional software and technical architectures? - what are the lines of development envisaged by type of computer business in terms of staff, qualifications, creation of "new busines" (quality, components architect, etc.)? - what are the developments in terms of software services (development of specific software applications, user support, etc.)? - what are the quality objectives (software delivery deadline, zero defects, etc.)? 2. If the profession supported by the IT system has statutory restrictions linked to the business, an inquiry must be held with the federating organisations to identify the developments planned for the subsequent few years. These developments, which are sometimes major, may cause significant structural modifications to the IT system. 3. All outside restrictions not directly linked to the strategy, but which must be taken into account, must also be found out about. For example, in Europe: - changeover to the Euro; - application of a new VAT; - etc. 4. The development needs will be classified according to order of priority. In particular, the development needs in terms of performance on the key management events are made clear. If possible, a macroscopic estimate will be made for the workload incurred. If sequencing restrictions are identified, they must be recorded.

202


9.3.3 Current enterprise architecture analysis Status of the phase in the process

Fig. 9.5 Current enterprise architecture analysis Objectives • To become familiar with the current architectures as to their technical, software and business aspect. • To evaluate the performance of the IT system and suggest some lines for improvement. • To define the broad outline of the development strategy for the IT system on the business, functional software and technical plans, and also the expertise and skills needed. • To define the broad outline of the development of the operational processes for the IT systems department. • To define the urbanism rules.


203

Presentation This phase will consist firstly of representing the structures describing the current IT system in a useable form for subsequent processing (notably for carrying out impact studies when designing the redevelopments of the software system). Secondly, the orientations of the overall IT system strategy are decided before being specified in the next phase of the approach. These orientations cover the various architectures of the IT system, and also the organisation and operational processes of the IT systems department, expertise and skills. Table 9.7 Incoming elements and finished products Incoming elements Current IT system Finished products from the business strategy gathering phase Current operational procedures of the IT systems department

Finished products Current business cartographies Current software cartographies Current technical cartographies Current operational procedures of the IT systems department Listing of current skills and expertise in the IT systems department Current status evaluation Note on the technological opportunities Broad outline of the IT system strategy Urbanism rules

Outgoing conditions The finished products are validated. Roles needed to achieve the objectives • Project manager. • Study team. • Software design and development team. • Software operation team. • Business department. • User. • IT system department. • Quality manager. • Human resources department. • Study sponsor.

204

• • • •


Business project manager. Security expert. Technical expert. Facilitator.

Major risks • Poor evaluation of the workload. • Inconsistent responses to the questionnaires and/or surveys. • Lack of reliable documentation on the existing business, software and/or technical aspects. • Lack of reliable knowledge on the existing business, software and/or technical aspects. • Focussing on the current situation and forgetting "gaps". • Lack of documentation on the current operations procedures of the IT systems department. • Lack of documentation on the current skills of personnel in the IT systems department and skills reference framework. Skills • Reconfiguration of the business process (here only for its process modelling component). • Software architecture. • Technical architecture. • Software and technical audit. • Holding of discussions. • Drafting of reports. • Organisation. • Skills management. • Software use. Techniques • Process modelling. • Architecture modelling. • Audit. Tools Process, architecture, and data modelling tool.


205

Fig. 9.6 Activities diagram of the current enterprise architecture analysis phase

Special considerations • This phase is very important. In fact, any project, of any type whatsoever, is destined to achieve satisfaction of the needs or the resolution of problems (current or future). It is therefore essential to know how to assess the current situation, to be able to diagnose it and make a prognosis. It is particularly because of this status evaluation that the architecture scenarios for the future are built, which is the main objective of an urbanisation project. • It is based on existing knowledge by the IT systems department's design and development teams. In practice, in this phase, the project team firstly presents the design and development teams with the results obtained, then it "coaches" them during their research, and in particular while they are filling out the software applications files, then it collects and formats the information provided. Current cartographies Objectives • To become familiar with the current architectures as to their technical, software and business aspect. Presentation The cartography tasks for this activity includes all the Design of the conceptual models for each cartography. In Chapter 3, we offer a generic model for cartographies which can be used as they are or adapted to the terminology and the other features of each context.

206


Actions to be taken • Put together the current business cartography: - design the conceptual model for the business cartography; - collect the descriptive documents for the business architecture; - supply the cartography model; - produce the cartography. • Put together the current software cartography: - design the conceptual model for the software cartography; - define the block files; - collect the completed block files; - supply the cartography model; - produce the cartography. • Put together the current technical cartography: - design the conceptual model for the technical cartography; - define the technical files; - collect the completed technical files; - supply the cartography model; - produce the cartography. • Describe the current organisation structure. • Document the operational procedures of the IT systems department. • Make a list of the current expertise and skills in the IT systems department. Table 9.8 Incoming elements and finished products Incoming elements Current IT system

Finished products

X

Current business cartography

X

Current software cartography

X

Current technical cartography

X

Current operational procedures of the IT systems department

X

List of the current expertise and skills in the IT systems department

X


207

Table 9.9 Responsibilities Actor Project manager Study manager Study team Software design and development team Management committee Business department User IT system department Quality manager Human resources department IT system management committee Study sponsor Business project manager

Responsibility A R A A I C C C C A I C C

R: is Responsible for. A: is Actor (i.e. carries out the operation). C: is Consulted. I: is Informed.

Special considerations 1. The level of detail in the cartography description must not be the same for all the projects. Depending on the means and constraints established for this task, it may be a long and tedious task to provide the information for the models. Care should therefore be taken in determining (according to previous studies) the appropriate level of detail. 2. Although the tasks of the current cartographies activity only concern the designs of the current system, the conceptual model will also be used for the designing of the future software system, and must consequently be able to implement the concepts of future cartographies. 3. The existing functional cartography is not carried out. At the current level, it is best to start directly with the software architecture, which corresponds to part of the objective and which can be drafted fairly easily with the help of the design and development teams. Moreover, a current functional cartography would be of little use. 4. Get the help of the "experts". The quickest and most reliable way to put together the current software cartographies is with the help of the design and development teams in a methodological coaching logic. 5. The business cartography comprises: - the processes cartography; - the process models; - the macrodata model.

208


6. The description of the current organisation structure comprises: - the description of the current organisational structure of the business, the description of the key functions and the link with the functional software and technical architectures; - the description of the current organisational structure of the IT systems department; - the description of the existing strategies including the management of human resources and location. 7. The descriptions of the rules and procedures in force in the IT systems department, comprising: - the investment assessment procedures; - the risk analysis procedures; - the technical or business rules and standards relevant in the context. 8. The human resources department is asked for the list of skills and expertise in the IT systems department. 9. The current technical cartography can be modelled using deployment diagrams and/or UML components diagrams. Current status evaluation Objectives • To establish a diagnostic of the current status of the IT system. • To draw out the lines for improvement for the IT system. • To establish a diagnostic of the current running and skills in the IT systems department. Presentation The critical assessment of the existing IT system must allow for finding the main lines of improvement which must be applied with a view to the improvement of the IT system and the achievement of the strategic objectives. Similarly, the critical assessment of the running of the IT systems department must allow for the finding of the main lines of improvement which will allow for achieving the quality of operation looked for. Action to be taken • Audit the current business architecture: - draft discussion guides along the lines of the profile wanted to be studied; - hold discussions; - collect the information pertaining to the lines of the profile that is to be studied; - perhaps study the state of the art IT systems sector in the enterprise domain.


•

•

•

• •

209

Audit the current software architecture: - study the software cartography elements and determine the strengths and weaknesses of this architecture, in particular in relation to analysis grids; - find the best possible lines of improvement; - produce the audit report and have it validated by the computer department. Audit the code: - choose the code analysis tools; - choose the sampling criteria: - by type of processing: batch, real time, etc., - language used, - volumes, - etc.; - choose the criteria to be evaluated: - readability of the code, - modularity, - performance, - etc.; - analyse the sample; - produce the audit report. Audit the current technical architecture: - study the technical cartography elements and determine the strengths and weaknesses of this architecture, in particular in relation to analysis grids; - find the the best possible lines of improvement; - produce the audit report and have it validated by the computer department. Draw up the status evaluation for the operational procedures of the IT systems department. Draw up the status evaluation for current expertise and skills.

210


Table 9.10 Incoming elements and finished products

Current business cartography Current software cartography Current technical cartography Current operational procedures of the IT systems department Inventory of expertise and skills within the IT systems department Current status evaluation

Incoming elements x x x x

Finished products

x x

Table 9.11 Responsibilities Responsibility Actor A Project manager R Study manager A Study team I Software design and development team I Management committee Business department C C User C IT system department C Quality manager I IT system management committee Study sponsor C Business project manager C R: is Responsible for. A: is Actor (i.e. carries out the operation). C: is Consulted. I: is Informed.

Special considerations Audit of the business architecture: the aim of this action is to present the overall profile of the IT system, i.e. its notable characteristics. This summarising document may highlight some structural weaknesses which may give rise to possibles lines of improvement in the urbanisation strategy design activities. Depending on the context and the strategic lines previously highlighted, certain lines of study may be benefitted from. If the strategic contribution of the future IT system is critical, this task may constitute an entirely seperate study and include a study using state-of-the-art methods and strategic developments in IT systems on the market in the domain of the enterprise (state-of-the-art IT systems sector).


211

Technological opportunity analysis Objectives To obtain a preliminary outline of the conceivable technologies for the future software system. Presentation Using the knowledge acquired in the context of the enterprise, it is a matter of studying the technologies, products and materials on the market to evaluate the appropriateness of using them in the future software system. This study demands a very good knowledge of the state-of-the-art, both on the technical level and for methods and tools. Care must be taken not to succumb to the effects of fashion, but carefully study the advantages and disadvantages or risks for the enterprise in using any such technology. This study must take into account the existing system, both in terms of equipment and human terms. Depending on the profile of the computer technicians, it may be difficult to get them to accept radically innovative designs (e.g. using a multi-level architecture in an enterprise with a tradition of large systems). What goes with the change will be studied, such as the factors of cost and significant risk. Actions to be taken Technological opportunities study Table 9.12 Incoming elements and finished products Incoming elements Knowledge of the market, monitoring of technological development Note on the technological opportunities

Finished products

X

X

212


Table 9.13 Responsibilities Actor Project manager Study manager Study team Software design and development team Management committee Business department User IT system department Quality manager IT system management committee Study sponsor Business project manager

Responsibility A R A I I C I C C

I

C

I


Special considerations None. Strategic intent and directions definition Objectives • To define the main lines of the IT system strategy. • To define the strategic lines of urbanisation. • To define the development lines for the IT systems department. • To get the strategic lines validated by the management. Presentation This activity will establish the foundations of the urbanisation operation. It is at this stage that the following will be defined: • • •

the development orientations of the various architectures of the IT system; the rules that will allow for designing the future system, as well as the technical means that will be used; the orientations concerning the development of the operational processes and expertise and skills in the IT systems department.


213

Actions to be taken • Define the future technical architecture orientations: - study the suitability of the technological opportunities in relation to the needs of the future software system; - draw up and evaluate technical architecture scenarios; - verify the feasabilty of the scenarios; - get the management to choose a scenario. • To define the urbanism rules: - define the urbanism rules; - have the urbanism rules validated; • To define the tools orientations: - produce a note on the tools orientations; - have the tools orientations validated; • To determine the software package policy: - produce a note on the software package policy; - have the software package policy validated. • To define the future software architecture orientations: - study the suitability of the technological opportunities in relation to the needs of the future software system; - draw up and evaluate software architecture scenarios; - verify the feasabilty of the scenarios; - get the management to choose a scenario. • Define the organisation of the operational processes within the IT systems department. • Define the development lines for the expertise and skills. Table 9.14 Incoming elements and finished products Incoming elements Current status evaluation

X

Note on the technological opportunities

X

Note on the strategic objectives of the IT system

X

Finished products

Main lines of the IT system strategy

X

Urbanism rules

X

214


Table 9.15 Responsibilities Actor Project manager Study manager Study team Software design and development team Management committee Business department User IT system department Quality manager Human resources department IT system management committee Study sponsor Business project manager

Responsibility A R A I I C C C C A I C C


Special considerations Future technical architecture This action consists of proposing the main lines of the future technology of the software system in terms of: • • • • • •

machines; networks; DBMS; operating tools (programme transmission, network surveillance, etc.); development languages; etc.

These proposals are made based on what exists, the nature of the developments to be made to the IT system and diagnostics which can be carried out. It is possible that several choices can be envisaged for certain options with regard to technology. Several scenarios may be drawn up. In this case, the scenarios must be evaluated in terms of lasting quality, risk, etc., and be submitted for selection by the management.


215

The reasons for any decision taken in this context must be recorded and kept in a "technical architecture" file. Very diverse skills may be required when choosing the architecture (e.g. networks and programming languages). In this case, after the end of the activity, a review phase must be planned for the technical choices in order to ensure the coherence and feasibility of the whole. If possible, a prototype of the solution used may be made, particularly for verifying the compatibility of the versions of the products used. Human resources The human resources department takes part in the definition of the human resources policy of the IT systems department. Urbanism rules The urbanism rules are made up of generic rules and rules specific to the project. The generic rules must be implemented for any urbanisation project. They are suggested in Chapter 3. The specific rules are drawn up according to the state-of-the-art and the context of the project. Tools orientations This concerns choosing the cohesion criteria for the tools implemented in the future software system. Some tools have already been chosen in the context of the technical architecture and are directly responsible for contributing to this architecture. This task consists of determining the tools orientations, i.e. according to what controlling ideas the tools will be chosen by, for example: • • • •

preferred suppliers; multiplatforms; object orientation; etc.

Software package policy This is a matter of clarifying if the enterprise will have a policy of using software packages (or components) on the market, or rather develop the software applications that it needs internally.

216


This choice must take into account several parameters, for example: • • • •

Does the enterprise have the necessary staff and skills? Does it have the necessary development and test infrastructures? Do the market tools meet the needs of the enterprise? etc.

The choices made here will have impacts at the urbanisation planning level (training people in new development techniques, or with the chosen software packages, learning curves, etc.). 9.3.4. Strategy design Status of the phase in the process

Fig. 9.7 Strategy design


217

Objectives • To choose an urbanisation scenario. • To design the target business cartography. • To design the target functional cartography. • To design the target software cartography. • To design the target technical cartography. • To design the organisation design of the IT systems department. • To design the target operational procedures of the IT systems department. Presentation This phase will alow for the determining of the target development of the IT system and listing the broad outlines of the actions to be taken to gradually migrate towards the target. Table 9.16 Incoming elements and finished products Incoming elements Notes on the strategic objectives of the IT system Urbanism rules Current business cartography Current software cartography Current technical cartography

Finished products Target business cartography Target functional cartography Target software cartography Target technical cartography Target operational procedures of the IT systems department List of target expertise and skills in the IT systems department Outline of the migration plan design Comparison table of urbanisation scenarios Note on the choice of an urbanisation scenario

Outgoing conditions The IS/IT strategy is validated by the management.

218


Roles needed to achieve the objectives • Study manager. • Project manager. • Study team. • Business department. • User. • IT system department. • Quality manager. • Human resources department. • Study sponsor. • Business project manager. • Business expert. • Computer operator. • Security expert. • Technical expert. • Facilitator. • Expert in carrying out changeovers. Major risks • The strategy is guided by the technology. • Define an unrealistic target from the point of view of the performances expected. • Define an over-ambitious target. • Do not obtain a commitment from the managers. • Resistance to change on the business side and/or the IT systems department's side. • Lasting quality of the technical options. • Role of the information technologies misunderstood. Skills • Reconfiguration of the business process. • Organisation. • Functional architecture. • Software architecture. • Technical architecture. • Risk analysis. • Business strategy/IT system link. • Development of SI/IT strategy. • Carrying out of the changeover. • Holding of discussions.


• • •

Drafting of reports. Skills management. Software use.

Techniques • Process modelling. • Data modelling. • Architecture modelling. • Brainstorming. • Holding of meetings. • Workshop. • JAD (Joint Application Design). • Multi-criteria analysis grid (rosace). • Benchmarking. • Variance analysis. • SWOT (Strengths, Weaknesses, Opportunities and Threats). • Project planning. • What? Who? Where? When? How?. Tools • Project management tool (for the planning aspects). • Process, architecture, and data modelling tool.

Fig. 9.8 Activities diagram of the strategy design phase

219

22 0


Special considerations 1. The reasoning for all the decisions made as to choosing or rejecting any of the planned solutions must be stored in a useable and accessible form per criteria. 2. The process for defining the target is both participating and iterative. 3. For this phase, we proceed in an iterative manner to rapidly develop a preliminary vision of the target and to compare it to the assessment. Three iterations should allow for obtaining the result of a solid target and obtaining a consensus. 4. The business cartography includes the processes cartography, the process model and the model of the flows between processes. 5. The functional cartography. 6. The software cartography. 7. The technical cartography. Land Use Plan Objectives • To choose the urbanisation scenario that will be implemented at the time of the urbanisation operation. • To design the target business architecture of the IT system. • To design the target functional architecture of the IT system. • To design the target software architecture of the IT system. • To design the target technical architecture of the IT system. Presentation As an urbanisation solution has to be a compromise between different factors (in particular, technical and financial), it will sometimes be necessary to construct several scenarios that will impact differently on one or other factor (e.g. maintenance costs, operating costs, etc.). The level of detail for the scenarios will be determined by an "approach by stakes" (depending on the cost ratio of implementation/gains expected). It may vary anyway from one block to the next depending on the importance of each of them.


221

Actions to be taken • To define the urbanisation scenarios: - design the urbanisation scenarios. • To compare the urbanisation scenarios: - choose the scenario evaluation criteria; - evaluate and compare the scenarios; - eliminate the less good scenarios so as to reduce the workload of the next activity "performance forecast". • To design the target business cartography. • To design the target functional cartography: - design of breakdown into blocks (zones, districts, plots); - definition of the plug-ins. • To design the target software cartography. • To design the target technical cartography. Table 9.17 Incoming elements and finished products Incoming elements Broad outline of the IT system strategy Diagram of the target enterprise Current business cartography Current software cartography Current technical cartography Current status evaluation Model of the strategic objectives of the IT system Note on the strategic objectives of the IT system Note on the technological opportunities Urbanism rules Target business cartography Target functional cartography Target software cartography Target technical cartography Outline of the migration plan design Comparison table for urbanisation scenarios Target operational procedures for the IT systems department List of target expertise and skills in the IT systems department Note on the choice of an urbanisation scenario

Finished products

X X X X X X X X X X X X X X X X X

X

X

222



Responsibility A R A I I C I C C

I

C

I


Special considerations • Data aspect: each urbanisation scenario should have the "data coherence" aspect attached to it to process. According to the generic urbanisation rules, each given macro data is allocated to a block; in theory, this involves redesigning the data models to make sure that an item of data only appears in one place in the system. The scenarios drawn up should take into account the different operations involved by these rules, for example: - the design of new models; - the maintenance plan; - the data migration plan; - the migration and tests. • Depending on the stakes of the urbanisation, different scenarios may offer different levels of establishing coherence, which will allow for choosing one option, depending on the aim looked for vis-a-vis costs and risks incurred. • Experience shows that an efficient migration is carried out through an iterative approach. Most often, three iterations of gradually shortening durations are needed. • The definition of the versions is particularly difficult to do, with numerous parameters to be taken into account (priority of software applications from one to another, design of intermediary versions, etc.).


•

223

The technical cartography can be modelled using component and/or UML deployment diagrams.

Performance forecast Objectives To evaluate the performances expected from the urbanisation scenarios. Presentation This phase is to support the choice of urbanisation scenario. It provides the necessary perspective in relation to performance. In fact, a software architecture, as attractive as it might appear on the conceptual level, is nothing if it is not technically achievable and if it is incompatible with the performance needs. Actions to be taken • Determine the scenario number before making the prototype. • Construct a prototype for each scenario selected. • Evaluate the performances for each scenario. Table 9.19 Incoming elements and finished products


Incoming elements x

Scenarios envisaged

x

Target software cartographies of the different scenarios

x

Target technical cartographies of the different scenarios

x

Performance evaluation report

Finished products

x

224



Responsibility A R A A I I I C C I C I


Special considerations The aim of the prototypes is: • •

to evaluate the future software architecture implemented on the future technical architecture according to the methods proposed for each scenario; to evaluate the intrinsic difficulties for implementing each solution (technical difficulty, complexity, etc.).

This involves having a critical outlook on the scenarios drawn up, in particular in terms of performance (exchange volumes, response time, etc.). Performances are to be judged, in particular, in relation to the needs expressed on some of the key management events to be processed by the systems. This activity may be carried out using metrics drawn from similar experiences, or by constructing a prototype with the most critical blocks. This activity should be carried out more or less in parallel with the previous activity. It would in fact be pointless to finalise a damaging scenario on the level of its performance.


225

The following should try to be simulated by way of an example:

• • • • •

the data flows; the message exchanges; the volumes of data and access to the DBMS; the network traffic; etc.

As the design of the future IT system has not been completed, the prototypes will be outlined according to the general principles. For example, the workload tests on the databases may be carried out by means of a workload test tool that generates multiples requests; the same can be done for the network flows. 1. Predicting performance does not always need a prototype. 2. The number of prototypes must be limited so as the workload remains reasonable. 3. The objectives and limits of each prototype must be clearly defined. Organisation design Objectives • To design the target operational procedures of the IT systems department. • To determine the target expertise and skills needed in the IT systems department. Presentation This activity allows for breaking down the measures within the IT systems department which are essential for the migration to the set target. Actions to be taken • Reconfigure the operational procedures of the IT systems department. • Model the target operational procedures of the IT systems department. • Define the expertise and skills needed to achieve the target. • Determine the gap in relation to current expertise and skills. • Design the plan needed to bridge this gap.

226


Table 9.21 Incoming elements and finished products Incoming elements Current operational procedures of the IT systems department List of the current expertise and skills in the IT systems department Target functional, software and technical cartographies Main lines of the IT system strategy Target operational procedures of the IT systems department Target expertise and skills for the IT systems department

Finished products

X

X

X

X X

X

Table 9.22 Responsibilities Actor Responsibility Project manager A Study manager R Study team A Software design and development team C I Management committee I Business department I User IT system department C Quality manager C Human resources department A IT system management committee I Study sponsor C I Business project manager R: is Responsible for. A: is Actor (i.e. carries out the operation). C: is Consulted. I: is Informed.

Special considerations The human resources department is obviously first in line for defining the target expertise and skills for the IT systems department.


22 7

Evaluation of scenarios and choices Objectives To choose the urbanisation scenario. Presentation This activity should only be carried out if several scenarios have been constructed. •

• • •

To determine the relevant choice criteria and weigh them against: - qualitative criteria; - quantitative criteria; - financial criteria. Construct comparison tables to help guide the choice of scenario. Make (or have made) the choice of scenario to use. Document the reasons for this choice.

Actions to be taken Evaluation of scenarios and choices. Table 9.23 Incoming elements and finished products Incoming elements

Finished products

X

X

Comparison table of urbanisation scenarios Note on the choice of an urbanisation scenario

X


Responsibility A R A C C C C C C I C C


228


Special considerations The comparison table for urbanisation scenarios, created at the time of the Land Use Plan activity, is updated, in particular for adding to it the conclusions as to performance from the performance forecast activity and to finalise the whole thing. 9.3.5 Migration plan design Status of the phase in the process

Fig. 9.9 Migration plan design

Objectives • To define the scheduling and principal due dates for the migration to the target. • To set up the plan's follow-up structure.


229

Table 9.25 Incoming elements and finished products

Incoming elements

Finished products

Future business, functional, software and technical cartographies Listing renovation tasks and putting them into a hierarchical structure Target operational procedures of the IT systems department Target expertise and skills for the IT systems department

Planning of the urbanisation operation Note on the organisation of the urbanism focus group Definition of the performance indicators Procedures for producing performance indicators Procedure for updating the IT system reference framework Plan for carrying out the changeover

Presentation This phase will basically consist of scheduling and planning activities. The plan for carrying out the changeover will also be extensive. Outgoing conditions The deliverables are validated. Roles needed to achieve the objectives • Study manager. • Project manager. • Study team. • Business department. • User. • IT system department. • Software design and development team. • Quality manager. • Human resources department. • Study sponsor. • Business project manager. • Expert in carrying out changeovers. • Business expert. • Computer operator. • Security expert. • Technical expert.

230


Major risks • The business changes precede the implementation of the IT system strategy. • Conflict of the evaluation criteria. • Purchasing process or statutory restrictions. • Time needed for assessing the business case. • Difficulty in measuring the benefits. • Sponsorship becoming fragmented. • Lack of appropriate skills. • Too many people wanting to be involved too early in the process. • Lack of communicators in the organisation. • Differing interpretations of the strategy between the business and IT systems departments. • No real allocation procedure. Skills • Project management (for the component planning). • Carrying out of the changeover. Techniques Planning. Tools Project management tool (for the planning aspects).

Fig. 9.10 Activities diagram of the migration plan design phase


231

Special considerations 1. Skills to be gathered in the project team. The head of the project will have final say in this phase. However, he will be helped by the technical and software applications architects to make his choices. 2. Participation of the user. Users are directly involved. Depending on the resources, costs and deadlines, planning and scheduling can easily be adapted. 3. Main reviews carried out. The action plan must be backed by everyone, and especially the users. 4. The evaluation of the work (workload in man-days and total) envelope must be obtained to tell the experts. 5. The updating of the IT system reference framework is important. The cartographies produced during the study allow for formalising the knowledge of the existing IT system and thus its control, analysis of the impacts of the planned developments and the quicker training of new staff. It is therefore important to keep this information for future reference. Migration plan completion Objectives • To confirm the priority redevelopments. • Accurately work out the main action plans and actions involved which should be carried out in the short, medium and long-term in order to implement the urbanisation plan. Presentation This phase involves specifying the outline of the migration plan design for the scenario used, which was prepared during the Land Use Plan activity. Among the action plans could be listed: • • • • • •

the investment and hardware installation plan; the software application development, purchasing and software package particularisation plan for the migration of data; the functional and technical migration plan (in particular, if it is a staggered multi-site migration); the human resources plan (outline, training, subcontracting, computer management), carrying out of the changeover; the test plans (new integration, performance, etc.); etc.

232


Actions to be taken • Confirm the definition and hierarchy structure for redevelopments: - identify the priorities; - identify the incompatibilities; - provide for intermediary solutions; - "version" all the components of the future software architecture and set out what functions are provided by each version; identify the interfaces and gateways. • Confirm the definition of the versions: - define the versions; - have the list of versions validated by the management. • Carefully define and arrange the implementation. Table 9.26 Incoming elements and finished products Incoming elements Urbanisation scenario used Planning of the urbanisation operation

Finished products

X

Table 9.27 Responsibilities Responsibility Actor A Project manager R Study manager A Study team A Software design and development team I Management committee C Business department C User C IT system department C Quality manager A Human resources department I IT system management committee Study sponsor C C Business project manager R: is Responsible for. A: is Actor (i.e. carries out the operation). C: is Consulted. I: is Informed.

X


233

Special considerations 1. The establishing of hierarchies for the redevelopments may take into account parameters other than those directly inherent to the restrictions of the architecture. For example, the management may impose certain priority applications on the redevelopment because they will be the display window of their future system. In other cases, some priority applications will take longer to install than those that need their services. The task of defining the redevelopments and putting them into a hierarchical structure should include managing the incompatibilities and provide for intermediary solutions. The management of versions (versioning) is an important part of this task. Several versions must in fact be provided for one software application in order to gradually install the functions or take into account redeveloped new software applications. 2. A version is a configuration of the software system or a sub-set of the software system, which is suitable for providing a coherent set of functions in the IT system. A version is a set of blocks which can operate together: - all the necessary functions are present (some may be in an intermediary version of the target version); - all the necessary data is present. The description of a version comprises the list of the blocks from which it is made, in a given version and on a given date. 3. The level of detail of the planning must be higher for the route to the first version, then a little lower for the route to the second version, and fairly macroscopic after that, both because, generally speaking, a plan that is too accurate over too long a term does not contribute too much, and because in the case of a target aligned to the strategy, it is known that it will have to be adjusted, bearing in mind the speed of the changes to the environment for an enterprise. Monitoring strategy design Objectives • Define and install the monitoring strategy design. • Define and install the monitoring management entity.

234


Presentation The purpose of this task is to define the processes by which the urbanisation project will be "brought to life", as for example: • • • • •

the monitoring indicators; the indicators collection and analysis strategy; the methods of adjusting the urbanisation plan according to the results obtained; the possible methods of collaboration with the customer for extras; etc.

The management procedures for the cartography must allow for maintaining the coherence of the information stored in the existing cartographies descriptions. They must use tools. Some types of roles must be provided to carry out this activity which has a lifetime at least equal to that of the urbanisation project (some roles may last longer). For example: • • • • • • •

•

functional cartography manager; software cartography manager; business cartography manager (may be carried out by the same person as the software cartography); technical cartography manager; version manager (one person may be responsible for several versions: provide the coordination, monitor the planning, etc.); data administrator; components architect (defines the blocks, interfaces, services, ensures the inter-applications coordination etc.); etc.

Actions to be taken • Define the monitoring indicators. • Define the procedures for producing the performance indicators. • Define the cartography management procedures.


235

Table 9.28 Incoming elements and finished products Incoming elements

Finished Products

Note on the organisation of the urbanism focus group

x

Definition of the performance indicators

x

Procedure for producing the performance indicators

x

Procedure for updating the IT system reference

x

framework__

Table 9.29 Responsibilities Actor Responsibility Project manager A R Study manager Study team A Software design and development team I I Management committee Business department I I User IT system department A Quality manager C IT system management committee I Study sponsor C I Business project manager R: is Responsible for. A: is Actor (i.e. carries out the operation). C: is Consulted. I: is Informed.

236


9.3.6 Publication of the strategy Status of the phase in the process

Fig. 9.11 Publication of the strategy

Objectives • To obtain support for the target and the migration plan design. • To obtain the validation of the summarising document for the IT system strategy. Presentation This phase consists of gaining support for the programme for migration to the target from the senior management and projects backers. Table 9.30 Incoming elements and finished products Incoming elements Finished products from the previous phases

Finished products Summary file for the IT system strategy

Outgoing conditions Validation of the summary file for the IT system strategy. Roles needed to achieve the objectives • Project sponsor. • Study manager. • Project leader. • Quality manager. • Business project manager.


23 7

Major risks • Non-implementation of the target. • Duration of the purchasing process. • The IT (Information Technology) undermines the strategy. • Strategy not effectively communicated or misunderstood. Skills • Project management. • Drafting of report. • Business strategy/IT system link. Techniques No special techniques. Tools No particular tool. Activities diagram This phase is not broken down into activities. Special considerations The summarising file for the IT system strategy covers the following points: • • • • • • • • • • •

introduction; summary for the management; business strategy; summary of requirements; evaluation of the current system; summary of the software architecture, technical architecture and organisational structure; plan of the whole migration programme; migration strategy; risk and risk reduction strategy; cost/benefits analysis; options considered and rejected.

238


9.3.7 Strategy review and update Status of the phase in the process

Fig. 9.12 Strategy review and update

Objectives To keep the target and migration plan design properly aligned to the strategic objectives. Presentation This phase consists periodically, or at the time of a major internal or external event, of checking the alignment of the target in relation to the business strategy as well as the relevance of the migration plan design. This involves: • • •

• •

evaluating the benefits achieved in relation to the plan; evaluating the progress of the projects set out in the plan and in progress; identifying the environmental changes (market, technology, customer, internal skills and resources) since the previous update, and evaluating the impact of these changes; defining the LUP updating process. At the end, all the deliverables may need to be updated; carry out process and produce the update.

Table 9.31 Incoming elements and finished products Incoming elements Update requirement

Finished products Variable according to the extent of the changes and stages already completed in the migration plan design


239

Outgoing conditions Variable according to the extent of the changes and stages already completed in the migration plan design. Roles needed to achieve the objectives Sub-sets of roles needed for the drawing up of the first LUP according to the nature and extent of the changes. The IT systems management committee plays the key role in deciding the major updates of the target and consequently, the migration plan design. Major risks • Sub-sets of risks needed for the drawing up of the first LUP according to the nature and extent of the changes. • Non-updating of the business strategy. • The IT system strategy is reduced to its most simple expression in scope and complexity and, consequently, no longer meets the business objectives. • Inability to measure the benefits. Skills Sub-sets of techniques needed for the drawing up of the first LUP according to the nature and extent of the changes. Techniques Sub-set of techniques useful for the drawing up of the first LUP according to the nature and extent of the changes. Tools Sub-set of tools needed for the drawing up of the first LUP according to the nature and extent of the changes. Activities diagram This phase is not broken down into activities.

240


9.4 Summary of the finished products Phase/Activity PLANNING OF THE STUDY


BUSINESS STRATEGY GATHERING

Model of strategic business objectives Note on the business development lines Diagram of the target enterprise Model of the strategic objectives of the IT system Note on the strategic objectives of the IT system Traceability matrix of the business/IT system objectives Diagram of the target enterprise

Understanding the enterprise business strategy

Model of the strategic business objectives Note on the business development needs Diagram of the target enterprise

Future business vision definition

Model of the strategic objectives of the IT system Note on the strategic objectives of the IT system Traceability matrix of the business/IT system objectives

CURRENT ENTERPRISE ARCHITECTURE ANALYSIS

Current business cartography Current software cartography Current technical cartography Current operational procedures of the IT systems department Listing of current skills and expertise in the IT systems department Current status evaluation Note on the technological opportunities Main lines of the IT system strategy Urbanism rules


241

Phase/Activity Current cartographies

Finished products Current business cartography Current software cartography Current technical cartography Current operational procedures of the IT systems department List of the current skills and expertise in the IT systems department



Technological opportunity analysis

Note on the technological opportunities

Strategic intent and directions definition

Main lines of the IT system strategy Urbanism rules

STRATEGY DESIGN

Target business cartography Target functional cartography Target software cartography Target technical cartography Target operational procedures of the IT systems department List of target expertise and skills in the IT systems department Outline of the migration plan design Comparison table of urbanisation scenarios Note on choice of urbanisation scenario

Land Use Plan

Target business cartography Target functional cartography Target software cartography Target technical cartography Outline of the migration plan design Comparison table of urbanisation scenarios

Performance forecast

Performance evaluation report

Organisation design

Target operational procedures of the IT systems department List of target expertise and skills in the IT systems department

242

The Enterprise A rchitecture IT Project

Phase/Activity Evaluation of scenarios and choices

Finished products Comparison table to scenarios Note on the choice of an urbanisation scenario

MIGRATION PLAN DESIGN

Planning of the urbanisation operation Note on the organisation of the urbanism focus group Definition of the performance indicators Procedure for producing the performance indicators Procedure for updating the IT system reference framework

Migration plan completion

Planning of the urbanisation operation

Monitoring strategy design

Note on the organisation of the urbanism focus group Definition of the performance indicators Procedure for producing the performance indicators Procedure for updating the IT system reference framework

PUBLICATION OF THE STRATEGY

Summary file for the IT system strategy

STRATEGY REVIEW AND UPDATE

Variable according to the extent of the changes and stages already completed in the migration plan design

Part IV

The dynamic of the actors


Chapter 10

The participants and their roles

10.1 The actors and bodies 10.1.1 The actors The actors and their roles in an IT system urbanisation project are shown in the following table. It should be noted that this involves actors, i.e. role type, and that an actor therefore does not necessarily mean a position in the enterprise. On the other hand, each role must be allocated to a person. Table 10.1 Actors: definition and roles Actors Applications manager

Definitions The applications manager manages the life-cycle of a system, after a first version has been installed. He determines whether or not a maintenance or development request must be processed immediately, or if it can wait until the next development cycle, or if it should be rejected.

BPR consultant

The BPR consultant describes, models and may reconfigure the enterprise or organisation's processes.

Business department

Department within the enterprise or organisation, in charge of part of its operational activity.

Business expert

The business expert has full understanding of the users activity. He takes part in the study.

246


Actors Business project manager

Definitions The busines project manager comes from a user service. It is the key user who will be be able to take, in the context of the study, all the decisions pertaining to the characteristics of the processing system for the information studied. His mission is to assist the project leader. He coordinates the work placed under the responsibility of the users. Depending on the size of the system studied and the number of business organisations involved, he can have several other users join the study. They make up the user working group.

Computer operator

The operations manager provides, in particular, an objective view of the existing system.

Design and development teams

Team in charge of design and development (new developments, development maintenance, corrective maintenance) for the IT system. These teams bring their knowledge of the existing system and their vision of the action plan to migrate to the target. They are also very useful in the testing of the target.

Expert in carrying out changeovers

The consultant carrying out the changeover produces the users' accompanying plan.

Facilitator

Designates a participant in a project in charge of coordinating the working groups and guaranteeing the method for carrying out an urbanisation project; the qualities required include verbal communication in extended working groups, coordination of teams and the summarising of the work of the groups.

Human resources department

Human resources department.

IT systems department

Department in the enterprise or organisation in charge of the IT system.

Project manager

The project manager is appointed to ensure that the objectives assigned to the study are successfully completed. He is responsible for the coherence and appropriateness of the choices made in the course of each phase of the study.

Quality manager

The quality assurance manager carries out the development and coordination of the quality assurance actions.

The Participants and their Roles

24 7

Actors Security expert

Definitions The security manager carries out the development and coordination of the actions pertaining to the security of the information processing systems.

Software architect

Responsible for the choices, in terms of the structure of IT system, which allow for the construction of a set of software blocks whose main characteristics are the ability to be developed, their reuseability, easy maintenance and performance.

Study manager

The study is placed under the responsibility of the study manager to successfully achieve the objectives assigned. The study manager is the sole visible participant at the time of the success or failure of the study. He is the individual who is responsible for the day-to-day coordination of the project and provides the general vision of the project.

Study sponsor

Manager from the management committee in charge of promoting the progress of the urbanisation study: allocation of human and financial resources.

Study team

The project team is made up of people placed under the hierarchical and/or functional responsibility of the head of the study project. It works with him to achieve the objectives of the study, the number and qualifications of its members varies in the course of the study phases.

Technical architect

This person brings all the technical means and logical descriptions possible to support the IT system. The technical architecture results from a general set of issues expressed by the stakes, objectives, orientations and restrictions.

Technical expert

Defines the rules and standards for using the various tools and infrastructures chosen for the IT system.

User

Any person likely to take part in the definition or implementation of the Land Use Plan, validate its results or merely to benefit from it.

248


10.1.2 The bodies As with any project, an IT system urbanisation study needs a certain number of bodies so as to control it and thus lead it to a successful conclusion. These bodies are shown in the following table. It should be noted that the study steering committee and the operational monitoring committee are transient bodies whose life-time is the same as that of the study. The other bodies are permanent bodies. It is the urbanism focus group and the IT systems management committee which ensure the proper implementation of the plan defined during the study phase and which carries out the updates necessary for the target and migration plan design. Table 10.2 Bodies: definitions and roles Bodies Management committee of the enterprise or organisation IT system management committee

Definitions This is the supreme body for guiding the work pertaining to the development and evolution of the enterprise, ________ This is the supreme body for guiding the work pertaining to the development and evolution of the systems. In an organisation, there is therefore only one management committee for the IT system. It is this committee that approves the general orientations of a technical, functional and financial nature (blueprint. software layout), allocates the budget by management domain, ensures the development and coordination at the highest level of the options used in the enterprise. It decides on updates to the urbanism plan and migration plan design.


Bodies Study steering committee

Operational monitoring committee

Urbanism focus group

249

Definitions The responsibilities of the steering committee are as follows: • To have a launch note validated and distributed by the head office. • To provide all the guidance necessary to the study team to successfully carry out its mission within the planned schedule. • To resolve, where necessary, any difficulties linked to the availability of resources. • To provide top level arbitration. • To validate the deliverables. The committee is, in principle, chaired by a user who is the most senior manager concerned by the scope of the study. This is the development or promotions manager. A steering committee corresponding to each key phase of the study is generally provided for when planning the study phase: • Business strategy gathering. • Current enterprise architecture analysis. • Strategy design. • Migration plan design. Apart from the study, a quarterly basis is generally appropriate. The purpose of the study is validated by the steering committee and ratified by the IT systems management committee. The responsibilities of the monitoring committee are as follows: • To assess any difficulties encountered. • To manage action plan needed to resolve these difficulties. • To determine the appropriate solutions and possibly inform the steering committee if it considers it necessary. • To organise the steering committees. This committee meets frequently (generally once a week) but has an intentionally limited duration (typically a maximum of 1 hour). It defines the actions to be implemented to deal with the difficulties encountered and monitors their progress, but it does not deal with basic problems. The urbanism focus group keeps the IT system within the established trajectory. Its responsibilities are as follows: • Processing applications for building licences. • Conformity control of systems delivered in relation to the building licence. • Maintenance of the IT system reference framework. • Production offrameworkdocuments. • Project management and ownership consultation. • Urbanism rules updates.

250


10.1.3 The roles of the actors at the time of the study The roles of the various actors and bodies in the course of an IT system urbanisation project are summarised in the following table according to RACI logic. In the table, R: is Responsible for. A: is Actor (i.e.carries out the operation). C: is Consulted. I: is Informed.

Table 10.3 Roles of actors and bodies


253

10.2 Skills, techniques and tools 10.2.1 Skills The skills needed to successfully complete an IT system urbanisation project are many: • • • • • • • • • • • • • • • •

project management; risk analysis; quality management; development of IS/IT strategy; business strategy/IT system link; reconfiguration of the business process; organisation; functional architecture; software architecture; technical architecture; software and technical audit; carrying out of the changeover; software use; holding of discussions; drafting of reports; skills management.

254


10.2.2 Techniques The following techniques are frequently used in IT system urbanisation projects and are referred to in the approach given in Chapter 9: • • •

• •

•

• • •

brainstorming; holding of meetings; JAD (Joint Application Design). Put simply, JAD is a type of work meeting designed to facilitate the changing of opinions and theoretical ideas into agreements and decisions for actions. The basis of JAD is the setting up of work meetings to define the detailed requirements of each of the processes or sub-systems. The participants in each of these work meetings are chosen according to their expertise or knowledge of one or more aspects of the new system. The results of each of these work meetings are collected by one of the participants and are consolidated with the results from other meetings to ultimately provide a document defining the needs of the system. The main problem for this consolidation, which is carried out outside the work meetings, is to define a general view of the future system that includes all the different points of view. This summary may highlight any contradictions. The risk is to end up with a document which does not satisfy any of those involved in the work meetings; workshops', Ishikawa diagram. The Ishikawa diagram, also called a cause-effect diagram or fishbone diagram serves to present the causes and effects that follow. The first element is a central arrow corresponding to the main effect, while the causes linked to this type of effect are represented by arrows pointing towards the central axis (arrow indicating the main effect). The arrow indicating the cause is in its turn considered as being an effect, and the causes bringing about this effect are represented by arrows pointing towards the cause/effect arrow in question, etc.; RACI. Technique allowing for specification of the roles of the actors in a process. R indicates that the actor is responsible for the activity, A that the actor is carrying out the activity, C that the actor is consulted at the time of the execution of the activity and / that the actor is informed at the time of the activity; multi-criteria analysis grid (rosace); risk analysis; WWWWH. Technique allowing for the resolution of a problem or the defining of an action plan to resolve it. It consists of posing the following five questions: What? Who? Where? When? How?


•

• • • • • • • •

255

SWOT. Technique allowing for the critical analysis of a strategy or processs. It consists of posing four questions (What are the strengths? What are the weaknesses? - What are the opportunities? - What are the threats?; balanced score card; benchmarking (test bank); process modelling; data modelling; architecture modelling; audit; variance analysis; project planning.

These techniques are the subject of fairly abundant writings, to which the reader may, if necessary, refer. 10.2.3 The tools The tools used in any IT system urbanisation project are of the two following types: •

•

project management tool. An IT system urbanisation project must, as with any project, have a project plan and follow-up. As this tool is a standard tool independently from the characteristics of this type of study, it is not necessary to describe it in more detail; process, architecture, and data modelling tool.

The methodological approach and the expertise of the external and internal participants are the basic factors of success for urbanisation studies. However, tooling is also a factor of primary importance during the mission, then to bring the reference framework put together during the study into being. For this type of project, it is therefore essential to use a software engineering tool on the market. Here it is not a question of rushing into a comparison of tools on the market since there are institutes that are specialised in this domain but, more modestly, to define the contributions and functions expected from this type of tool.

256


The ideal tool should be based on a real integrated, reliable, flexible and extendable reference framework It must cover the process modelling and simulation and the modelling of the architectures and support UML so as to make the link with the design and development projects using IT system components (i.e. the construction of a property planned in the town plan). Process modelling and simulation functions This module of the tool must allow for: • • • • • •

defining the business models with all the participants involved and guaranteeing coherence; helping to quickly and easily detect any potential improvements to the existing processes; quickly constructing the new processes; comparing several organisation scenarios: to quantify the human and computer resources needed, estimate the duration of the processes; guiding the user through all the phases of the project by supporting the methodological approach via intuitive graphics tools; guaranteeing the sharing and coherence of the information.

Architecture modelling functions This module of the tool must allow for: • • • • • • • • • • •

supporting the urbanism concepts of the methodology; presenting a complex and extensive IT system; taking into account the integration of the software applications; showing the functional breakdown of a software application; integrating the internal dimension into the software architecture; formalising the flows of information; describing a functional architecture; describing a software architecture; describing a technical architecture; referencing external information; analysing the impacts of the architecture modifications.

Do we have to use UML? Firstly, it should be noted that the methods and techniques presented in this book are not linked to any modelling technique and are probably applicable whatever the modelling technique used.


25 7

The Unified Modelling Language has become a market standard after having been standardised by the OMG in 1997. The evolution towards UML was certainly slow, but at the same time, real and inevitable. Moreover we should be pleased. It is in fact the first time there has been a worldwide standard in terms of a modelling technique, thus leading to an extremely abundant and competitive availability of software engineering tools, which allows for a real competitive supply. Moreover, the respecting of UML brings a good level of interoperability between design tools, which, together with the low prices (in comparison with design SEWs of ten years ago), makes the choice of tool much more flexibleand thus much less strategic than before. Some have justifiably remarked that UML: • • • •

is perfectible; does not offer much for the validation of the coherence of the models; has a chronic weakness as to modelling the organisation; offers no instructions for use.

All this is true. But UML evolves and is clarified or enriched, and various instructions for use are offered by different software editors or IT services companies. The real questions are therefore, with regard to the IT system urbanisation project: • •

Can we do everything with UML? Is it the best way of proceeding?

As for the first question, the response is clearly positive. Modelling processes in UML Processes in UML can be modelled using one of the following diagrams: • • •

the use case diagram; the sequence diagram or its twin brother, the collaboration diagram; the activity diagram.

On the other hand, we must recognise that these models allow for carrying out process models but do not result in clearer models and therefore those that are more "easily validated" by the peole concerned. The modeller must get round certain difficulties, and in particular:

258

•

•

•


the sequence diagram (or the collaboration diagram) which usually corresponds to a scenario with no prior conditional alternatives, each of them corresponding to a different scenario, and thus a different diagram. So it is essential to find a graphic or textual astuteness (not interpreted by the tool) to get around this problem. The classes concerned with the progresss of each activity must also be identified; the use case diagram allows for the representing of each activity of a process as a use case and shows who does what. On the other hand, it is difficult to show (without using a text or graphic which cannot be interpreted by the tool) the sequence of activities. This diagram also allows for the showing of all the processes on the same diagram, but it may soon become unreadable should there be several actors communicating with each process. Finally, as with the sequence and collaboration diagrams, it also necessitates the identification of the classes concerned with the progress of each activity; the activity diagram is the one that allows, on the graphic plan, for getting closest to a process models recommended in the method proposed. On the other hand, there are differences in current implementions of a UML tool to others.

Modelling of architectures in UML For the modelling of architectures, the key concepts of the recommended method (zones, districts, plots) may be implemented via the creation of package stereotypes. The functional and software architectures may be represented by class models in which the zones, districts and plots are represented by package stereotypes corresponding to the flows between packages via associations (at the cost of a significant semantic diversion). As for the technical architecture, it can be modelled with the aid of deployment and component diagrams which will allow for fewer graphic possibilities than an automation tool for providing support to the presentation but which allows for remaining in the tool. Conclusions on the tool We have demonstrated that a design tool from the market supporting UML allows for the successful conclusion to this type of project, especially as its implementation of the activity diagram allows for the best modelling of the processes.


259

The alternatives to using a UML tool are: •

•

the use of a tool dedicated to the modelling of organisations but that does not, or only slightly, supports (i.e. offering an interface) UML. This alternative is interesting if the project is basically centred around a reconfiguration of the process. On the other hand, it presents the major inconvenience of leading to two reference frameworks, one decribing the organisation, the other the software system supporting this organisation; the use of a modelling tool integrating, in addition to UML, and within the same metamodel, concepts and models specifically adapted to model the organisation and processes. This is before me ideal solution to successfully complete an IT system urbanisation project. In fact, this sort of tool has an essential advantage for process modelling and architecture modelling compared to the other tools that only support UML. The models proposed are much clearer and therefore "validatable" (in particular for the validation of process models with the owner) than if they were produced in UML, while offering a link, managed in the reference framework, between the concepts handled in these models and the UML concepts handled in the design and development of any systems that may follow. In fact, the tool offers a single software suite, the functions of tools dedicated to modelling the processes and functions of an SEW (Software Engineering Workshop) UML, which avoids the problems of interfacing betwen the two types of tools.

Finally, in choosing a tool for a given urbanisation project, obviously you must take into account any tools already used within the enterprise or organisation and the overall economic status (acquisition, training, learning curve, maintenance) of the choice of SEW.

10.3 Take a new approach to the relationship between project ownership and project management 10.3.1 Background The relationship between project ownership and project management has evolved over time, in the search for a balance that has never really been achieved. There are four main periods in the history of these relationships:

260

• • • •


the reign of computers; the infancy of project ownership; the coming of age of project ownership; the transition towards the insight era.

The first period, which covers the two decades of the 60s-70s, was characterised by the computerisation of repetitive administrative tasks and the lack of real strategic thought. It was also the age of ultra-powerful computers which were given all the projects and which benefitted from the lack of user computer culture to reign unchallenged. In reality, there was no real project ownership. It was the reign of computers. The second, which corresponds to the middle of the 1980s, was characterised by the setting up of ownership by project. Before the failures of certain computer projects, business departments no longer being able to blame the failures only on computers, became aware of the need for a real involvement with critical projects. These project ownerships were set up for projects of user project managers or user applications directors. Depending on the organisations and culture of the enterprises and/or organisations, the ultimate consequence of project ownership/project management may incline one way or the other. The project owner of a project was schematically responsible for drawing up the specifications, managing user resources and acceptance of the software applications. This was the infancy of project ownership. The third period, which covers the middle of the 1990s, corresponds to a growing awareness of the need for an overall vision, and no longer the project by project approach of project ownership. This growth in awareness was basically caused by the computerisation of all areas of enterprises or organisations. It was at this time that IT systems departments suceeded computer departments, that the IT system management committees were created and that power as regards the IT system often swung from the business department side. This was the coming of age of project ownership. The fourth period, which started at the end of the 1990s, was the era of the collaborative enterprise. It was the start of the transition towards the insight era, at least it was hoped so.


261

Gradually, the classic diagram was left behind, in which the project manager suggested something about something that the project owner had to decide on by the differences. The classic distinction between project owner and project manager does not remain in the planning of the implementation of the urbanisation plan and its various updates. During the planning, there is only one study team with all the skills necessary, i.e. both business skills and organisational skills, to carry out the changeover and computing. This is fundamental, and if this condition is not met, it is nearly inevitable that we will go back to the clasic blueprint type study. 10.3.2 The new challenge: the transition towards the insight era Consequently, a new challenge has appeared for this type of study. This is in fact the time to reinvent the link-up of jobs between project ownership and project management, in theory for the duration of the study, but will last much longer because, in the event of success, nothing else will do. This concerns at last moving on from apartheid to cohabitation. Working together, the project owner and project manager understand each other better and, consequently: • •

jointly define the best solutions for the enterprise or organisation; pass the buck less in the event of difficulties.

The IT systems department develops and provides the software applications while the business departments define their resources, including information resources, and ensure they have the right tools at the right time. The project management does not have the monopoly of the creation of value in the IT system! Project ownership is often broken down into strategic project ownership and operational project ownership. The strategic project ownership, generally carried out by an "IT systems management committee", deals with the business vision. The IT systems management committee is a decision-making body that meets with the business manager and his main associates as well as the heads of the project management.

262


Meeting every two or three months, it makes decisions on: • • • •

the orientation of the IT system according to the business strategy; the launching or stopping of strategic projects; the validation of the major stages of strategic projects; the organisation of operational project ownership.

It is therefore this committee which, with the support of the urbanism focus group, has the responsibility of ensuring that the urbanism plan is executed and deciding on the target updates and, consequently, the migration plan design. As with large towns, there are two levels of governance for IT systems in large enterprises or organisations: the town level and the borough level. You can therefore have an IT systems management committee for the town and an IT systems management committee per borough. The involvement of the head office in the overall IT systems management committee of the enterprise is fundamental, both because strategic decisions are to be taken and because it is not natural for the business manager to devote time to his IT system, even if it is to his benefit. The participation of the head office leads to a more assiduous participation of the other business departments. The operational project ownership is the linchpin of the strategic project ownership. It translates the business vision into developmental lines for the IT system. It defines and models the business processes, draws up the specifications and accepts the software applications. The responsibilities of the project ownership are as follows: •

• • •

to guide: to ensure the financing of the project, to structure its teams and set the work framework conferred upon the project managers, inform them of the rules and restrictions to be taken into account, monitor the progress of the project, define and then monitor the return on investment and monitor the coherence with the enterprise's strategy; to work out: to define the objectives, the stakes and the corresponding functional needs; to accept: to accept the overall system in the context of the organisation design; to carry out the changeover: to define and set up the design organisation, ensure the training and communication with the users.


263

The cartographies (business, functional, software and technical) produced in the context of the urbanisation project provide the means to allocate the responsibilities between project ownership and project management and, to a certain extent, within each of them on the basis of a clear joint and shared reference framework. For example: •

•

for the processes for which cartographies are being created in the context of the business cartography, a manager can be appointed for each process which has a well defined perimeter and flows as regards the other processes identified and described; as the zones, districts, plots and their plug-ins are clearly defined, the responsibility of one of these blocks can be allocated to a given organisational entity.

Of course, as the cartographies are an excellent tool for specifying the perimeters of responsibility for everyone during the study, care must be taken because, hidden by questions which are more or less technical, there may be some concerns more linked to the distribution of the perimeters. But this is not a reason for being vague, and bringing cartographies produced in the context of an IT system urbanisation project to the organisation is therefore very largely positive.

10.4 The role and organisation of the urbanism focus group The urbanism focus group can take different forms depending on the enterprise or organisation concerned: it may be a service, a cell of an office or even a division. The term "focus group" designates an entity of the organisation suited to fulfil, on an ongoing basis, (in fact, this entity has to be ongoing and not function bit by bit) the missions of an urbanism focus group as defined below. 10.4.1 The purpose The purpose of the urbanism focus group is to keep the IT system on the trajectory established, by preventing successive projects "breaking" the urbanism set up progressively and periodically revising the target and the migration plan.

264


10.4.2 The missions The urbanism focus group is in charge of the following seven essential missions: • • • • • • •

processing applications for building licences; checking conformity with the execution plans; maintaining the IT system reference framework; producing the framework documents; advising the project owner and project manager; updating the urbanism rules; guiding the updates of the Land Use Plan and migration plan design.

Processing applications for building licences (compulsory prior to starting any project) As with a building, it is essential, if you want to impose urbanism rules, to ensure in advance the respecting of these rules on the basis of an accurate description of the project. The applicant therefore must deposit a building licence application that clearly sets out the project planned, in terms of purpose, objectives, perimeter, location in relation to the Land Use Plan, and the respecting of the various standards or norms. The urbanism focus group studies the file and either: • •

approves the building licence where all the rules have been respected; declines the building licence and lists the reasons for the refusal which may only be the non-respect of one or more rules.

More exceptionally, the urbanism focus group may approve an exception or even add to or amend the rule. Next, if in the course of the project it is necessary to modify one of the elements in the file for which a building licence was obtained, the project must deposit a modified building licence application which itself may be approved or declined for a reason. For a maintenance project, we refer to a -works declaration rather than a building licence, but the same principles are applied.


265

For software applications to be removed, we refer to a demolition licence, but for this also, the same principles are applied. The conformity control in relation to the building licence plans at the end of the development At the end of the development and before putting the new or modified application into service, the focus group makes a so-called conformity inspection, i.e. it checks that the application produced conforms to the licence granted and to its aproved modifications, if any. The maintenance of the IT system reference framework established during the urbanisation study The various cartographies produced during the study and entered in the reference framework of the design tool used constitutes a precious asset for the enterprise or organisation, and allows for, notably: • • •

prompt and reliable analyses of impacts; controlling the IT system; rapid training of new contributors to the IT system.

Without regular updates, the information contained in this reference framework soon becomes unreliable and even obsolete. A little time must therefore be devoted, on a regular basis, to keeping the value of this asset. Remember that not all the cartographies are produced for every IT system urbanisation project, but that in extreme cases, it can take up to three cartographies (business, software and technical) to describe the existing IT system, four (business, functional, software and technical) to describe the target IT system and, why not four cartographies to describe each of the stages towards converging towards a target IT system? The production of framework documents The urbanism focus group must produce framework documents allowing the heads of the projects to deposit applications for building licences, modifications to building licences, works declarations or even demolition licence applications, which will be accepted because they respect all the urbanism rules. The urbanism focus group goes over the norms with the project heads. With them, they establish "urbanism contracts" which respect the urbanism rules, i.e. the functional and technical standards for the installation of data, their updates, etc.

266


The consultant Together with project ownerships, the urbanist plays the role of consultant. He helps them to see the added business value of their functional requirements, to frame them in relation to the strategic diagram established by the enterprise or organisation and classify them. By monitoring the technical and functional developments of the market, he informs them of the best practices. Together with the project management, he also provides daily assistance and added value to the projects. Updating the urbanism rules When updating the urbanism rules, the urbanism focus group is the linchpin behind drafting the new rule, which is approved by the IT systems management committee. Guiding updates of the Land Use Plan and the migration plan If necessary, and following a decision of the IT system management committee, an update of the target and therefore the migration plan design may be decided. This type of situation occurs if one or more factors within or outside the enterprise or organisation leads to the strategy being revised in a significant way. Steps must therefore be worked out to realign the target IT system and migration trajectory. The urbanism focus group is in charge of guiding this update. 10.4.3 The pitfalls The following are not part of the urbanism focus group's mission: • • •

to be an internal auditor; to be thought of as a decision-maker; to act as designers or developers.

In reality, in order to succeed, the urbanism focus group must be strictly limited to fulfilling the missions listed above. It does not audit the projects, whatever the plan: • • • •

functional; technical; methodological; guiding.


267

Neither does it make other decisions as to approving or declining building licences, modified building licences, demolition licences, works declarations for reasons based on a technical inspection in relation to the rules in force. It therefore does not decide on the starting or stopping of projects, or the validation of the software applications, even if its decisions strongly influence the choice of the decision-makers. Finally, even if the urbanism focus group plays a consultancy role with the project management or project ownership, it must not replace them. It must therefore not take part directly in the design or development of the software applications. 10.4.4 Organisation Attachment We have to say that the urbanism focus group is often attached to the IT systems department. Even so, it would be preferable if the urbanist was directly attached to the head office. He provides the link between the strategy of the enterprise, which comes by definition from the head office, and the IT system(s). As the guardian of the temple, he ensures the coherence of the IT system(s). The recognition of the position in the enterprise is greater if he is directly attached to the head and if he accomplishes his mission in a structure where IT is at the heart of the business. Composition The urbanism focus group is exclusively made up of urbanists who rely, if necessary and therefore occasionally, on other actors from the types of actors needed in the IT system urbanisation project team. The IT system urbanisation project team brings into play three types of actors: • • •

actors who are typically from business departments and and able to obtain an overall grasp of the business issues and to understand the alignment approach; actors able to align the processes and the IT system to the business strategy. Urbanists are; actors able to align the IT system and software system. They are IT and NICT (New Information and Communications Technologies) professionals. They are the functional and technical architects.

268


If the profiles of the functional and technical architects are well known because they are relatively old, the profile of the urbanist is, on the other hand, both newer and less well defined, as what's more, is that of the city urbanist compared to architects for buildings. It is therefore advisable to spend time defining the profile of this new business. The urbanist must ideally have: • • • • • •

a solid knowledge of IT systems; a good knowledge of the activity sector; concrete experience in the business of the department for which he is working; ability to conceptualise and model; a good imagination; negotiation abilities.

Often you cannot find this rare bird. You have to make do with an ordinary bird and train him. You should also think about hiring someone with a strong potential, and then offer a job enhancement and attractive career prospects. The set-up of the urbanism focus group varies greatly from one enterprise to another, but to get a fixed idea, typically a team of between two and eight people can fulfil all the missions of an urbanism focus group as described in this book.

Conclusion

It is time to go over the subjects covered by the beginning of the book again. I would like to highlight the vital importance for an enterprise or organisation to manage its IT system with care and coherence in a context where the IT system is at the heart of the running of any organisation and where its efficiency determines performance. I would also like to highlight that a major difficulty in making an efficient IT system available to the enterprise or organisation is finding a balance between the following factors: • • •

identifying the changes necessary for to implement the enterprise or organisation's strategy; safeguarding the coherence and improvement in efficiency of the IT system; the quicker setting up of quality systems.

The ambition of this book was therefore to describe: • •

the specific use of the methodological tool that constitutes process management to identify, in the context of the urbanisation project, the changes needed for the implementation of the strategy; the IT systems urbanisation approach, i.e. the approach which allows for improving the efficiency of the IT system while safeguarding its coherence.

2 70


I hope that I have provided some convincing responses to these questions and more especially, to have described, for an IT system urbanisation project: • • •

What should be done? Who should do it? How do you do it?

Of course, I am aware of the limits of these approaches: •

• •

Firstly, of the relative newness of this methodological approach. This approach has already been successfully used on a dozen projects over the last four years, and proof has therefore been provided in the validity of the underlying concepts and hypotheses. This book gathers together the lessons for implementing this method in these diverse contexts with regard to their size (from small and medium-sized companies to multinationals), their type of organisation and the nature of the activities carried out (administration, banking, insurance, telecommunications, transport). You cannot completely free yourself from the interdependence between the different levels of the reference framework (business, functional, software, technical). As the book centres around the study leading to the defining of a target and a migration plan design, it may give the impression that all that needs to be done is this study phase, although the implementation phase is just as important as the study itself. It is therefore a matter of taking a voluntaristic approach, allowing for focussing most efforts and resources on the migration towards the target and not exceeding a certain volume, set in advance, for processing urgent requests. The challenge is clear, either you take the fast route, or you choose to focus on a precise selected objective. In one instance, you have a certain control of your destiny, in another you live day by day. The urbanism focus group is a key element in the plan concerning the governance of the IT system, and the success of its implementation needs one more new era, a new dynamic in the relationships between project management and project ownership.

Conclusion

•

271

With this type of approach, if you design the ideal target, you generally end up with what you were trying to avoid. However, even in this extreme case, the approach presents significant advantages, due to the fact that the progressiveness of the step-by-step migration, with each step bringing a measurable return on the investment for the enterprise or organisation and its users and helping to limit the risks in comparison to a total overhaul project, which can be a little grandiose.

Despite these limits, I hope to have demonstrated that it is possible, by following the approach proposed, to urbanise IT systems and to turn these IT systems into real levers for implementing the strategy, in particular allowing for achieving the following objectives: • • • • • • • •

to ensure the ongoing status of investments; to increase the reactivity of the enterprise; to increase the neutrality of the IT system in relation to the growth or evolution of the organisation; to increase the independence of the various blocks; to increase the reusability of the components; to improve the openness and interoperability of the systems; to reinforce integrity and coherence; to ensure exhaustiveness because we are considering the town in its entirety.

I hope finally that this formalisation of an expertise acquired in the field may be put into practice by enterprises and administrations so as to focus their investments on the developing their IT systems in a controlled, progressive way, aligned to their stakes.


Appendices


Glossary

Actor class Corresponds to a specific view of an actor in a core business class. The actor classes provide an organisational vision. It is understood that the core business class level describes the basic information of the enterprise; this information is then structured and organised according to purely architectural criteria (adherence of the classes between each other, coupling of packages, modularity) but do not take into account the business organisation. This is the role of actor classes. An actor class therefore defines a specific view of a core business class.

Actor or external actor An actor represents a role outside the IT system but which interacts with it. An actor may be a person or a machine. It carries out transactions with the system, and each sequence of transactions can be defined in a use case. An actor is different from a user: • •

a user is someone who actually uses the system; an actor is an external agent that represents something for the system.

Back end Application implementing a set of back-office services for one or more actors.

2 76

The Enterprise A rch itecture IT Project

Back office The back office is all the product orientated services which cannot be activated directly by the external actor in contact with the customer or by the customer himself.

Block A block designates any one of the three breakdown levels of the functional architecture: the zone, district or plot. This is an individual unit, autonomous and separate from the execution. A block is used in a specific context with a view to the partial or total automation of the management of information for one or more of the enterprise's businesses.

Business activity A business activity or activity defines the specific aim of an entity or its characteristic action. An activity is a logical process which converts the content or state of the data. Upper-level activities can be broken down, basic activities are reusable in several processes. A work unit is an activity which does not justify being broken down further.

Business architecture This is the structuring of the IT system by the enterprise's activities vis-a-vis its business processes.

Business class Corresponds approximately to the following five class types: actor, core business, primary core business, secondary core business and reference.

Glossary

277

Business rule Formula for the way to process an operation according to the prevailing conditions or modalities.

Cartography of the processes Systemic analysis stage of an organisation through all its processes in such a way as to classify them, link them and put them into an order of hierarchy.

Class Model shared by a set of objects which have the same characteristics.

Communications artery Example of a message manager dedicated to a flow type and that corresponds to its characteristics of fluidity (flow direction, availability required, maximum response time) and volumetrics.

Control class Class allowing for the management and/or control of the business rules application asociated with the business classes. The control classes allow for the management of specific rules (e.g. the multi-class business rules, i.e. supported by the services of several classes),coherence controls, access controls, etc. They may also allow for managing the link sequences of the operations calls, which would allow for externalising the rules for linking of operations themselves which, as a result, remain stable.

Core business class Class that allows for describing a business concept independently from the organisation. A core business class is a class allowing the description of a business concept for the enterprise, as opposed to a business concept limited to the view of a user. This can be a primary core business, secondary core business, or reference class.

2 78


District Group of plots This groups together components that are uniform with regard to the nature of the information processed. A district will typically correspond to what is commonly known as a subsystem. Examples of districts (taken from the case study): • • •

management of payments; management of reservations; accounting.

Correspondence with the urbanism concepts: the district which groups together a set of housing showing uniform characteristics from a technical, administrative, economic and social point of view.

Event An event is a signal which can be recognised by a given actor and indicates that an act to which the data is attached has taken place. Example: request to open a contract. An event has the following charateristics: • • • • •

it arrives at a given moment; it has no duration; it may precede or follow another event; it may be used by several objects simultaneously; it is sent in the form of a message from one object to another.

Flow A flow is an exchange. There are material flows and data flows, which are financial flows. Exchanges between blocks are data flows routed by messages. They may be continuous or triggered at certain times in the day (e.g.: taking into account night-time accounting movements).

Glossary

279

A data flow may be inside the system studied or come from (or be going to) an external system. Among data flows, there are management flows, business flows exchanged with the organisation and business flows exchanged with the other software applications systems.

Front end Application implementing a set of front-office services for one or more actors.

Front office Set of product orientated services which can be activated directly by the external actor in contact with the customer or by the customer himself.

Functional architecture This is the structuring of the IT system into communicating functional blocks. The rules and principles for the breaking down into these functional blocks and their organisation within the functional blocks are described in the urbanism plan.

GUI class Technical class of the presentation layer (man/machine interface). It allows for describing the way in which the actors (real human users in this case) interact with the system. It allows for access to the core business classes, possibly via the corresponding actor classes, and the manipulation of the data they contain. It also contains the top-level interface controls: value interval, type.

Impact perimeter of an event The impact perimeter of an event comprises all the activities which interrupted by the end of the main activity reacting to this event.

280


Internal actor An internal actor represents a role within the IT system and which takes part in one of its procedures. An internal actor may be a person or a machine.

IT system Aspect of an organisation which supplies, uses and distributes information. It is therefore an aspect of a human system, which may contain IT systems.

Land Use Plan The purpose of the LUP of an IT system is to define, as accurately as possible, the services and responsibilities attached to each sub-set of the IT system, and also to organise the IT system overall, by defining: • • •

the purpose and, as it were, the mission of the applications that make it up; to group the software applications into coherent sets; the perimeters reserved for future software applications yet to be built, in particular, for transverse applications.

Logical technical architecture Modelling the distribution of the components in the technical architecture for the various site types of the software system, independently from the hardware and software configurations.

Message The message is the mode of propagation between software blocks of a data flow resulting from a management event. It therefore represents a flow travelling within the enterprise or exchanged between the enterprise and its environment. It may be sent synchronously or asynchronously.

Glossary

281

Message manager Once the breaking down of the IT system has been carried out, it is a matter of allowing communication between the various blocks. In an urban environment, this is shown by setting up lines of communication, public road networks, sewage networks, etc. In the IT system, it is the role of the message manager to provide these exchanges by means of specialist components (inter-applications message systems, bus software, etc.) on the basis of a standardised format, in a transparent manner for the software applications.

Middle end Application implementing a set of middle-office services for one or more actors.

Middle office The middle office is all the services which cannot be activated directly by the external actor in contact with the customer or by the customer himself allowing: • •

a direct interaction with the customer; correspondence between the customer (front office) and product (back office) views.

Objectives With the aim of traceability, the description of the enterprise objectives and sub-objectives can be recorded in the business cartography. You should check that each of the objectives is covered by a process, each process by a set of activities and each activity by one or more blocks. This way you can keep track of the needs covered by the IT system.

282

The Enterprise A rchitecture IT Project

Operation Stage in a procedure that corresponds to the intervention of an actor from the organisation in the context of the enterprise's activities. Once started, the operation can be executed without waiting for any event other than the triggering event. The operation cannot be interrupted.

Package Group of elements of the same type as their relations. The elements may for example be (non-exhaustive list) classes, objects or even components.

Persistence Ownership of an object whose value is able to persist for an indeterminate time (in a database).

Persistent class Technical class built in the same way as the database structure. A persistent class allows for describing the way in which objects are stored.

Physical node A physical machine with its associated software environment from the system point of view (operating system, system drivers, network drivers, compilers, etc.). Care should be taken with documenting the compatibilities between physical nodes to allow for verifying the feasibility of technical solutions used.

Physical technical architecture Physical description of the software means (hardware, software, network) implementing the logical technical architecture.

Glossary

283

Plot This is a replaceable entity of the IT system likely to be developed or purchased separately. A plot covers an "activity", which corresponds to a functional purpose and includes the processing and accessing of data for this purpose. A plot produces standardised results that can be used by other plots. A plot will typically correspond to: • •


Examples of plots (taken from the case study): • •

general compatibilty; analytical compatibility.

Plug-in A plug-in is the means made available to the outside world by a block to offer its services. A plug-in comprises data structures and one or more operation names that can be used in this block.

Primary core business class Core business class describing a major business concept. A primary core business class is a core business class with the essential idea of the corresponding business concept. A package of classes is automatically associated with each concept. One such class could serve to define the concept of the "customer" for example. The primary core business classes are not necessarily identified initially. A concept is first of all a set of core business classes. The core business classes are only defined once and it depends on the choices taken at the modelling as to what primary core business classes are definitively chosen.

284


The primary core business classes in a way form the pillars of the functional architecture, around which the other core business classes are formed then the other class types are grouped into packages.

Procedure The same as a business process as described in the context of a structured organisation. Designates a sequence of activities carried out by actors acting on the data and governed by the business rules linked to markers; a procedure is triggered by a request and ended by the acceptance of a result.

Process A process is made up of a network of activities whose purpose is to process an initial management event. Its purpose is to produce the flow of results defined in the time and quality conditions set to meet the internal or external third party needs. It must be defined independently of any organisation or system that exists in the enterprise. It corresponds to the user functional vision. Example of a process (taken from the case study): • • •

reservation; payment by instalments; invoicing.

Process management Manages the linking of activities involved in a process or operations involved with one or more procedures.

Glossary

285

Reference class Core business class whose role is to store all or some of the parameters of a concept. In practice, this can be shown in a parameters table in the database, a configuration file, etc. For example, the various "customer categories" may be defined as a reference class attached to the "customer" class.

Reference framework Enterprise model centered around the IT system. It allows for formalising the representation of all the components of any enterprise or organisation, notably its IT system and the connections between these components. There are four levels, as well as the strategy level: • • • •

the business level; the functional level; the software level; the technical level.

Secondary core business class A core business class complementing the definition of the business concept to which it relates. It is in principal in direct relation (association, aggregation) to the corresponding primary core business class. Most of the time, a secondary core business class can be a functional sub-set of the attached concept. In other cases, it may correspond to a concept of less importance which can have a different meaning from one context to the next. For example, the idea of an "address" may also be applied as much to a "customer" as to a "supplier".

Site A geographic location considered from the point of view of one or more activities.

286


Examples of sites (taken from the case study): • •

local or regional branch; head office.

Site type This is characterised by a group of actors according to a reference structure and appear in geographic sites. Several site types can be located in the same geographic site. The concept of a site type concerns both the expression of the organisation and its geographic deployment. Examples of site types (taken from the case study): • •

agency; head office.

Software application A set of software blocks which make up a coherent whole with regard to the information processing needs.

Software architecture This is the structuring of the IT system into communicating software blocks. The rules and principles for the breaking down into these blocks and their organisation within the software applications systems are described in the urbanism plan.

Software block Executable software module with an identity, offering services and with a well defined plug-in.

Glossary

287

Software component Package representing the most detailed level for a set of data and functions which forms a whole from the functional point of view. It may be distributed (installed on any machine, duplicated on several machines), but it is impossible to segment it. It may correspond to the implementation of a use case.

Software system One or more computers, peripherals and software which processes data. It is the automated part of IT systems. It is made up of all the hardware and software means that process, store and transport the information.

Technical architecture This is the structuring of the technical infrastructure means to be implemented for computerising the enterprise's activity. It is made up of three sub-sets: the operations architecture, the development architecture and the administration architecture. Specified for each of these three sub-sets are the software and hardware blocks needed, the location of the processing and data and the data flows. The technical architecture is described according to two levels: logical and physical. This distinction allows in particular for the sharing of the logical architecture between the various entities in the same enterprise or even the same group.

Technical class Class allowing for the link to be made with the technical elements. This allows for constructing an interface with all the technical layers of the system and offers a set of services used by the software layer. The technical classes also cover all the generic functions (date control, conversion).

288

The Enterprise A rch itecture IT Project

Technical component Package of software and technical classes which correspond to the most detailed level of a from a distribution point of view. There can be GUI components, persistence components software tools, and compilers.

Third parties Person or organisation that has dealings with the enterprise (customer, shareholder,etc.) participant in the execution of its businesses (distributer, partner, opponent, etc.) supplier of resources (employee, service provider, etc.) or influences it (competitor, legal body, pressure group, etc.).

Urbanisation An approach that allows for the defining of a set of rules and principles aiming to gradually convert an IT system whose target structure, comprising a set of mutualised services, absorbs any developments in technology and organisation in a controlled way and at a lower cost. Parallel with the urbanism of towns: starting with a site, lay it out with a view to developing or creating an urban centre.

Urbanism Science and technique for the construction and development of IT systems. Science and technique for the construction and development of urban centres, towns and villages. Use case Follows transactions executed by a system which produce a value result for a specific actor.

Glossary

289

Value chain Representation of a business activity by breaking it down according to a sequence of basic activities detailing the different stages of added value carried out throughout the sequence.

Version A version is a configuration of the software system or a sub-set of the software system, which is suitable for providing a coherent set of functions in the IT system. A version is a set of blocks which can operate together: • •

all the necessary functions are present (some may be in an intermediary version of the target version); all the necessary data is present.

Zone This corresponds to the most basic breakdown level of the IT system and more often the highest level of the software organisation. A zone will typically correspond to what is commonly called a design and development department or a system. Examples of zones (taken from the case study): • • • •

exchange; resources; decision-making; operation.


Bibliography

The Art of Strategic Planning for Information Technology, Boar, Bernard H., John Wiley & Sons, 2nd edition, 10, November 2000, ISBN 0471376558. Constructing Blueprints for Enterprise IT Architectures, Boar, Bernard H., John Wiley & Sons, 1st edition, 26 October 1998, ISBN 0471296201. Building Enterprise Information Architecture: Reengineering Information Systems, Cook, Melissa A., Prentice Hall PTR, 1st edition, 22 January 1996, ISBN 0134402561. Management & Information Systems for the Information Age, Haag, Stephen, Cummings, Maeve, McCubbrey, Donald J., McGraw-Hill Higher Education, 3rd edition, 27 July 2001, ISBN 0072458720. Your Next IT Strategy, Hagell, John III and Brown, John Seely, Harvard Business Review, October 2001. Informatique et strategic d'entreprise, architecture et pilotage des systemes d. information, Michel Mingasson, Dunod, 2000. Urbanisation des systemes d'information, Jacques Sassoon, Hermes, 1998. Dictionnaire de I'urbanisme et de I'amenagement, Pierre Merlin and Francoise Choay, "Grands dictionnaires", PUF, 1996. Architecture technologique des systemes d'information, la methode TACT, Nidal Alakl and Jean-Christophe Lalanne, Editions d'organisation, 1989. Petit Larousse grand format, 1995.

292


Iteor/2, referential methodologique de Sema version 2 et plus particulierement les modules Iteor/Management de Processus et Iteor/Urbanisation.

Index

activities, automation of 109 actor 29 and bodies 246 architecture business 38 functional 38 case study 140 good practice 44, 138 target 140 et seq and urbanism 133 et seq urbanism rules 43 good practice rules 42 software 39 good practice 46 urbanism rules 45 technical 39 good practice 47 urbanism rules 41, 46 block 17,25,30 communication between 26 interfaces 26 plug-ins 26 breakdown or subcontracting 103 business objectives/ IT system objectives 82 business processes cartography 98 and urbanism 97 et seq cartography 22 target business 121 city metaphor 13 subsets 15 urbanism and IT

coherence, safeguarding 5 data 30 database 31 district 31 enterprise business strategy 197 diagram 87 et seq rules 41 graphic representation 75 response to 10 stakes in 1 event 31 flow 32 impact perimeter 110 Ishikawa diagram 41 good practice rules 41 IT system, efficiency of 5 objectives , Ishikawa diagram 80 prioritisation 86 IT urbanisation, scope of 70 objectives case study 81 diagram 74 model 73 strategy 72 key performance indicators (KPI) 84 land use plan (LUP) 13 file 14 monotoring 19

294


procedure 19 logging 28 message 32 manager 157 functionality 171 metamodel 27 concepts 28 definitions 29 migration plan 189 et seq completion 231 multimedia district 177 objective 33 operation 33 organisation design 225 participants and roles 246 et seq physical node 33 plot 34 plug-in 158 primary core business class 34 process 34 description 101 diagram 100 evaluation 107 good practice rules 42 improvement 109 management 2 /strategic objectives matrix 99 modelling 100 models, good practice 106 soft and hard 105 urbanism rules 105 project, success of 8 quality systems, installation of 8 site 35 type 35 skills, techniques and tools 253 et seq software, block 36 cartography 153

strategic business objectives, case study 77 Ishikawa diagram 80 strategy design 216 implementation 1 monitoring 223 publication 236 review 238 sub-system 17 target and migration plan 189 et seq target architecture case study 170 functional to software 157 tour operator case study 51 et seq traceability 28

UML, use of 256 et seq urbanisation of towns, requirements 7 basic rules 23 et seq businesses 21 infrastructure 20 urbanism and business processes 98 case study 111 et seq focus group 263 and functional architecture 133 case study 140 and IT systems 13 rules 18,40,136 for functional architecture 137 and software architecture 153 case study 161 and functional architecture 153 rules 160 and strategy 69 et seq case study 76 v development cycle 9 zones 37 various 15

The Enterprise Architecture IT Project

Architecture Principles: The Cornerstones of Enterprise Architecture

Strategic IT Management: A Toolkit for Enterprise Architecture Management

Dynamic Enterprise Architecture: How to Make It Work

IT Project+ study guide

IT Project Management Handbook

IT Architecture For Dummies

Building Java Enterprise Applications. Architecture

Patterns of Enterprise Application Architecture

Advances in Government Enterprise Architecture

The SIM Guide to Enterprise Architecture

Successful IT Project Delivery: Learning the Lessons of Project Failure

A Standard for Enterprise Project Management (Esi International Project Management)

Enterprise JavaBeans™ Component Architecture: Designing and Coding Enterprise Applications

Dynamic Architecture: How to Make Enterprise Architecture a Success

A Standard for Enterprise Project Management

Enterprise Architecture and New Generation Information Systems

Java Connector Architecture: Building Enterprise Adaptors

Enterprise Cloud Computing: Technology, Architecture, Applications

Practical Guide to Enterprise Architecture, A

Enterprise SOA: Service-Oriented Architecture Best Practices

Winning in business with enterprise project management

Java Connector Architecture: Building Enterprise Adaptors

A Standard for Enterprise Project Management

Enterprise architecture and new generation information systems

Enterprise SOA: Service-Oriented Architecture Best Practices

Outsourcing, Insourcing and IT for Enterprise Management

Implementing Homeland Security for Enterprise IT

Constructing Blueprints for Enterprise IT Architectures

Enterprise SOA: Designing IT for Business Innovation

Syngress IT Security Project Management Handbook

The Enterprise Architecture IT Project

Architecture Principles: The Cornerstones of Enterprise Architecture

Strategic IT Management: A Toolkit for Enterprise Architecture Management

Dynamic Enterprise Architecture: How to Make It Work

IT Project+ study guide

IT Project Management Handbook

IT Architecture For Dummies

Building Java Enterprise Applications. Architecture

Patterns of Enterprise Application Architecture

Advances in Government Enterprise Architecture

The SIM Guide to Enterprise Architecture

Successful IT Project Delivery: Learning the Lessons of Project Failure

A Standard for Enterprise Project Management (Esi International Project Management)

Enterprise JavaBeans™ Component Architecture: Designing and Coding Enterprise Applications

Dynamic Architecture: How to Make Enterprise Architecture a Success

A Standard for Enterprise Project Management

Enterprise Architecture and New Generation Information Systems

Java Connector Architecture: Building Enterprise Adaptors

Enterprise Cloud Computing: Technology, Architecture, Applications

Practical Guide to Enterprise Architecture, A

Enterprise SOA: Service-Oriented Architecture Best Practices

Winning in business with enterprise project management

Java Connector Architecture: Building Enterprise Adaptors

A Standard for Enterprise Project Management

Enterprise architecture and new generation information systems

Enterprise SOA: Service-Oriented Architecture Best Practices

Outsourcing, Insourcing and IT for Enterprise Management

Implementing Homeland Security for Enterprise IT

Constructing Blueprints for Enterprise IT Architectures

Enterprise SOA: Designing IT for Business Innovation

Syngress IT Security Project Management Handbook

Recommend Documents