Outline of ProgrammeX

The Transformation Approach, Architecture and Component-based Development will strongly influence the way in which the transformation is delivered. This chapter gives and overview of the most important changes.

9.1 Iterative Transformation Cycles

The transformation of business and ICT will follow an approach based on iterative transformation cycles.

The Iterative Transformation Cycle (ITC) approach originated from the iterative application development approach (Iterative Application Development, IAD). The approach is meant for changing all business and ICT aspects of a company in an iterative fashion. Different aspects within an organisation - such as commerce, organisational structure, personnel, administrative organisation, finance, information, technology and legal aspects - may all be touched upon in an iterative delivery of a transformation. The Iterative Application Development approach was developed for the delivery of applications. For a project, which may only involve the development of applications, the IAD approach is sufficient. The Iterative Transformation Cycle approach is useful for business and ICT transformations such as the realisation of an ICT enabled Web Enterprise where a lot of business and ICT aspects are involved.

In a transformation programme the iterative transformation cycles occur primarily at the level of the achievement/assessment cycles. The delivery projects within the programme are grouped in an iteration of achievement/assessment cycles. Each transformation cycle delivers and assesses a next stage of the solution. The solution grows during the consecutive stages iterative and incremental from the As-Is situation to the To-Be vision.

There are two approaches for the delivery projects within an achievement/assessment cycle of the programme:

• Iterative approach
  The results of a delivery project are achieved in a number of stages, which lead step by step to the desired results. In this procedure every step produces a useful result and leads directly to the next step.
• Linear approach
  The results of a delivery project are achieved in one well-structured step. At the start, the solution is clearly designed, and is continually worked out in further detail; however, the target is always just the one solution.

The transformation programme may contain both linear and iterative projects. The combination of linear and iterative approaches forms a major part of the transformation delivery concept. It deviates from the idea that a single approach is the best for every situation. The programme combines projects with various approaches and supports the choice and combination of these approaches for various stages of the programme.

9.1.1 Iterative versus Linear Approach

The most important differences between the iterative and linear approach lie in the scope and the content of the executed steps.

A typical example of a linear approach is the building of a house. Making the first sketches, the blueprint, the design, getting the necessary approvals, building and delivering it are all one-off, consecutive events. When the house is finished, it will certainly need maintenance, but redesigning the house will not be necessary; the basics are available and will remain so as long as possible.

Iterative projects are characterised by a number of short steps. Each step is an iteration that realises a part of the total solution, which can be put to immediate use. After an iteration the project team can adjust or revise the scope and content of the next steps or of the whole project.

The steps of linear projects correspond to stages in the development like requirement analysis, functional design, technical design and realisation. Every stage provides the input for the next stage. It is certainly not the intention to change the scope and content of the solution defined in earlier stages during the later stages of the project. A characteristic of linear projects is that they can be subject to go/no go decisions after each stage, but have little means of altering the scope an content without directly influencing the duration of or costs involved in a project. A linear project normally results in either a 100 % or 0 % solution, and the consequence of cutting off a project prematurely almost always mean that one ends up without a result that can be used.

A linear approach is effective when working on a solution which can be exactly designed and where the development and implementation may be isolated from other aspects. The target of a linear project is to achieve a predefined solution for instance a certain ICT application. Therefore, a linear project is product oriented.

Such a limited view of the solution is not possible in a complex business and ICT transformation that is aimed at business benefits. The route that must be followed to realise the business benefits is not always clear. This is both the case for the whole programme but also for a lot of delivery projects within the programme. In order not to lose sight of the goal, it is necessary to keep the business benefits in mind for which the transformation programme was originally set up. The control mechanism available within an iterative approach - i.e. the possibility of reconsideration and adaptation of the delivered solution during each step – is very appropriate when the target of the project is to realise an effect such as business benefits and not a specified product. The assignment is then not to produce a product, but to realise business benefits. Therefore, an iterative project is goal oriented.

The difference between linear and iterative projects is also easy to observe in the manner in which they are completed. A linear project is completed when the product is delivered according to previously agreed specifications, whether or not these specifications are still valid. An iterative project is completed when the last step has delivered a solution that sufficiently fulfils the goals, and a further step would not add any major extra value.

9.1.2 Characteristics of the Iterative Approach

The most important reason for choosing an iterative approach is its flexibility. The flexibility to change one's mind and approach during the course of the transformation, depending on the results of each stage. The flexibility to readjust the specifications of the final version, if the interim results require to do so. The flexibility to be able to react to changes in the outside world, reactions from customers or from the competition, and the reactions from one's own organisation to the implementation of an interim step. The flexibility to be able to optimise the route one is following, if it should become necessary to redefine the target during the project.

The iterative transformation approach is not an approach, which targets only minor projects and minor results. The approach is highly applicable to the implementation of major changes throughout a company in both business and ICT. Such projects could last for a number of years before achieving sufficient results or before all components are fully integrated within the organisation. It is easy to give a good description of the target of such projects in the form of business benefits, but not the full details of the business and ICT solutions involved. Therefore, it is not possible to map out the route completely in advance, and during the project the details will have to be added.

9.1.3 Combining Linear and Iterative Approach

The linear approach is not completely replaced by the iterative approach. It is better to create a sensible combination of the linear and the iterative working methods. Parts of the solution, which must remain, stable or last for a long time, would be better designed and developed according to a linear approach. Whereas those parts of the solution, which are meant to be temporary or adaptable, would be better designed or developed according to an iterative approach.

In our example of the virtual bank the back-offices will form the base of the solution. Both the administrative processes and the information systems of the back-office must be sound and stable. They will have to perform their job at length, perhaps even for 24 hours a day. So the linear approach is appropriate for the back-office part of the solution.

The distribution channels will be determined to a greater degree by the daily activities of the customers and employees. In such a dynamic area, one can expect these activities to change regularly, especially if the virtual bank is trying to follow market developments, or has to defend itself against the competition, and therefore has to react to the unpredictable outside world. It would then be better to design and develop the business processes and information systems of the distribution channels using an iterative approach; they are of temporary use and will have to be improved regularly in order to keep them up to date.

9.1.4 Managing the Transformation Programme

Managing transformation programmes with a combined approach (linear and iterative) is more complex than managing projects with a single approach. The project management takes place by using milestones and time limits.

A milestone is the delivery of a specified product at a certain date. An example of a milestone is the completion of the document "Market Research," or the availability of the "Organisation Schedule". The product is important for reaching the milestone: it has to be delivered. If the milestone has not been reached by the set date - if the product is not yet finished - more time is needed (and the project has over-run).

Time limits are used to indicate the moment in time by which a product should be made available. When a time limit has been reached, the product is made available in whatever form it is at that moment. This is an important controlling mechanism within an iterative project. This mechanism is called time boxing. An example of a time limit is the passage of a three-week period, after which the version of the 'List of priority demands' that is available at that moment is used to support decision taking. As far as time limits are concerned, the actual moment in time is the determining factor, and the product - as far as form and content are concerned - available at that very moment is the one that is used. If the product is not yet finished when a time limit has been reached, then permission is requested for partial delivery.

A variant of time boxing is budget boxing. In stead of a time limit is budget limit is used. When the budget limit has been reached, the product is made available in whatever form it is at that moment.

An essential instrument for focusing the efforts within a time-box or budget-box on the right issues is letting the customer determine what features are essential, important and nice-to-have. Make sure that all features deemed essential can be realised (else re-discuss essentiality or get more time/budget). Furthermore let the customer prioritise the list of important issues, the budget left over from the essentials will be used to realise the issues in their chosen order. The role of nice-to-haves is to take them into account if cost is minimal.

The term milestone is often used in linear projects, and also in iterative projects. Time or budget limits are inherent to iterative projects. Therefore, both terms appear in transformation programmes; milestones and time limits. It is important here to realise that, due to their different nature, time limits and milestones do not have to concur. The delivery of a result is marked by or a time limit or by a milestone and not by both.

Combining both controlling mechanisms means that a programme management will have two characteristics. The programme management will have to give off the right signals depending on the context, both to the project participants and to the client. For a linear delivery project, the programme management is expected to stimulate the project team, in order to ensure that the product is finished by the date set as milestone. For an iterative project, the management must stimulate the project team to ensure that the most important part of the product is available by the date set as time limit.

9.2 Delta Analysis

The Component-Based Development (CBD) approach will strongly influence the delivery approach of applications.

CBD makes it easier to decide which part of the application development is performed with a linear approach and which part with an iterative approach.

This follows the division in activities of the application delivery with CBD as described in chapter 8.

Business-specific or system utility components and frameworks (activities 1 and 2) are best manufactured in linear fashion. They must have a sound and stable character, because they are reused or shared by multiple applications.

The iterative approach is most useful for the design and development of an application (activities 3 and 4). Both the application-specific components and the assembly of the application from components/frameworks are best developed in an iterative way by a multidisciplinary team consisting of an architect, developers and users.

The division in iterative and linear approach follows the division of the application delivery in front office and back-office activities.

The experts in the back-office develop with a linear approach the business-specific and system utility components and frameworks. The back-office is product-oriented: it delivers products (components and frameworks) to the front office.

The architects and developers in the front offices design and develop the application with an iterative approach. The front office is goal-oriented: it delivers through iterative development of applications certain business benefits to the customer.

Combining of the iterative and linear approach is necessary in the case of Component-Based Development, because this always involves the combination of adaptable applications with flexible application-specific components based on stable and sound business and system utility frameworks.

 

The current linear approach of application development starts with the requirements analysis followed by a complete design of the application. The application is build from scratch in conformance with the design.

In the iterative approach based on CBD the application architect will start with a delta analysis (D-analysis). The architect takes business-specific frameworks as the base for the design that best fit to the business requirements. The architect makes an analysis modifications and extensions with application-specific components that are needed to build the applications. An example of D-analysis is the bicycle of Panasonic. They use a design frame of a bicycle (see figure) for the analysis of modifications and extensions that are needed to build a bicycle that perfectly fits to the body and wishes of the user.

The application design and building based on D-analysis reduces to modifications of an existing framework, extending it with existing components and frameworks and building and adding some application-specific components. The development can be done in a fast and iterative fashion in co-operation with the user.

The iterative approach with D-analysis is also the main reason for the reduction of the development time of application from 9 months to 9 weeks or even 9 days. Analysing, designing and building the whole application in a linear fashion is no longer needed. The development starts with D-analysis of the gap between the required application and available frameworks and components. The architect and developers have only to design and develop the modifications and extensions that are needed to bridge this D.

9.3 Transition of Existing Applications

It would be easy when the information systems of the ICT enabled Web Enterprises could be build from scratch. But building applications in a green field is rare. Companies have a legacy of tailor-made application systems or systems based on application packages. Both types of systems are normally not based on architecture or a component-based approach.

Existing application systems are difficult to adapt to business changes. Every change in the functionality makes the system more complex and still more difficult to change. Every change will take more time and cost more money. Existing systems are based on older software and hardware technology. Eventually this technology may become obsolete.

The only way to solve these problems is to replace the existing system with a new one and use the component-based approach for developing adaptable systems.

But complete replacement in one "Big Bang" is not the best way:

• Most of the existing systems are back-office systems supporting the business functions and information for products and customers;
• Large investments are made in the development of the existing applications;
• The "old" technologies, on which existing systems are based, like mainframes, are still very capable for the job of processing the huge transaction load.
• The systems support mission-critical business processes. A failure of the replacement project may threaten the continuity of the business.

So it is better to search for transition paths that facilitate the gradual migration of the existing systems. Here are some possible ways in the case of a financial company like a bank:

• A middle-office between existing and new systems
  A good moment for the start of the migration is the introduction of new electronic distribution channels, like the Internet, electronic kiosks or call-centres. The bank builds new systems for the electronic distribution channels and adds a middle-office system that connects the channels with the existing systems in the back-office. The first step of renewal of the back-office applications consists of the building of an interface with the middle-office applications and new transaction application for the processing of transaction requests from the middle-office. The result is "encapsulation" of the existing system. It acts now like one big component. This step is relatively easy when the existing system already processes transactions on-line, but can be very complicated if the existing system processes the transactions in batches overnight.
• Partial Renewal
  A next step with support of the middle-office is partial renewing of the existing systems. The bank builds a new transaction server for an existing product, which is specifically build for use via the middle-office. The applications of the new server are developed with CBD. The bank can use the distribution channel manager for controlling, which customers have their account at the new transaction server or at the old system. This offers the bank the opportunity to migrate the accounts gradually from the old system to the new transaction server. This limits the risk of discontinuity of the services. The bank can gradually replace the existing system by building a new transaction server for each different product.

 

9.4 Reinvention of the Application Delivery

Architecture and CBD will lead to a reinvention of the application delivery. Like every business, application delivery in the 21^st Century will become a virtual agile adaptive Web Enterprise. There are four stages in this development:

• craft stage
  Application development started in the sixties as a craft. Every application was designed, programmed and tested individually by one person (the famous analyst-programmer). The developer is a craftsman and his applications show his own individual style and thus mostly his "creativity" and not his methods. A good developer tailored the applications to the wishes of the customer, but many developers tailored the applications to their own insights.
• industrial stage
  In the seventies the industrialisation of the application development starts. Methodologists organise and standardise the development process. The development of individual applications is replaced by projects, which develop large tailor-made information systems. The industrial principle of division of labour is applied through the "waterfall"-method, which organises the process in consecutive stages of requirement analysis, functional design, technical design, programming, testing and implementation. Every stage has its own professionals with the specific knowledge required for the type of activities. Customers get some "influence". They must accept the business requirements as formulated by the developers in the requirement analysis.
  In practice this methodological development appears to cause problems, especially when developing a large system and the project take some years. The whole working order is more or less linear. The development path must be gone through from the beginning to the end. The detailed designs can hardly be reversed. If at some stage it turns out that mistakes were made at an earlier stage, or that the business requirements radically change, the development is in dire straits.
  When the project ends well, customers mostly did not recognise any relationship between the delivered system and the requirements they accepted some years ago. The result is also an information system with a monolithic architecture, which is difficult to adapt. So keeping the system in line with the changing business requirements will always need a lot of time and investments.
  In the eighties the technologists try to improve the system development. Automating the automation. They want to realise an industrial approach with technologies such as 4^th generation development tools, CASE tools, repositories and reuse of software. The developers use methods like workshops and prototyping with the customer for the fast development of tailor-made applications. The result is faster development and better user satisfaction. But the developers still have problems with the development of large information systems because the individually developed applications not always fit together, when they become part of a larger system.
• mass-distribution stage
  In the eighties and nineties we see also the rise of software packages. It is the first form of reuse. The software suppliers develop the package once and distribute copies of the package to many users.
  Software suppliers like Microsoft, SAP and Baan use an important principle of production in the information age: develop immaterial products like software, movies or encyclopaedias once and massively distribute the copies via CD-ROM or the Internet. The earnings of the mass-distributed copies amply surpass the investments in the development of the product.
  But packages still have a problem. Packages are a uniform product. The users must always adapt themselves to the package or the package must be customised to the specific situation of the user. The software of SAP and Baan is adaptable to the requirements of the customer but this customisation takes a lot of work. Another problem is that packages support standard business functions and not always the specific business functions of a company. This makes it necessary to add tailor-made applications for these specific functions.
  Also the package suppliers have discovered the component-based approach. We see the componentisation of package-based solutions result in better adaptability of the package to the business requirements and in easier extensibility with tailor-made application components.
• mass-customisation stage
  This new stage is an answer to the problems in both the industrial and mass-distribution stage. Mass-customisation of application delivery is possible by:
  • A component-based approach of application development. Adaptable component-based applications replace both the monolithic tailor-made applications and the monolithic software packages. The component-based applications are assembled from tailor-made and off-the-shelf components.
  • A coherent design of the business and ICT system based on an architectural approach guarantees that individually developed applications will fit together in one ICT system that supports the business requirements (.
  • A transformational approach to business and ICT based on an adaptive programme of projects that supports an interactive, incremental and iterative development.

CBD supports the reinvention of the application delivery. The above figure depicts the way that the developers and organisations like Cap Gemini go in the transition from craft to mass-customisation. From "crafting" individual applications by a developer through people-intensive and later automated development projects, we reach the stage of mass-customisation.

The result of CBD will be mass-customisation of the software delivery. Developers will spend the most of their time in designing applications, components and frameworks. The time-consuming programming of code is replaced by generation from specification.

Cap Gemini, as application developer, will become a key participant in a Web Enterprise that delivers applications to the customers. Our application developers develop new applications or adapt existing applications in a real or virtual office in co-operation with customers. The application developers assemble tailored applications from components. The components are delivered through the Internet by component developers in the back-office of Cap Gemini or by independent component suppliers.

The result for the customer is an adaptable complex distributed information system, which perfectly aligns with his own virtual, adaptive and agile Web Enterprise.