From Train to Scooter - Five Application Lifecycles That Address Differing IT Dynamics Within Your Organization
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Application Services the way we see it From Train to Scooter Five Application Lifecycles That Address Differing IT Dynamics Within Your Organization Many organizations struggle to To facilitate the dialogue, we use this introduce a new generation of whitepaper to introduce the concept technology solutions that are created of five different “Application and used in the nearest proximity to Lifecycles.” Building on a simple the business side. The cloud, Web 2.0 metaphor of modes of transport, we and the mobile revolution offer direct show how insight into differing value to the business with relatively application dynamics can help to plan low initial costs and short time to a renewed generation of IT activities market. Often, however, the way these across the entire organization. solutions are delivered and applied differs dramatically from what the IT Bleeding-Edge IT: Avoiding the department is used to. It once again Valley of Delivery Disillusion opens the debate around ownership With the increasing availability of and governance of IT, around cloud-based applications, Web 2.0, centralization versus decentralization web services, business process and and contractual models, as well as rules management suites, real-time around timing and priorities. Without business intelligence and enterprise mutual understanding, the result may mobile platforms, a new generation be a lack of alignment, growing of bleeding-edge IT solutions is on frustration or – even worse – the rise that: fragmented solution deployment and I Are created in – or very near – scattered investments. the actual business units.
I Produce quick and directly This can easily lead to a situation in
measurable value. which Central IT is getting more
I Apply new, easy-to-deploy tools and isolated from the business side,
platforms. condemned to sustain existing
I Do not require the typical
systems with an ever-shrinking
budget, no headroom to innovate or
specialized IT skills of the past to
to expand and thus inclined to say
build.
“no” to any new IT initiative. On the
I Are delivered in an accelerated and
business side, do-it-yourself
flexible way. “bricolage” IT may bring some short-
term solutions but can easily result in
This poses important questions applications sprawl, redundancy,
around shifts in the delivery of IT uncoordinated use of corporate
solutions: information and ineffective use of
I Who is in charge of the portfolio, splintered budgets.
budgets, projects and priorities?
I What is the right – possibly global – So how to avoid getting caught up in
The key to avoid getting mix of delivery resources? this valley of delivery disillusion, with
so much inspiration coming from a
caught up in the valley of I What new capabilities and skills are
completely new incarnation of the IT
declining disillusion is in needed and what may become
solutions landscape?
redundant?
distinguishing — and
I What are the architectural
The key is in distinguishing – and
managing — different considerations to take into account? then actively managing – different
Application Lifecycles. I What tools, methodologies and Application Lifecycles, each with its
accelerators should be used? own dynamics, timing, economic
I And as a result, how long will it take models, governance and design
to create solutions? considerations.
Clearly, in many organizations there is Two of these lifecycles of applications
friction between “Central IT” – in (or, as it becomes more and more
charge of the big legacy systems, ERP appropriate to speak of “application
and data stores – and “decentral” services”) pertain to the stable, often
business units that typically create (or more centralized part of the IT
are tempted to create) this new landscape. Two others pertain to the
generation of “Business Technology” more volatile, business-oriented part.
solutions. The bulk of the budget may Connecting them all, we distinguish a
be consumed by Central IT, which fifth, crucial lifecycle that provides the
uses it to keep the lights on for the flexible, yet mission-critical platform
existing applications landscape. The application services for the business
focus there may be on industrialization, side to thrive on, while unlocking the
simplification and trying to control full enterprise potential of the
the overall costs. On the other side, centralized application services and
business units – possibly holding their information. It is this platform “hub”
own decentral IT and budget – may where the IT and business sides meet
be acquiring and developing new, again: After identifying solutions with
lightweight solutions that satisfy their the highest value to the business, the
real-life requirements and deliver hub is the place where the actual
tangible value. connection in delivery is being made.
2
Application Services the way we see it Metaphor: Modes of Transport A simple metaphor from the world of transport helps explain the dynamics of the five lifecycles. To reach our destination, we may have several alternatives to consider. 1. The TRAIN is a stable, robust mode of mass transportation. It is not flexible but reaches its goal in a predictable, straightforward way (ignore possible regional differences, we are not comparing Great Britain and Scandinavia here). It is based on an infrastructure that is designed and built to last for decades, and everybody who uses that train travels in the same way from A to B. There is no chance to go by train where no route is defined. The functionality is provided in a highly efficient and standardized way (at least if we look at the effort per passenger). The only option may be choosing first class if we’re interested in extra comfort. One does not customize a train. Many people will be affected when trains do not run. 2. The BUS is also a relatively stable mode of mass transportation, but clearly with more flexibility. A bus can take a detour if circumstances require, and it can be used for alternative purposes on top of the fixed schedule. Moreover, it usually connects directly with the train system. A bus still needs a road, but a flexible route 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 specific enterprise use and customize and brand them to reflect the organization’s unique image. 3. The CAR is a much more agile, individualized means of transport. It can take a person – or a small group of people – to most of the places they want to go. There are many different types of cars to choose from and their owners will configure and adapt them to reflect their individual, differentiated styles and personalities. People – particularly men, admittedly – often confess to “love” their cars: Their car gives them a sense of freedom and it is often tightly integrated with their everyday lives. 4. The SCOOTER is a lightweight, extremely flexible and individual method of transport. It can be used for the “last mile,” bringing you to places even cars cannot reach. In crowded areas, scooters are faster than any other means of transport. There are many different types of scooters and they can only transport one or two people at the same time. It is easy to rent a scooter – just for a day or so – 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 as well, as it is fast, cheap, does not need a heavy engine or lots of fuel, and is extremely agile. 5. All of these modes of transport are tied together through a HUB, best seen as a modern train station with carefully provided additional services. Such a hub is truly multi-modal in that trains, buses, cars and scooters all can conveniently “dock” and people can easily change their means of transport, while benefiting from a host of add-on services. A well-designed station like this functions as the pumping heart of the city. From Train to Scooter 3
The Five App Lifecycles and green TechnoVision clusters solutions, including the total
In the same way as we would select (business process and business rules duration of use
our mode of transport – depending management, real-time intelligence I The Application Area in which the
on the actual situation – we would be and analytics, collaboration and user solution is delivered
able to position the five different experience). The Hub lifecycle I The Governance, in terms of
Application Lifecycles (in short, App connects these two worlds; it is where
ownership and place in the
Lifecycles) in our Business Technology IT and business entwine, and it
organization
landscape. If we map them to should be positioned in the middle.
I The Architecture considerations
Capgemini’s TechnoVision clusters1, If we rotate the picture of the
we start to see that certain categories TechnoVision framework, we can and typical challenges to the design
of IT solutions have a natural “fit” visualize the five App Lifecycles from I The Testing requirements of the
with specific lifecycles. And although left to right, as has been done here solutions, also pertaining to quality,
there is no 1:1 connection between a (see accompany diagram below, robustness and documentation
specific solution category and an App “The Five App Lifecycles”). I The Delivery characteristics such as
Lifecycle, we can safely state that the methods, tools, accelerators and
two more robust, stable lifecycles – Describing the App Lifecycles sourcing mix
Train and Bus – mostly pertain to the To further understand the dynamics I The Key Capabilities, existing and
TechnoVision “blue” clusters of each lifecycle, we identify some
new, that are needed
(particularly Sector-as-a-Service, the characteristic attributes:
foundational, core applications of an I The typical Rhythm of creating –
organization). The more agile and frequency of enhancing –
lifecycles fit with the orange, yellow
The Five App Lifecycles
1 “Building the BusinessTechnology Agora with Capgemini’s TechnoVision,” Capgemini, 2010
4
Application Services the way we see it
Let’s look in more detail at these
five lifecycles:
1. TRAIN Apps
TRAIN Apps are foundational
solutions that organizations need as
the backbone for their operations.
These solutions are very stable and
provide little or no differentiating
power, let alone specific traction with
business drivers. They are, however,
at the heart of operations, may service or even in combination with
contain crucial corporate knowledge Business Process Outsourcing. It’s
and need to be robust, stable, becoming quite unlikely that new order to avoid unwanted side effects.
compliant with rules and regulations, TRAIN Apps are developed from This type of application is particularly
and predictable. scratch, but generating code from suitable for automated testing, and the
standard sector/industry models may focus of the tester could be more on
TRAIN Apps tend to change little. occur more frequently. technical challenges and tooling,
New, major releases should typically rather than business challenges.
only occur in yearly cycles, although TRAIN Apps are owned by the IT Documentation must be up to date
ongoing maintenance work might be organization and there should be a and actively maintained, as it captures
the norm. As these applications are well-defined, periodic process to knowledge of the systems for many
the typical backbone of an enterprise, involve the business community for years. As more TRAIN Apps will be
a frequent flow of changes to them the new release. As new releases may procured as SaaS-based ERP, special
suggests systems that are faulty, over- introduce relatively big changes to the tools and approaches must be used
customized and difficult to maintain. functionality, this will involve a change for testing packages. Given the typical
Nowadays, often too much of the management program across the size and impact of the change, proper
overall IT budget is spent on TRAIN organization. Frequent applications change management needs to be in
Apps – sometimes hugely overlapping maintenance (AM) should be place and special attention needs to
ones on multiple platforms – especially minimized, but taken care of through be paid to training the users of the
if we consider the limited degree of a well-defined, mature AM process. application.
business differentiation they provide.
The architectural approach focuses on A rather classic, linear, requirements-
Typically the underlying functionality stability, maintainability and providing driven approach is used to manage
can be provided as software off the a reliable set of foundational services. the lifecycle of the solution. ASL
shelf. Only in a few instances (often in There may be an ongoing lean effort and/or ITIL may be used for
fields where no market exists) is there to further improve foundational apps applications maintenance. Continual
no off-the-shelf software at all that can through simplification, rationalization may be needed,
be used, for example in the case of standardization (for example, de- particularly if existing TRAIN Apps
special government areas. customization) and rationalization, are outdated, difficult to maintain and
also taking into account that not standardized. And it may involve
Systems are based on classic ERP (for organizations have inherited many lean-style improvement and
example, finance and control, different legacy TRAIN Apps that approaches such as Capgemini’s
inventory, order management, MRP, overlap in functionality. Next to the “Agile Legacy Lifecycle.”2 Building,
core banking) or on bespoke – often main drivers of robustness and implementing and maintaining TRAIN
legacy – systems that support compliance, cost effectiveness is an Apps may involve up to 80% offshore
foundational activities of the important requirement for the design. resources. ERP is implemented – and
organization. The latter may be updated – as “vanilla,” refraining from
developed in COBOL, RPG, PL/1 or New releases must be tested excess customization. Code generators
4GL, but newer legacy core apps may extensively and a risk-based approach could frequently be used.
also have been developed in Java, C# (starting from a risk analysis) is
and – yes – ABAP. Newer foundational typical. There is a special emphasis on
applications may be purchased as regression and end-to-end testing in
sector-specific “vanilla” software-as-a-
2 “Agile Legacy Lifecycle,” Capgemini, 2010
From Train to Scooter 5
For this lifecycle (and for BUS Apps as catering to the needs of the business BUS Apps should be jointly owned by
well), contracts that are based on units involved. the IT and business organizations,
multi-year Service Level Agreements with the IT organization responsible
(SLAs) are typical. The needed results BUS Apps are changed and implemented for development, implementation and
can be well defined and are on a regular basis. The typical metric maintenance, and the business
predictable. The amount of change would be a season (for example, organization in charge of needs and
requests can be anticipated and salesforce.com features four major budget.
carefully managed. Going live with a releases every year, timed with the
solution in this category is a costly seasons). Implementing a new solution The architectural approach focuses on
and impactful process, hence it is should also take seasons, not years. flexibility, maintainability, speed of
done only every now and then and Smaller functional enhancements and implementation and providing easy
overruns on the deployment are to be bug fixes are applied in a more access to BUS services, the common
avoided. Contracts reflect the inherent continual way, with the AM process basis being a stable, elaborate and
complexity of this lifecycle and are being more cyclical and agile in proven approach. There needs to be a
often elaborate and highly nature. Speed-to-market is important proper balance among standardization,
professionalized, with some experts for this type of app: A time-box may the orchestration of readily available
dedicating a full career to the provide a fixed amount of time to get services, customization and bespoke
supporting process. the application to work and an agreed software. This implies a continual
“release calendar” would be quite rationalization effort, comparable to
The needed skills include proactive achievable, based on an actively what is needed for TRAIN Apps.
applications maintenance, applications managed requirements list. Pre-defined sector business models will
rationalization, retirement, requirements help to speed up – and standardize –
management, regression testing, Systems are based on “edge” ERP efforts in this area. This also pertains
model-driven architecture (MDA), (such as CRM, SRM, SCM and HRM) to architectural models (or DSLs,
legacy programming languages, as well as sector-specific applications Domain Specific Language) that
information analysis and business like Transportation Management and accelerate the development of
modeling. Investigative Case Management, but solutions that are in large part
may also involve enterprise content similar and in small ways different.
2. BUS Apps management and E-business packages.
BUS Apps are stable, yet flexible A certain level of customization is Testing is done in close alignment
solutions that provide organizations applied, although within defined with the business side and applied
with a certain degree of competitive boundaries to keep the solution throughout the lifecycle (rather than
differentiation. Being core apps, they manageable. More bespoke software at the end, which might reduce speed-
define the very essence of the should be expected in this lifecycle, to-market). Testers therefore need
organization. They may be key written in Java, C# or other more more focus on business issues as well,
enablers to some of the more stable modern programming languages. and the upcoming interest in context-
business drivers. Although the pace of Code generation from pre-defined driven testing is particularly relevant.
change is relatively slow, implementing business models may occur as well. They will work in close collaboration
changes and customizing the solutions Many of these edge applications are with the developers, possibly as a pair,
must be easy – while sustaining the delivered in an attractive SaaS model covering the entire lifecycle. Iterative
stable and standardized elements of (again, for example, salesforce.com), or agile testing is often applied, as
the solution. BUS Apps support which further pushes the need for well as model-based testing.
specific functions of the organization, limiting customization. Documentation must be up-to-date,
although it may be maintained in
retrospect after the solution has been
delivered.
An iterative, cyclical approach will be
the default throughout the lifecycle
(including applications management),
as it is risk-driven, involves the
business side in an interactive way
and delivers solutions within a fixed
time window. Methods may include
agile RUP and SCRUM but may also
be mixed with more linear
6
Application Services the way we see it
approaches. A “software factory” could enable all stakeholders to create cloud and “social.” The strategic
be a powerful accelerator for BUS solutions within the pace and direction of the company – and the
Apps, possibly involving code requirements of their own lifecycle way it wants to function and organize
generation from models and reusable dynamics. The HUB platform enables itself – should be apparent in the
frameworks (such as MDA). BUS flexibility and speed-to-market on one architectural direction. This will be
applications may involve up to 65% hand, but also brings the integration, reflected in the level of integration,
offshore resources. Rapid Solution robustness and data/process integrity federation and collaboration that is
Workshops and Smart Use Cases can that mature enterprises require. With aimed for. Actually, the architectural
speed up requirements management. that, the HUB is also a steward of blueprint and design principles are
Typical programming languages are open standards. crucial deliverables of this lifecycle,
Java, .NET, ASP, Ruby and PHP. together with the actual applications.
As new technologies emerge on a
Capabilities include proactive frequent basis and organizations want HUB application services must be
applications management, to benefit from them in a timely way, carefully tested: A new platform
applications rationalization, context- HUB Apps will evolve quickly in release should be upward compatible
driven testing, SCRUM, agile RUP, terms of new services they provide, with earlier releases in order not to
MDA/DSL and software factories, more in months than in seasons, but frustrate organizational use. This puts
business analysis/SEMBA, Smart Use not in weeks. All in all, the overall a particular focus on automated
Cases and IRMA for requirements design of the HUB itself is presumed regression testing and testing of
management. to be stable. orchestration of several services, both
internal ones and externally acquired.
3. HUB Apps A HUB may include Master Data As HUB application services are
HUB Apps – or better, HUB Management services, a business web foundational, they have the highest
application services – provide the services catalog that gives access to quality requirements, and an integral
crucial glue between the IT and foundational and core functions, a test architecture may be needed to
business sides of the organization, corporate “apps store” and “data deal with robustness and stability,
including the outside world. They market,” and contains all the but also with security, compliance and
“infostructural” facilities needed to corporate integrity. Many innovations
effectively create and compose occur first in HUB application
Business Technology Apps (for example, services, which is also reflected in
Enterprise Service Bus [ESB], BPM suite, test approaches that deal with SOA,
Business Rules Engines [BRE], portals, cloud, open standards and BPM.
mashup tools, BI, mobile services, Documentation is particularly crucial
security, etc.). Much of this will be for communication to the future users
cloud-based, although hybrid of the platform.
scenarios (a combination of on-premise
and public cloud delivery) will be A HUB platform evolves continually
typical in the forthcoming years. and often; it needs to be distilled from
an existing set of poorly integrated
HUB Apps are the pièce de résistance of and redundant solutions. This is why,
the IT department, as they are the in addition to an approach such as
powerful catalyst to create more TOGAF for architecture and agile RUP
business value from IT. The for platform development, much focus
requirements of HUB application will be on rationalization. The amount
services must be proactively aligned of work that can be done offshore is
with all stakeholders – both in probably never more than 50%.
business and IT – in order not to lag
behind. There must be a sense of The necessary skills include
collaboration, rather than “comply or architecture, SOA, cloud, open
die,” and architectural design standards, middleware tools, ESB,
principles must be carefully and BPM suites, end-to-end testing, multi-
convincingly communicated. channel distribution testing, social
media and procurement.
These architectural principles revolve
around open standards, open
solutions, SOA/service orientation,
From Train to Scooter 7
4. CAR Apps
CAR Apps are created in, or in near
proximity to, the business. Because
they are close to the market-facing
units – and possibly to clients – the
dynamics of these applications reflect
the volatility of the outside world.
CAR Apps address many direct,
operational and tactical needs of the
business and provide direct, measurable
value. They bring differentiation to
the enterprise, on top of the non-
differentiating elements of the TRAIN
and the somewhat differentiating
Business units are in charge of CAR
elements of BUS applications.
Apps, ensuring optimal leverage of the
supplied enterprise HUB application
The tools being used are simple and help to keep a stable, proven
services, in close collaboration with
require few specialized IT resources. environment. The tester needs to
Central IT. Although many CAR Apps
CAR Apps illustrate the shift to understand both the business context
are built with low-tech tools, they still
Business Technology from Information of the application and the specific
may require more specialized IT
Technology. To be effective, CAR Business Technology tools being used.
resources. These will be located in the
Apps must be created in days or End-to-end business process testing is
business units themselves, or
weeks, rather than in months. They emerging here. Exploratory and agile
resourced from Central IT.
may have a relatively short life, in testing will be more effective than
which case they typically will be traditional approaches. In general,
The architectural approach to this area
replaced, rather than continually errors in this category of apps may
is typical to engagement models such
enhanced and expanded. have less far-reaching consequences,
as Capgemini’s BusinessTechnology
Agora3 in which business drivers are although blunders in communication
CAR Apps are built on shared or marketing can cause serious damage
mapped on technology solutions and
platform services or simply bought to the reputation of an organization.
then quickly put into action.
in the cloud. The first category
Architecture is more a question of
may involve platform services for Methods applied in this area typically
aligning to the HUB, rather than
Business Process Management, will be lightweight, agile and action-
creating something new. However,
Business Rules Management, oriented, such as SCRUM. They
using unified, integrated information
intelligence, analytics, portals, assume a high level of involvement of
and shared, enterprise services is
enterprise content management the intended users of the app in the
crucial to achieving the desired
and mobile applications. Solutions development and maintenance of the
benefits. Failure in this area will
may be created by orchestrating solution. Capgemini’s Rapid Design &
ultimately lead to island automation
readily available services, both Visualization (RDV) accelerated design
and applications sprawl (think of the
internally (often supplied by methodology may be applied for
current heap of “homebrew” Excel-
TRAIN and BUS Apps) and externally requirements specification. Offshore
based applications). Continual
acquired. This leads to “composite leverage is possible, but likely less
rationalization must therefore be built
applications” that spawn multiple than 35%.
into the architectural approach,
processes, services and data sources.
including an explicit focus on
Lightweight “glue” programming For this lifecycle (and SCOOTER
applications retirement.
languages (e.g., Ruby, PHP, Python, Apps as well) contractual agreements
JavaScript) may be used to integrate are more iterative and the targeted
Testing must focus on proper
and augment services, as well as results may be more “aspirational to
alignment with the enterprise
“cloud development platforms” be” than a fixed outcome based on
platform. However, new approaches
such as Force.com, Red Hat’s Service Level Agreements. The
may be needed to test the functional
OpenShift or Windows Azure and performance may be more dependent
correctness of applications that are
mobile development platforms like on the realization of “business points”
built with non-software engineering
Apple’s Cocoa. – in terms of business benefits and
tools. A sandbox environment may be
needed and version management will value achieved – than “function
3 “Building the BusinessTechnology Agora with Capgemini’s TechnoVision,” Capgemini, 2010
8
Application Services the way we see it
points.” A contract may describe Like CAR Apps, SCOOTER Apps are as compliance afterwards will be an
envisioned final results and built on shared HUB application obstacle to the short time-to-market
intermediate plateaus but would services or are created using the tools that is typical of this lifecycle.
typically focus more on “rules for the that are supplied through the HUB. Preferably, testers are already involved
journey” such as length of a cycle, Often, building just means configuring in planning and designing the
architectural foundation, budget limits a tool or defining declarative rules. It solution, rather than during – or even
and methods for collaboration. also may involve visual GUI builders, after – the building phase. SCOOTER
do-it-yourself portals, mashup kits applications will often connect to the
The necessary skills include and social media platforms. outside world so – again – end-to-end
exploratory/agile testing, business business process testing is crucial.
analysis, BusinessTechnology Agora Business units are in charge of
interactions, SCRUM and other agile SCOOTER Apps, ensuring optimal There are no formal methods applied
approaches, next-generation leverage of the supplied enterprise in this lifecycle. Rapid Design &
programming languages, Business platform services and tools. They may Visualization may be applied to
Technology tools (Business Intelligence, want to leverage the in- and outside prototype scenarios and then used to
Business Process Management suites, world – using the “power of the bring them to life. Offshore leverage is
Business Rules Engines) and mobile crowd” to build applications and, to a highly unlikely.
application platforms. certain extent, act themselves as
provider of a HUB platform. Skills needed include exploratory and
5. SCOOTER Apps end-to-end business process testing,
SCOOTER Apps are created in the The architectural approach for knowledge of social media and mashup
operational business units by the SCOOTER Apps is to use whatever tools, and typical business-oriented
employees of these units themselves. tools, services and information are tools (BPM, BRE, social BI, etc.)
They may be applications that are available – preferably through Central
created as a direct response to a IT and the HUB, but with public
certain event but can also include resources as well.
highly personalized user experiences,
aimed at supporting individuals in Testing must focus on compliance
their work. In contrast to CAR Apps, with corporate policies so as to avoid
most SCOOTER Apps require very unwanted exposure of information
little or no specialized IT tools and and data to the outside world. This
skills, nothing more than the skills must, however, be a proactive activity,
that any IT-literate individual
nowadays would possess. With that,
SCOOTER Apps are completely
self-sufficient.
SCOOTER Apps are created in days,
hours or maybe even minutes. They
are probably short-lived and will be
replaced by other solutions, rather
than extended or enhanced. It should
be the norm to “throw away” these
applications frequently, a bit like we
acquire – and then get rid of –
applications in apps stores.
From Train to Scooter 9
Summarizing the Five Lifecycles perform a gap analysis on the application portfolio, the need for a
Putting it all together, we have created current situation. From there, we can shift towards more valuable Business
a non-exhaustive summary of the plan for and then execute a portfolio Technology solutions, and the necessity
lifecycle attributes – with examples – transformation, even tracking benefits of applications rationalization – and
in the accompanying matrix (see while the transformation evolves. In building a HUB platform – to create
below). We encourage you to think many cases, the overall IT budget is the foundation for the shift.
further – and collaborate with us – mainly spent on TRAIN and BUS
around solutions, accelerators and applications, where thinking in terms We have a blueprint for the IT
other characteristics of each lifecycle. of HUB apps and putting more focus organization, so that we can discuss
on CAR and SCOOTER applications central versus decentral models,
Delivering on the Promise of would increase the value of IT and the options for ownership and
Business Technology satisfaction from the business side. alternative demand/supply chains.
Understanding – and acknowledging Also, in typically distributed For each of the categories of
– that there are different Application organizations, too many different applications, we thus can discuss
Lifecycles is a powerful tool when TRAIN and BUS applications are options for governance. Again, it
following up the initial euphoria of found, all based on their own helps us to plot a path towards the
discovering and exploring the next platforms and technology stacks and desired situation. In general, more
generation of Business Technology highly overlapping in functionality. organizations will seek to decentralize
solutions: These situations require application their CAR and SCOOTER
rationalization, an effort that is applications, which may lead to the
We may use the five types to difficult to ignite. The Application reallocation of IT staff (and budgets)
identify an ideal portfolio mix – in Lifecycles should be used to discuss across the organization.
terms of budget and focus – and to the imbalance of the current
Characteristics of the Five App Lifecycles
10Application Services the way we see it
The HUB lifecycle is the place making “TRAIN applications behave TRAIN and BUS applications will be
where two worlds meet. The like TRAINS again” is one of the built and maintained more by
relatively short-lived, action- and biggest challenges of the forthcoming geographically remote teams than
information-oriented requirements of years. Full outsourcing may be the will CAR and SCOOTER
the business side are translated into a way to accelerate such a change. applications. Local IT professionals
set of services that unleash the power I BUS applications need to be built in need to move yet closer to the
and knowledge that are contained in a more flexible, agile way and much business side of organizations than
the core and foundational systems on focus will be on boosting they used to be and they will have to
the IT side. It is the crucial enabler to productivity through frameworks, master a new palette of tools,
the promises of a fully aligned sector-specific templates, model- platforms and accelerators.
“Business Technology Agenda” and driven development and re-use. A
should be central in any follow-up migration to cloud-based delivery Technology is becoming intimately,
discussion. For the IT department, can be instrumental in achieving irreversibly entwined with business.
building a compelling, well-defined these objectives. To fully leverage the potential of this
and well-communicated catalog of I CAR applications will be at the core
unique marriage, we must
HUB services provides the key to acknowledge – and appreciate – that
of a new wave of high-value
bringing all threads together. It we need stability and predictability
solutions, delivered very near to the
involves making choices about open hand-in-hand with flexibility and
business side of organizations. It
standards, platforms, tools and speedy action. We are convinced that
involves new, often yet unknown
suppliers. It brings back the the five Application Lifecycles will
tools and platforms to create
architectural allure to IT, but at the help you in achieving this.
solutions and new ways of managing
same time the HUB can only be built
requirements and engineering.
step by step, in close alignment with
Leveraging the HUB is crucial for
actual solutions being created in all of
productivity, but just as much of
the other lifecycles – obviously with a
ensuring consistency and alignment
new focus on CAR and SCOOTER
across the organization.
solutions. Very few organizations will For the IT industry, a new
I SCOOTER applications will typically
be able to permit themselves to build
an entire HUB catalog before building not be built by IT experts, but and inspiring perspective
the first solutions on top of it. instead by business users who will emerges on how to both
continually explore new ways of
quickly creating their own,
leverage distributed,
We get to understand what new
capabilities will be needed in the individual solutions. It is a matter of offshore resources and
forthcoming years, what contractual understanding the requirements of how — and where — to
forms will emerge, what new tools these users, particularly in terms of
the HUB services needed, rather
excel with local, onshore
will be used and what accelerators
can be applied. In each of the than being too prescriptive about the resources
lifecycles, substantial changes are tools to be applied. Providing
imminent. community support can be highly
effective, as users can learn from
I TRAIN applications will be highly
each other’s solutions and can jointly
standardized and normalized. Their
create even better solutions.
overall number within an
I For the IT industry, a new and
organization needs to be brought
down significantly and cloud-based inspiring perspective emerges on
delivery will be typical for new how to both leverage distributed,
solutions. The existing base of legacy offshore resources and how – and
applications (custom-built or ERP) is where – to excel with local, onshore
in dire need of rationalization, and resources. It is of course likely that
From Train to Scooter 11www.capgemini.com/technovision
About Capgemini and the
Collaborative Business ExperienceTM
With around 115,000 A deeply multicultural organization,
people in 40 countries, Capgemini has developed its own way
Capgemini is one of the world’s foremost of working, the Collaborative Business
providers of consulting, technology and ExperienceTM, and draws on Rightshore®,
outsourcing services. The Group reported its worldwide delivery model.
2010 global revenues of EUR 8.7 billion.
More information is available at
Together with its clients, Capgemini www.capgemini.com.
creates and delivers business and
technology solutions that fit their needs
and drive the results they want.
To learn more about the five Application Lifecycles and Capgemini’s
Application Services please contact:
Ron Tolido
ron.tolido@capgemini.com
Illustrations by: Alfredo Carlo, Housatonic Visual Agency
Rightshore® is a trademark belonging to Capgemini
Copyright© 2011 Capgemini. No part of this document may be modified, deleted or
expanded by any process or means without prior written permission from Capgemini.You can also read
