http-equiv="Content-Type">
face="Verdana, sans-serif">
style="font-style: normal;">Andy
Mulholland, CTO,
color="#0000ff">
face="Verdana, sans-serif">
style="font-style: normal;">Capgemini
face="Verdana, sans-serif">
face="Times New Roman, serif">Budget
season will be starting soon and of course all options for saving
money will be required and onto the table go all suggestions.
Virtualization is probably under way, so what about the other options
that new technology is offering? The popular three are moving to a
shared service center, data center consolidation and Business Process
Outsourcing, BPO. And circling around these are the issues of
software-as-a-service, security, and some very practical issues of
exactly what is involved in each. Why is cloud included? Mainly
because it is over-used, often wrongly, to describe anything and
everything, and as such it's not really a helpful term. In fact
it's more of a hype point adding confusion, and this blog is a
'back to basic options' piece.
face="Times New Roman, serif">Exploring
options seems a good idea except it can be time-consuming and
expensive if you don't know what you are looking for, and it's
also pretty concerning when considering changes to enterprise
applications. Consolidating enterprise applications looks a good bet,
and certainly with ERP it usually is a good plan to consolidate the
number of instances in use around a global enterprise. But what about
other applications in use around the enterprise in various
departments which do roughly the same thing? Assuming you can get the
political agreement of everyone, and that's a big assumption, then
it's usually less easy than you might suppose unless the selected
new single shared application has a good set of migration tools. The
'gotcha' is in the databases, often different products, but
almost always the non-obvious point is that the data models are too
different to be readily reconcilable.
face="Times New Roman, serif">The
time, cost and risk of the resulting migration is usually enough to
discourage the project and to prove the projected savings might take
longer than is acceptable after paying for the migration. The
practical answer is to start off with considering migration tools and
options at the beginning, and use this to figure out the choices,
rather than the classic evaluation of the applications to establish a
best, acceptable choice, and then look at the difficulties in
deploying.
href="http://www.it-checklists.com/Application_Upgrade_Checklist.html">Checklists
on
application migration and on
href="http://www.it-checklists.com/checklist_data_migration.html">data
migration
style="font-size: 8pt;" size="1">
are available
online to help anyone planning these moves.
face="Times New Roman, serif">It's
usually easier to take the route of data center consolidation to
handle this issue as at least 95% of applications can be operated on
virtualized servers, so moving to fewer data centers, and
consolidating in the remaining data centers is a simpler solution.
The US Government has widely published details and the results of its
href="http://www.datacenterknowledge.com/archives/2011/04/28/feds-will-shutter-137-data-centers-in-2011/">huge
consolidation
exercise . The real long-term issue in this is not
the traffic and use patterns of today, it's the patterns that are
building up, and the long-term issues about high or low cost energy
and the telecommunications zone. Specialist advice on the long-term
outlook for energy and telecommunications coupled with emerging
markets and the shift towards running as many 'services' as
applications can all change the obvious choices of today. Data center
planning in terms of location and use has never been so critical as
at this conjunction of so many changes.
face="Times New Roman, serif">CIO
face="Times New Roman, serif">
magazine had an interesting article on the
href="http://www.cio.com/article/464360/The_5_Pitfalls_of_Data_Center_Consolidation_and_Relocation">five
pitfalls
of data center consolidation a while back, but frankly
the horror story quoted is just bad planning.
face="Times New Roman, serif">
href="http://www.sig.org/i4a/pages/index.cfm?pageid=4232">BPO
has become really popular over the last couple of years, but what
and where to consider applying? Funnily enough it's back to some of
the same issues as mentioned above; invoicing has long been
considered as ideal for BPO and is a perfect example of what makes a
good process to outsource. There is no competitive differentiation in
the ability to prepare an invoice other than cost, and the data on an
invoice is, in most countries, defined by accounting rules so is
structured in a manner that a third party specialist can immediately
use. Volume and expertise in operations allows the specialist BPO
provider to achieve both better costs and to remove the need to
support a vital service by employing in-house expertise in case it is
needed.
face="Times New Roman, serif">BPO
works in other areas where the ownership of the process doesn't
provide any differentiation but is a business necessity, and can be
said to be defined and structured by clear circumstances, such as HR,
or Purchasing. So the real question in all three examples is less
about the visible part of the actual application, and more about the
underlying data model and how far this can be 'accommodated in any
change'. Of course the flip side of this is planning ahead, and the
explosion of data in various forms in the so called 'big data'
generation ahead is think very, very carefully about databases and
data models!!
face="Times New Roman, serif">So
there are some good moves to get the cost down, even simplify
operations and improve service levels, but the low hanging fruit has
mostly gone and it does need to be approached in a skilled manner to
gain from the experiences of those who have gone before! And most of
all it needs to have some real consideration of future requirements
that could look very different as more and more enterprises move to
embrace technology for new roles around their markets and work
practices with new devices.