From Train to Scooter - Capgemini · Producequickanddirectly measurablevalue. Applynew,easy-to-deploytoolsand platforms. Donotrequirethetypical specializedITskillsofthepastto build.

To facilitate the dialogue, we use thiswhitepaper to introduce the conceptof five different “ApplicationLifecycles.” Building on a simplemetaphor of modes of transport, weshow how insight into differingapplication dynamics can help to plana renewed generation of IT activitiesacross the entire organization.

Bleeding-Edge IT: Avoiding theValley of Delivery DisillusionWith the increasing availability ofcloud-based applications, Web 2.0,web services, business process andrules management suites, real-timebusiness intelligence and enterprisemobile platforms, a new generationof bleeding-edge IT solutions is onthe rise that:

� Are created in – or very near –the actual business units.

Many organizations struggle tointroduce a new generation oftechnology solutions that are createdand used in the nearest proximity tothe business side. The cloud, Web 2.0and the mobile revolution offer directvalue to the business with relativelylow initial costs and short time tomarket. Often, however, the way thesesolutions are delivered and applieddiffers dramatically from what the ITdepartment is used to. It once againopens the debate around ownershipand governance of IT, aroundcentralization versus decentralizationand contractual models, as well asaround timing and priorities. Withoutmutual understanding, the result maybe a lack of alignment, growingfrustration or – even worse –fragmented solution deployment andscattered investments.

From Train to ScooterFive Application Lifecycles That Address DifferingIT Dynamics Within Your Organization

Application Services the way we see it

� Produce quick and directlymeasurable value.

� Apply new, easy-to-deploy tools andplatforms.

� Do not require the typicalspecialized IT skills of the past tobuild.

� Are delivered in an accelerated andflexible way.

This poses important questionsaround shifts in the delivery of ITsolutions:

� Who is in charge of the portfolio,budgets, projects and priorities?

� What is the right – possibly global –mix of delivery resources?

� What new capabilities and skills areneeded and what may becomeredundant?

� What are the architecturalconsiderations to take into account?

� What tools, methodologies andaccelerators should be used?

� And as a result, how long will it taketo create solutions?

Clearly, in many organizations there isfriction between “Central IT” – incharge of the big legacy systems, ERPand data stores – and “decentral”business units that typically create (orare tempted to create) this newgeneration of “Business Technology”solutions. The bulk of the budget maybe consumed by Central IT, whichuses it to keep the lights on for theexisting applications landscape. Thefocus there may be on industrialization,simplification and trying to controlthe overall costs. On the other side,business units – possibly holding theirown decentral IT and budget – maybe acquiring and developing new,lightweight solutions that satisfy theirreal-life requirements and delivertangible value.

This can easily lead to a situation inwhich Central IT is getting moreisolated from the business side,condemned to sustain existingsystems with an ever-shrinkingbudget, no headroom to innovate orto expand and thus inclined to say“no” to any new IT initiative. On thebusiness side, do-it-yourself“bricolage” IT may bring some short-term solutions but can easily result inapplications sprawl, redundancy,uncoordinated use of corporateinformation and ineffective use ofsplintered budgets.

So how to avoid getting caught up inthis valley of delivery disillusion, withso much inspiration coming from acompletely new incarnation of the ITsolutions landscape?

The key is in distinguishing – andthen actively managing – differentApplication Lifecycles, each with itsown dynamics, timing, economicmodels, governance and designconsiderations.

Two of these lifecycles of applications(or, as it becomes more and moreappropriate to speak of “applicationservices”) pertain to the stable, oftenmore centralized part of the ITlandscape. Two others pertain to themore volatile, business-oriented part.Connecting them all, we distinguish afifth, crucial lifecycle that provides theflexible, yet mission-critical platformapplication services for the businessside to thrive on, while unlocking thefull enterprise potential of thecentralized application services andinformation. It is this platform “hub”where the IT and business sides meetagain: After identifying solutions withthe highest value to the business, thehub is the place where the actualconnection in delivery is being made.

2

The key to avoid gettingcaught up in the valley ofdeclining disillusion is indistinguishing — andmanaging — differentApplication Lifecycles.

Application Services the way we see it

From Train to Scooter 3

Metaphor: Modes of TransportA simple metaphor from the world of transport helps explain the dynamics of thefive lifecycles. To reach our destination, we may have several alternatives toconsider.

1. The TRAIN is a stable, robust mode of mass transportation. It is not flexiblebut reaches its goal in a predictable, straightforward way (ignore possible regionaldifferences, we are not comparing Great Britain and Scandinavia here). It is basedon an infrastructure that is designed and built to last for decades, and everybodywho uses that train travels in the same way from A to B. There is no chance to goby train where no route is defined. The functionality is provided in a highlyefficient and standardized way (at least if we look at the effort per passenger). Theonly option may be choosing first class if we’re interested in extra comfort. Onedoes not customize a train. Many people will be affected when trainsdo not run.

2. The BUS is also a relatively stable mode of mass transportation, but clearlywith more flexibility. A bus can take a detour if circumstances require, and it canbe used for alternative purposes on top of the fixed schedule. Moreover, it usuallyconnects directly with the train system. A bus still needs a road, but a flexibleroute can be more easily configured out of roads than out of available railways.Some organizations may choose to own or hire their own buses for specificenterprise use and customize and brand them to reflect the organization’s uniqueimage.

3. The CAR is a much more agile, individualized means of transport. It can take aperson – or a small group of people – to most of the places they want to go. Thereare many different types of cars to choose from and their owners will configureand adapt them to reflect their individual, differentiated styles and personalities.People – particularly men, admittedly – often confess to “love” their cars: Theircar gives them a sense of freedom and it is often tightly integrated with theireveryday lives.

4. The SCOOTER is a lightweight, extremely flexible and individual method oftransport. It can be used for the “last mile,” bringing you to places even carscannot reach. In crowded areas, scooters are faster than any other means oftransport. There are many different types of scooters and they can only transportone or two people at the same time. It is easy to rent a scooter – just for a day orso – and explore parts of the city in a flexible, cost-effective way. And it is fun too.Depending on the regional situation, a bicycle would be a suitable metaphor aswell, as it is fast, cheap, does not need a heavy engine or lots of fuel, and isextremely agile.

5. All of these modes of transport are tied together through a HUB, best seen as amodern train station with carefully provided additional services. Such a hub istruly multi-modal in that trains, buses, cars and scooters all can conveniently“dock” and people can easily change their means of transport, while benefitingfrom a host of add-on services. A well-designed station like this functions as thepumping heart of the city.

4

and green TechnoVision clusters(business process and business rulesmanagement, real-time intelligenceand analytics, collaboration and userexperience). The Hub lifecycleconnects these two worlds; it is whereIT and business entwine, and itshould be positioned in the middle.If we rotate the picture of theTechnoVision framework, we canvisualize the five App Lifecycles fromleft to right, as has been done here(see accompany diagram below,“The Five App Lifecycles”).

Describing the App LifecyclesTo further understand the dynamicsof each lifecycle, we identify somecharacteristic attributes:

� The typical Rhythm of creating –and frequency of enhancing –

solutions, including the totalduration of use

� The Application Area in which thesolution is delivered

� The Governance, in terms ofownership and place in theorganization

� The Architecture considerationsand typical challenges to the design

� The Testing requirements of thesolutions, also pertaining to quality,robustness and documentation

� The Delivery characteristics such asmethods, tools, accelerators andsourcing mix

� The Key Capabilities, existing andnew, that are needed

The Five App LifecyclesIn the same way as we would selectour mode of transport – dependingon the actual situation – we would beable to position the five differentApplication Lifecycles (in short, AppLifecycles) in our Business Technologylandscape. If we map them toCapgemini’s TechnoVision clusters1,we start to see that certain categoriesof IT solutions have a natural “fit”with specific lifecycles. And althoughthere is no 1:1 connection between aspecific solution category and an AppLifecycle, we can safely state that thetwo more robust, stable lifecycles –Train and Bus – mostly pertain to theTechnoVision “blue” clusters(particularly Sector-as-a-Service, thefoundational, core applications of anorganization). The more agilelifecycles fit with the orange, yellow

The Five App Lifecycles

1 “Building the BusinessTechnology Agora with Capgemini’s TechnoVision,” Capgemini, 2010

Application Services the way we see it

From Train to Scooter 5

Let’s look in more detail at thesefive lifecycles:

1. TRAIN AppsTRAIN Apps are foundationalsolutions that organizations need asthe backbone for their operations.These solutions are very stable andprovide little or no differentiatingpower, let alone specific traction withbusiness drivers. They are, however,at the heart of operations, maycontain crucial corporate knowledgeand need to be robust, stable,compliant with rules and regulations,and predictable.

TRAIN Apps tend to change little.New, major releases should typicallyonly occur in yearly cycles, althoughongoing maintenance work might bethe norm. As these applications arethe typical backbone of an enterprise,a frequent flow of changes to themsuggests systems that are faulty, over-customized and difficult to maintain.Nowadays, often too much of theoverall IT budget is spent on TRAINApps – sometimes hugely overlappingones on multiple platforms – especiallyif we consider the limited degree ofbusiness differentiation they provide.

Typically the underlying functionalitycan be provided as software off theshelf. Only in a few instances (often infields where no market exists) is thereno off-the-shelf software at all that canbe used, for example in the case ofspecial government areas.

Systems are based on classic ERP (forexample, finance and control,inventory, order management, MRP,core banking) or on bespoke – oftenlegacy – systems that supportfoundational activities of theorganization. The latter may bedeveloped in COBOL, RPG, PL/1 or4GL, but newer legacy core apps mayalso have been developed in Java, C#and – yes – ABAP. Newer foundationalapplications may be purchased assector-specific “vanilla” software-as-a-

service or even in combination withBusiness Process Outsourcing. It’sbecoming quite unlikely that newTRAIN Apps are developed fromscratch, but generating code fromstandard sector/industry models mayoccur more frequently.

TRAIN Apps are owned by the ITorganization and there should be awell-defined, periodic process toinvolve the business community forthe new release. As new releases mayintroduce relatively big changes to thefunctionality, this will involve a changemanagement program across theorganization. Frequent applicationsmaintenance (AM) should beminimized, but taken care of througha well-defined, mature AM process.

The architectural approach focuses onstability, maintainability and providinga reliable set of foundational services.There may be an ongoing lean effortto further improve foundational appsthrough simplification,standardization (for example, de-customization) and rationalization,also taking into account thatorganizations have inherited manydifferent legacy TRAIN Apps thatoverlap in functionality. Next to themain drivers of robustness andcompliance, cost effectiveness is animportant requirement for the design.

New releases must be testedextensively and a risk-based approach(starting from a risk analysis) istypical. There is a special emphasis onregression and end-to-end testing in

order to avoid unwanted side effects.This type of application is particularlysuitable for automated testing, and thefocus of the tester could be more ontechnical challenges and tooling,rather than business challenges.Documentation must be up to dateand actively maintained, as it capturesknowledge of the systems for manyyears. As more TRAIN Apps will beprocured as SaaS-based ERP, specialtools and approaches must be usedfor testing packages. Given the typicalsize and impact of the change, properchange management needs to be inplace and special attention needs tobe paid to training the users of theapplication.

A rather classic, linear, requirements-driven approach is used to managethe lifecycle of the solution. ASLand/or ITIL may be used forapplications maintenance. Continualrationalization may be needed,particularly if existing TRAIN Appsare outdated, difficult to maintain andnot standardized. And it may involvelean-style improvement andapproaches such as Capgemini’s“Agile Legacy Lifecycle.”2 Building,implementing and maintaining TRAINApps may involve up to 80% offshoreresources. ERP is implemented – andupdated – as “vanilla,” refraining fromexcess customization. Code generatorscould frequently be used.

2 “Agile Legacy Lifecycle,” Capgemini, 2010

6

For this lifecycle (and for BUS Apps aswell), contracts that are based onmulti-year Service Level Agreements(SLAs) are typical. The needed resultscan be well defined and arepredictable. The amount of changerequests can be anticipated andcarefully managed. Going live with asolution in this category is a costlyand impactful process, hence it isdone only every now and then andoverruns on the deployment are to beavoided. Contracts reflect the inherentcomplexity of this lifecycle and areoften elaborate and highlyprofessionalized, with some expertsdedicating a full career to thesupporting process.

The needed skills include proactiveapplications maintenance, applicationsrationalization, retirement, requirementsmanagement, regression testing,model-driven architecture (MDA),legacy programming languages,information analysis and businessmodeling.

2. BUS AppsBUS Apps are stable, yet flexiblesolutions that provide organizationswith a certain degree of competitivedifferentiation. Being core apps, theydefine the very essence of theorganization. They may be keyenablers to some of the more stablebusiness drivers. Although the pace ofchange is relatively slow, implementingchanges and customizing the solutionsmust be easy – while sustaining thestable and standardized elements ofthe solution. BUS Apps supportspecific functions of the organization,

catering to the needs of the businessunits involved.

BUS Apps are changed and implementedon a regular basis. The typical metricwould be a season (for example,salesforce.com features four majorreleases every year, timed with theseasons). Implementing a new solutionshould also take seasons, not years.Smaller functional enhancements andbug fixes are applied in a morecontinual way, with the AM processbeing more cyclical and agile innature. Speed-to-market is importantfor this type of app: A time-box mayprovide a fixed amount of time to getthe application to work and an agreed“release calendar” would be quiteachievable, based on an activelymanaged requirements list.

Systems are based on “edge” ERP(such as CRM, SRM, SCM and HRM)as well as sector-specific applicationslike Transportation Management andInvestigative Case Management, butmay also involve enterprise contentmanagement and E-business packages.A certain level of customization isapplied, although within definedboundaries to keep the solutionmanageable. More bespoke softwareshould be expected in this lifecycle,written in Java, C# or other moremodern programming languages.Code generation from pre-definedbusiness models may occur as well.Many of these edge applications aredelivered in an attractive SaaS model(again, for example, salesforce.com),which further pushes the need forlimiting customization.

BUS Apps should be jointly owned bythe IT and business organizations,with the IT organization responsiblefor development, implementation andmaintenance, and the businessorganization in charge of needs andbudget.

The architectural approach focuses onflexibility, maintainability, speed ofimplementation and providing easyaccess to BUS services, the commonbasis being a stable, elaborate andproven approach. There needs to be aproper balance among standardization,the orchestration of readily availableservices, customization and bespokesoftware. This implies a continualrationalization effort, comparable towhat is needed for TRAIN Apps.Pre-defined sector business models willhelp to speed up – and standardize –efforts in this area. This also pertainsto architectural models (or DSLs,Domain Specific Language) thataccelerate the development ofsolutions that are in large partsimilar and in small ways different.

Testing is done in close alignmentwith the business side and appliedthroughout the lifecycle (rather thanat the end, which might reduce speed-to-market). Testers therefore needmore focus on business issues as well,and the upcoming interest in context-driven testing is particularly relevant.They will work in close collaborationwith the developers, possibly as a pair,covering the entire lifecycle. Iterativeor agile testing is often applied, aswell as model-based testing.Documentation must be up-to-date,although it may be maintained inretrospect after the solution has beendelivered.

An iterative, cyclical approach will bethe default throughout the lifecycle(including applications management),as it is risk-driven, involves thebusiness side in an interactive wayand delivers solutions within a fixedtime window. Methods may includeagile RUP and SCRUM but may alsobe mixed with more linear

Application Services the way we see it

From Train to Scooter 7

approaches. A “software factory” couldbe a powerful accelerator for BUSApps, possibly involving codegeneration from models and reusableframeworks (such as MDA). BUSapplications may involve up to 65%offshore resources. Rapid SolutionWorkshops and Smart Use Cases canspeed up requirements management.Typical programming languages areJava, .NET, ASP, Ruby and PHP.

Capabilities include proactiveapplications management,applications rationalization, context-driven testing, SCRUM, agile RUP,MDA/DSL and software factories,business analysis/SEMBA, Smart UseCases and IRMA for requirementsmanagement.

3. HUB AppsHUB Apps – or better, HUBapplication services – provide thecrucial glue between the IT andbusiness sides of the organization,including the outside world. They

enable all stakeholders to createsolutions within the pace andrequirements of their own lifecycledynamics. The HUB platform enablesflexibility and speed-to-market on onehand, but also brings the integration,robustness and data/process integritythat mature enterprises require. Withthat, the HUB is also a steward ofopen standards.

As new technologies emerge on afrequent basis and organizations wantto benefit from them in a timely way,HUB Apps will evolve quickly interms of new services they provide,more in months than in seasons, butnot in weeks. All in all, the overalldesign of the HUB itself is presumedto be stable.

A HUB may include Master DataManagement services, a business webservices catalog that gives access tofoundational and core functions, acorporate “apps store” and “datamarket,” and contains all the“infostructural” facilities needed toeffectively create and composeBusiness Technology Apps (for example,Enterprise Service Bus [ESB], BPM suite,Business Rules Engines [BRE], portals,mashup tools, BI, mobile services,security, etc.). Much of this will becloud-based, although hybridscenarios (a combination of on-premiseand public cloud delivery) will betypical in the forthcoming years.

HUB Apps are the pièce de résistance ofthe IT department, as they are thepowerful catalyst to create morebusiness value from IT. Therequirements of HUB applicationservices must be proactively alignedwith all stakeholders – both inbusiness and IT – in order not to lagbehind. There must be a sense ofcollaboration, rather than “comply ordie,” and architectural designprinciples must be carefully andconvincingly communicated.

These architectural principles revolvearound open standards, opensolutions, SOA/service orientation,

cloud and “social.” The strategicdirection of the company – and theway it wants to function and organizeitself – should be apparent in thearchitectural direction. This will bereflected in the level of integration,federation and collaboration that isaimed for. Actually, the architecturalblueprint and design principles arecrucial deliverables of this lifecycle,together with the actual applications.

HUB application services must becarefully tested: A new platformrelease should be upward compatiblewith earlier releases in order not tofrustrate organizational use. This putsa particular focus on automatedregression testing and testing oforchestration of several services, bothinternal ones and externally acquired.As HUB application services arefoundational, they have the highestquality requirements, and an integraltest architecture may be needed todeal with robustness and stability,but also with security, compliance andcorporate integrity. Many innovationsoccur first in HUB applicationservices, which is also reflected intest approaches that deal with SOA,cloud, open standards and BPM.Documentation is particularly crucialfor communication to the future usersof the platform.

A HUB platform evolves continuallyand often; it needs to be distilled froman existing set of poorly integratedand redundant solutions. This is why,in addition to an approach such asTOGAF for architecture and agile RUPfor platform development, much focuswill be on rationalization. The amountof work that can be done offshore isprobably never more than 50%.

The necessary skills includearchitecture, SOA, cloud, openstandards, middleware tools, ESB,BPM suites, end-to-end testing, multi-channel distribution testing, socialmedia and procurement.

8

4. CAR AppsCAR Apps are created in, or in nearproximity to, the business. Becausethey are close to the market-facingunits – and possibly to clients – thedynamics of these applications reflectthe volatility of the outside world.CAR Apps address many direct,operational and tactical needs of thebusiness and provide direct, measurablevalue. They bring differentiation tothe enterprise, on top of the non-differentiating elements of the TRAINand the somewhat differentiatingelements of BUS applications.

The tools being used are simple andrequire few specialized IT resources.CAR Apps illustrate the shift toBusiness Technology from InformationTechnology. To be effective, CARApps must be created in days orweeks, rather than in months. Theymay have a relatively short life, inwhich case they typically will bereplaced, rather than continuallyenhanced and expanded.

CAR Apps are built on sharedplatform services or simply boughtin the cloud. The first categorymay involve platform services forBusiness Process Management,Business Rules Management,intelligence, analytics, portals,enterprise content managementand mobile applications. Solutionsmay be created by orchestratingreadily available services, bothinternally (often supplied byTRAIN and BUS Apps) and externallyacquired. This leads to “compositeapplications” that spawn multipleprocesses, services and data sources.Lightweight “glue” programminglanguages (e.g., Ruby, PHP, Python,JavaScript) may be used to integrateand augment services, as well as“cloud development platforms”such as Force.com, Red Hat’sOpenShift or Windows Azure andmobile development platforms likeApple’s Cocoa.

Business units are in charge of CARApps, ensuring optimal leverage of thesupplied enterprise HUB applicationservices, in close collaboration withCentral IT. Although many CAR Appsare built with low-tech tools, they stillmay require more specialized ITresources. These will be located in thebusiness units themselves, orresourced from Central IT.

The architectural approach to this areais typical to engagement models suchas Capgemini’s BusinessTechnologyAgora3 in which business drivers aremapped on technology solutions andthen quickly put into action.Architecture is more a question ofaligning to the HUB, rather thancreating something new. However,using unified, integrated informationand shared, enterprise services iscrucial to achieving the desiredbenefits. Failure in this area willultimately lead to island automationand applications sprawl (think of thecurrent heap of “homebrew” Excel-based applications). Continualrationalization must therefore be builtinto the architectural approach,including an explicit focus onapplications retirement.

Testing must focus on properalignment with the enterpriseplatform. However, new approachesmay be needed to test the functionalcorrectness of applications that arebuilt with non-software engineeringtools. A sandbox environment may beneeded and version management will

help to keep a stable, provenenvironment. The tester needs tounderstand both the business contextof the application and the specificBusiness Technology tools being used.End-to-end business process testing isemerging here. Exploratory and agiletesting will be more effective thantraditional approaches. In general,errors in this category of apps mayhave less far-reaching consequences,although blunders in communicationor marketing can cause serious damageto the reputation of an organization.

Methods applied in this area typicallywill be lightweight, agile and action-oriented, such as SCRUM. Theyassume a high level of involvement ofthe intended users of the app in thedevelopment and maintenance of thesolution. Capgemini’s Rapid Design &Visualization (RDV) accelerated designmethodology may be applied forrequirements specification. Offshoreleverage is possible, but likely lessthan 35%.

For this lifecycle (and SCOOTERApps as well) contractual agreementsare more iterative and the targetedresults may be more “aspirational tobe” than a fixed outcome based onService Level Agreements. Theperformance may be more dependenton the realization of “business points”– in terms of business benefits andvalue achieved – than “function

3 “Building the BusinessTechnology Agora with Capgemini’s TechnoVision,” Capgemini, 2010

Application Services the way we see it

From Train to Scooter 9

points.” A contract may describeenvisioned final results andintermediate plateaus but wouldtypically focus more on “rules for thejourney” such as length of a cycle,architectural foundation, budget limitsand methods for collaboration.

The necessary skills includeexploratory/agile testing, businessanalysis, BusinessTechnology Agorainteractions, SCRUM and other agileapproaches, next-generationprogramming languages, BusinessTechnology tools (Business Intelligence,Business Process Management suites,Business Rules Engines) and mobileapplication platforms.

5. SCOOTER AppsSCOOTER Apps are created in theoperational business units by theemployees of these units themselves.They may be applications that arecreated as a direct response to acertain event but can also includehighly personalized user experiences,aimed at supporting individuals intheir work. In contrast to CAR Apps,most SCOOTER Apps require verylittle or no specialized IT tools andskills, nothing more than the skillsthat any IT-literate individualnowadays would possess. With that,SCOOTER Apps are completelyself-sufficient.

SCOOTER Apps are created in days,hours or maybe even minutes. Theyare probably short-lived and will bereplaced by other solutions, ratherthan extended or enhanced. It shouldbe the norm to “throw away” theseapplications frequently, a bit like weacquire – and then get rid of –applications in apps stores.

Like CAR Apps, SCOOTER Apps arebuilt on shared HUB applicationservices or are created using the toolsthat are supplied through the HUB.Often, building just means configuringa tool or defining declarative rules. Italso may involve visual GUI builders,do-it-yourself portals, mashup kitsand social media platforms.

Business units are in charge ofSCOOTER Apps, ensuring optimalleverage of the supplied enterpriseplatform services and tools. They maywant to leverage the in- and outsideworld – using the “power of thecrowd” to build applications and, to acertain extent, act themselves asprovider of a HUB platform.

The architectural approach forSCOOTER Apps is to use whatevertools, services and information areavailable – preferably through CentralIT and the HUB, but with publicresources as well.

Testing must focus on compliancewith corporate policies so as to avoidunwanted exposure of informationand data to the outside world. Thismust, however, be a proactive activity,

as compliance afterwards will be anobstacle to the short time-to-marketthat is typical of this lifecycle.Preferably, testers are already involvedin planning and designing thesolution, rather than during – or evenafter – the building phase. SCOOTERapplications will often connect to theoutside world so – again – end-to-endbusiness process testing is crucial.

There are no formal methods appliedin this lifecycle. Rapid Design &Visualization may be applied toprototype scenarios and then used tobring them to life. Offshore leverage ishighly unlikely.

Skills needed include exploratory andend-to-end business process testing,knowledge of social media and mashuptools, and typical business-orientedtools (BPM, BRE, social BI, etc.)

application portfolio, the need for ashift towards more valuable BusinessTechnology solutions, and the necessityof applications rationalization – andbuilding a HUB platform – to createthe foundation for the shift.

We have a blueprint for the ITorganization, so that we can discusscentral versus decentral models,options for ownership andalternative demand/supply chains.For each of the categories ofapplications, we thus can discussoptions for governance. Again, ithelps us to plot a path towards thedesired situation. In general, moreorganizations will seek to decentralizetheir CAR and SCOOTERapplications, which may lead to thereallocation of IT staff (and budgets)across the organization.

10

Summarizing the Five LifecyclesPutting it all together, we have createda non-exhaustive summary of thelifecycle attributes – with examples –in the accompanying matrix (seebelow). We encourage you to thinkfurther – and collaborate with us –around solutions, accelerators andother characteristics of each lifecycle.

Delivering on the Promise ofBusiness TechnologyUnderstanding – and acknowledging– that there are different ApplicationLifecycles is a powerful tool whenfollowing up the initial euphoria ofdiscovering and exploring the nextgeneration of Business Technologysolutions:

We may use the five types toidentify an ideal portfolio mix – interms of budget and focus – and to

perform a gap analysis on thecurrent situation. From there, we canplan for and then execute a portfoliotransformation, even tracking benefitswhile the transformation evolves. Inmany cases, the overall IT budget ismainly spent on TRAIN and BUSapplications, where thinking in termsof HUB apps and putting more focuson CAR and SCOOTER applicationswould increase the value of IT and thesatisfaction from the business side.Also, in typically distributedorganizations, too many differentTRAIN and BUS applications arefound, all based on their ownplatforms and technology stacks andhighly overlapping in functionality.These situations require applicationrationalization, an effort that isdifficult to ignite. The ApplicationLifecycles should be used to discussthe imbalance of the current

Characteristics of the Five App Lifecycles

Application Services the way we see it

The HUB lifecycle is the placewhere two worlds meet. Therelatively short-lived, action- andinformation-oriented requirements ofthe business side are translated into aset of services that unleash the powerand knowledge that are contained inthe core and foundational systems onthe IT side. It is the crucial enabler tothe promises of a fully aligned“Business Technology Agenda” andshould be central in any follow-updiscussion. For the IT department,building a compelling, well-definedand well-communicated catalog ofHUB services provides the key tobringing all threads together. Itinvolves making choices about openstandards, platforms, tools andsuppliers. It brings back thearchitectural allure to IT, but at thesame time the HUB can only be builtstep by step, in close alignment withactual solutions being created in all ofthe other lifecycles – obviously with anew focus on CAR and SCOOTERsolutions. Very few organizations willbe able to permit themselves to buildan entire HUB catalog before buildingthe first solutions on top of it.

We get to understand what newcapabilities will be needed in theforthcoming years, what contractualforms will emerge, what new toolswill be used and what acceleratorscan be applied. In each of thelifecycles, substantial changes areimminent.

� TRAIN applications will be highlystandardized and normalized. Theiroverall number within anorganization needs to be broughtdown significantly and cloud-baseddelivery will be typical for newsolutions. The existing base of legacyapplications (custom-built or ERP) isin dire need of rationalization, and

making “TRAIN applications behavelike TRAINS again” is one of thebiggest challenges of the forthcomingyears. Full outsourcing may be theway to accelerate such a change.

� BUS applications need to be built ina more flexible, agile way and muchfocus will be on boostingproductivity through frameworks,sector-specific templates, model-driven development and re-use. Amigration to cloud-based deliverycan be instrumental in achievingthese objectives.

� CAR applications will be at the coreof a new wave of high-valuesolutions, delivered very near to thebusiness side of organizations. Itinvolves new, often yet unknowntools and platforms to createsolutions and new ways of managingrequirements and engineering.Leveraging the HUB is crucial forproductivity, but just as much ofensuring consistency and alignmentacross the organization.

� SCOOTER applications will typicallynot be built by IT experts, butinstead by business users who willcontinually explore new ways ofquickly creating their own,individual solutions. It is a matter ofunderstanding the requirements ofthese users, particularly in terms ofthe HUB services needed, ratherthan being too prescriptive about thetools to be applied. Providingcommunity support can be highlyeffective, as users can learn fromeach other’s solutions and can jointlycreate even better solutions.

� For the IT industry, a new andinspiring perspective emerges onhow to both leverage distributed,offshore resources and how – andwhere – to excel with local, onshoreresources. It is of course likely that

TRAIN and BUS applications will bebuilt and maintained more bygeographically remote teams thanwill CAR and SCOOTERapplications. Local IT professionalsneed to move yet closer to thebusiness side of organizations thanthey used to be and they will have tomaster a new palette of tools,platforms and accelerators.

Technology is becoming intimately,irreversibly entwined with business.To fully leverage the potential of thisunique marriage, we mustacknowledge – and appreciate – thatwe need stability and predictabilityhand-in-hand with flexibility andspeedy action. We are convinced thatthe five Application Lifecycles willhelp you in achieving this.

For the IT industry, a newand inspiring perspectiveemerges on how to bothleverage distributed,offshore resources andhow — and where — toexcel with local, onshoreresources

From Train to Scooter 11

Ron [email protected]

Rightshore® is a trademark belonging to CapgeminiCopyright© 2011 Capgemini. No part of this document may be modified, deleted orexpanded by any process or means without prior written permission from Capgemini.

www.capgemini.com/technovision

With around 115,000people in 40 countries,

Capgemini is one of the world’s foremostproviders of consulting, technology andoutsourcing services. The Group reported2010 global revenues of EUR 8.7 billion.

Together with its clients, Capgeminicreates and delivers business andtechnology solutions that fit their needsand drive the results they want.

A deeply multicultural organization,Capgemini has developed its own wayof working, the Collaborative BusinessExperienceTM, and draws on Rightshore®,its worldwide delivery model.

More information is available atwww.capgemini.com.

About Capgemini and theCollaborative Business ExperienceTM

To learn more about the five Application Lifecycles and Capgemini’sApplication Services please contact:

Illustrations by: Alfredo Carlo, Housatonic Visual Agency