=Paper=
{{Paper
|id=Vol-1753/paper1
|storemode=property
|title=Using Enterprise Architecture to Attain Full Benefits from Corporate Big Data while Refurbishing Legacy Work Systems
|pdfUrl=https://ceur-ws.org/Vol-1753/paper1.pdf
|volume=Vol-1753
|authors=Thomas Koehler,Steven Alter
|dblpUrl=https://dblp.org/rec/conf/wecwis/KoehlerA16
}}
==Using Enterprise Architecture to Attain Full Benefits from Corporate Big Data while Refurbishing Legacy Work Systems
==
https://ceur-ws.org/Vol-1753/paper1.pdf
Proceedings of CBI 2016 Industrial Track
Using Enterprise Architecture to Attain Full Benefits from Corporate Big Data
while Refurbishing Legacy Work Systems
Thomas Koehler, DBA Steven Alter, PhD
Senior Program Director Professor of Information Systems
Standards & Architecture University of San Francisco
DHL Express Europe IT San Francisco, United States
Bonn, Germany alter@usfca.edu
thomas.koehler@dhl.com
Abstract
In early 2011 DHL Express, a division of the Deutsche Post DHL Group, concluded that the core
infrastructure of its European Country Data Warehouse system (CDW) was approaching a crisis.
Vendors for its operating system, hardware, middleware, and database management systems
announced that those technologies had become obsolete and that support for those technologies would
end in the near term future. This paper explains how DHL converted the crisis into an opportunity to
create a well-constructed and easily maintainable basis for future development of new capabilities that
would benefit both DHL’s customers and DHL’s internal operations. Where possible without
unnecessary complications, this complex project improved existing capabilities. This paper provides
background about DHL and the type of operational data that would have to be migrated to a new
infrastructure. It describes the project, with special emphasis on how DHL leveraged its enterprise
architecture and also assured that each user group would fully understand the functionality they would
receive. That functionality would have to be at least as good as the existing functionality, and often
much better, without creating customer service problems during the transition. The paper ends with
lessons learned and concluding comments.
1 The Context
A. DHL Express1
The Deutsche Post DHL Group is the leading global brand in the logistics industry. Its family of divisions provides a portfolio of logistics
services including national and international parcel delivery, international express, and road, air, and ocean transport for industrial supply
chain management. DHL Express provides specialized solutions for growth markets and industries including e-commerce, technology, life
science and healthcare, energy, automotive and retail. With about 325,000 employees in over 220 countries and territories worldwide, DHL
connects people and businesses and serves an important role in global trade.
DHL Express serves its customers through more than 500 airports via three main global hubs in Cincinnati, Hong Kong and Leipzig.
The airports in its hub and spoke system serve as country gateways linked to over 45,000 service points that serve approximately 2.5 million
customers around the world, with 1.5 million in Europe.
B. DHL Express Europe
In 2014 the DHL Express Region Europe 32,000 employees operated roughly 660 daily flights and transported more than 150 million
shipments in 60 countries and territories. Those countries and territories are served from the main hubs in Leipzig (Global Hub),
Amsterdam, Bergamo, Brussels, Copenhagen, East Midlands (UK), Frankfurt, London, Madrid, Marseilles, Paris and Vitoria (Spain).
1
Extracts from the DHL Express – GLOBAL Fact Sheet July 2015
1
Proceedings of CBI 2016 Industrial Track
C. Enterprise Architecture at DHL
As DHL grew significantly through mergers and acquisitions, it started to experience redundancy and low value variation in significant parts
of its application system landscape. It became increasingly important to implement an enterprise architecture process that would avoid
reinventing previously created solutions and would reduce waste due to unnecessary inconsistency across different applications and
business units.
DHL treats Enterprise Architecture as the process of translating business vision into technology strategy. To support this process, an
enterprise architect is embedded in the cross functional team managing the translation from an organization’s business vision and strategic
intent to a road map of the required technological change.
This strategic alignment helps to exploit technology-supported processes that deliver the outputs needed to create product and service
offerings for customers. DHL’s enterprise architecture process aims at creating agile work systems that are able to react quickly to ever
changing market conditions. In other words, enterprise architecture focuses on how the business intends to address threats and opportunities
and how to evolve technology as the business environment changes.
2014 €m
Revenue 12,491
Europe 5,670
Americas 2,259
Asia Pacific 4,456
MEA (Middle East and Africa) 924
Consolidation/Other –818
Profit from operating activities (EBIT) 1,260
Operating cash flow 1,689
Return on sales (%) (EBIT/revenue] 10.1%
Table 1: Key DHL Express results for 20142
D. The DHL Convergence Program
DHL’s enterprise architecture effort contributes to the ultimate goal of establishing a single DHL Express Global Application Platform
(EGAP) consisting of 148 applications and then removing as many non-standard applications from service as possible. The EGAP
philosophy has become an undisputed underpinning of application development at DHL.
The goal of establishing EGAP makes it essential to decide whether or not to keep each existing capability that is being used. The term
business capability relates to a DHL’s ability to execute a defined and repeatable portfolio of business processes to produce a desired
portfolio of products, services and/or solutions (e.g. a Time Definite International service). This is achieved by deploying specific
participants, information, software assets and process technology in a logistics system that performs the work. The EGAP portfolio is
therefore the portfolio of 148 software assets (or applications) to be used at DHL to support all business processes defined in the Global
Standard Operating Procedure (GSOP). GSOP and the underlying EGAP portfolio (currently version 6) are under constant co-evolution to
meet customer needs.
The DHL convergence program started in 2008 in the aftermath of various mergers and acquisitions. From over 1400 applications in
2008, less than 500 remain, and the number continues to shrink. When a non-EGAP capability is specific to one country or one customer,
there are cases where DHL decided not to migrate that capability to the global platform and to treat it is an agreed exception, a so called
“specialist” in DHL Europe’s terminology.
The majority of currently used applications that are outside of EGAP are either waiting for a global replacement or subject of a Clean
Sweep, the type of project explained here. Only the highly complex or cross functional applications remain. All low hanging fruit has been
harvested by now. At this point, the remaining steps are based on a systematic, rigorous enterprise architecture procedure that has been used
since 2007 in various business units in the Deutsche Post DHL group.
2
Extract from table A.46 “Key figures by operating division” from the DPDHL 2014 Annual Report
2
Proceedings of CBI 2016 Industrial Track
2 The Solution
The Clean Sweep for CDW
In early 2011 DHL Express Europe concluded that key components of its Country Data Warehouse system (CDW) - the operating system,
hardware, middleware, and database management system - were far along a trajectory from “supported” to “end of life” to “end of service.”
Figure 1 illustrates the general form of that trajectory. Vendors usually withdraw a software product in two distinct steps. As long as an
application is supported, vendors work under a Service Level Agreement (SLA) to provide patches or spare parts as contractually agreed.
Eventually the product moves to “End of Life” and then to “End of Service.” A clock starts ticking as soon as a vendor officially announces
the End of Life and End of Service due dates. As an example, Microsoft officially flags those dates for their operating systems on its life
cycle support page3. So once a system reaches End of Life status, it is time for a “clean sweep”.
Figure 1: Implications of life cycle stages for vendor products
The highly customized CDW was built in the late 1990s with the promise of providing most of the operational and planning information
that would be needed by most operational units within DHL Express Europe to operate in DHL’s global network. In addition to the fact that
the promise had not been met, DHL identified four different types of legacy issues that applied to various parts of CDW:
a) Strategic legacy issues: Some business processes that CDW supported in the past had been changed greatly or discarded.
b) Financial legacy issues: CDW was too expensive to maintain.
c) Operational legacy issues: Changes in the competitive and regulatory environment and changes in internal infrastructure required
significant changes in CDW.
d) Technical legacy issues: Vendors would no longer support CDW after 2014.
To address these issues, DHL Express Europe undertook a major program that it called Clean Sweep CDW. DHL systematically
assessed CDW’s 362 IT capabilities that were used in 29 European countries and hosted on 30 servers. DHL decided whether to eliminate
or refurbish each of them one by one.
3 The “Clean Sweep” Approach
The goal of a major refurbishment project is to maintain or create operational and technical capabilities that support both customers and
DHL’s internal operations. DHL’s Clean Sweep approach to infrastructure refurbishment emphasizes meeting customer needs and
satisfying or exceeding customer expectations. Once the updated capabilities are released to production all capabilities that have become
obsolete are removed from service thereby completing the “Clean Sweep”.
Project Clean Sweep CDW was conducted in a linear sequence of four standalone projects that were budgeted individually. At DHL
such a portfolio of projects is managed in a program by a program manager.
• Project 1. Legacy assessment: “What we have in use”
The first project examined the customer-related and operationally-related value of existing legacy assets. It looked for ways to evolve
toward the desired functionality that might not be available in the legacy capabilities.
• Project 2. Strategic design: “How to handle it”
The second project generated agreement about how to handle each redundant and obsolete capability still in use. It emphasized joint
decision making about which existing capabilities should be retained for future usage.
3
http://support.microsoft.com/en-us/gp/lifecycle
3
Proceedings of CBI 2016 Industrial Track
• Project 3. New system development: “Making it happen”
The third project reconfigured existing capabilities so that they would fit into an enterprise architecture that addressed current and
forthcoming customer needs and could be maintained for the foreseeable future.
• Phase 4. “Clean up”
The fourth project removed legacy components from service as soon as newly deployed components delivered equivalent or improved
capabilities or performance.
Table 2 summarizes time lines and several key milestones for each of the projects.
Leg Timeline Key Task Main Output
Project 1 Q4 2012 - Review of the 220 Baseline and desired end-state
Q1 2013 legacy components
in use
Project 2 Q1 2013 - Design, align and Agreed joint course of action and
Q3 2013 agree on a legacy decision points to get to the agreed
strategy for each portfolio of capabilities in the
capability and predefined desired end-state
component found
Project 3 Q4 2013 - Build the to-be The agreed end-state
Q4 2014 system landscape
Project 4 Q3 2014 - Final and Code removal, hardware
Q1 2015 conclusive decommissioning, Solution Support
decommissioning contract termination, hosting contract
of CDW termination and license cancellation
Table 2: CDW's project sequence at a glance
Each of the Clean Sweep projects will be discussed in turn.
A. Project 1: Legacy Assessment
A legacy assessment was conducted for each IT capability in CDW. The main idea of the legacy assessments was to determine whether
each capability actually was being used, and if so, whether it had all of the desired or necessary functionality.
The assessment results were documented in various detailed specifications as well as a briefing slide deck for senior decision makers.
These documents were produced in five generic steps. Aspects of each step in the legacy assessment will be discussed briefly.
Gather available documentation. This step provided a rough idea of how well or poorly a software asset was documented. This step
found that CDW presented all variants of partially disorganized or erroneous documentation. Many of the issues were related to the fact that
CDW was originally built to deliver a fixed set of reports for senior management. That report set was never used. Nonetheless, some users
exploited the data available in CDW and built workarounds which added value at the time they were built. The quality of the workaround
was directly related to the technical skills of the user. Figure 2 summarizes the results from the initial overview.
Create initial overview. It was apparent that the original purpose of CDW was never achieved and 12 countries did not use CDW at all.
Countries that used it only used those parts that were included in country-specific workarounds and were not in use elsewhere. None of the
reports of the original setup were used, but CDW was used as a data source for consumer systems for some purposes that were not known.
An interim working document identified 308 reports and 15 interfaces that were labeled ‘Other Usages’. Figure 2 summarizes the results
from the initial overview.
Figure 2: Summary of the legacy assessment results
4
Proceedings of CBI 2016 Industrial Track
That interim document was developed further and become an important part of the project documentation. During CDW’s end game, it
was updated to identify every report and ‘Other Usage’ that was found. All relevant stakeholders were asked to sign off that each report or
‘Other Usage’ either was to be discarded or should be retained based on a business case for doing so.
It was extremely important that the results from the audit would be transparent to all decision makers and that all stakeholders would
have a real say in the changes that would be coming. The stakeholders had to indicate that they understood how upcoming changes might
affect them.
The high degree of stakeholder involvement helped in minimizing resistance to changes, which turned out to be very limited. All
stakeholders were invited to make a case for each capability to be retained. Business stakeholders were adequately informed and could
participate fully in a fact-based decision making session. Their participation was especially important since they identified business benefits
and confirmed a cost case for each capability. The only initial resistance was related to contractually agreed reporting for key account
customers.
Conduct technical deep dive. The third leg of the journey was about understanding technology in use. Even the fact that CDW itself was
comprehensively documented by its service owners and solution support team did not help much because CDW was used differently than
intended. Its initial set of reports was not used, but local CDW experts exploited its data tables as a data source. The analysis found that 9 out
of 42 tables were of particular interest as a data source for workarounds or even as a data mining source. The most challenging part of this
exercise was to map the content of reports and ‘Other Usage’ to its origin in CDW.
Validation of data fields proved a noteworthy issue for a number of reports or ‘Other Usages’. An example is that the field title ‘’name”
meant different things in different reports. It might refer to a sender, account (in case the sender is a subsidiary), recipient, or payer (which
can be a third party). As DHL’s service portfolio evolved over the years the meaning of field validations changed. The project team did two
things to overcome this issue. It generated a facsimile of the report as a PDF and changed the field validation accordingly to make sure that a
report to be retained had the correct data and look and feel. If a report was to be retained, both the PDF and the updated field validations
were documented for the landscaping to come.
The technical analysis found that static report set ups led to workarounds when business needs changed. In many cases those
workarounds added genuine value. Ideally, CDW should have used a dynamic report generator so that reports could be generated in a drag
and drop fashion instead of relying on a fixed set of reports.
Understand usage and value to business. This step in the legacy assessment was about understanding how the interplay of all
components of the current work system delivers products and services to customers. The analysis focused on what processes were in use,
how process technology supported processes, and how software assets provided information to process participants. In some cases the
operation of processes differed from process archetypes expected by senior management.
The key objective of this step was mapping what was in use and how it added value. At DHL Express, process blueprints are defined in
a Global Standard Operation Procedure. Whenever a process in use was not compliant with current standard operating procedures, the
process and associated technology, information and participants were challenged. The only cases where noncompliant processes were
retained were those that were classified as best practices that would become the new global standard and others that were required
contractually or legally. The latter two cases were documented in Architecture Concession Agreements which approved them for two years.
After two years they were to be revisited and challenged again.
Final write-up. The final write up compiled this massive amount of information into a form that was usable by decision makers. It also
provided detailed information for Enterprise Architects to help them decide on how to deal with each capability in use.
In essence, the final write-up compiled a capability list with executive summary style information for each capability plus detailed
specifications that complemented any useful documentation that existed. This set of documents was discussed with all stakeholders, leading
to agreements about which capabilities were to be retained. The final list of capabilities (including business vision and strategic intent for
each) was transformed into a road map of the technical changes required to reach that desired end-state. This led to 26 work orders for
vendors to implement the required changes in the target landscape.
B. Insight about Workarounds
An important conclusion from the legacy assessment was that CDW was not actually fulfilling its initial promise. At the time of the analysis
none of CDW’s originally defined reports for senior management were being used. Almost all IT capabilities that were not contractually or
legally required were used for operational support and incident management rather than management reporting in the initially intended
standard information pack.
While the initially designed reports were not being used at all, 84 workarounds had been implemented over time by local IT staff or local
vendors to address front line issues. CDW captured the necessary data and made it readily available in some of its data base tables. The
workarounds were necessary to transform the available raw data into useful information for participants, senior managers, or even third
parties (usually local authorities or key account customers).
Based on experiences with workarounds that had been institutionalized as part of everyday practice, one of the goals for the rest of the
project was to benefit as much as possible from those efforts and from insights that had been built into the many workarounds that provided
necessary management information. Thus, some workarounds were seen as valuable innovations, not just housekeeping adjustments.
5
Proceedings of CBI 2016 Industrial Track
C. Project 2: Strategic Design
The second project included the design, alignment, and agreement on a strategy for each component and capability that was to be retained
globally. This was the most challenging part of the Clean Sweep because it involved all 308 capabilities within CDW, 3 interfaces from
source systems to CDW, and 15 interfaces from CDW to target systems. All of that was jointly scrutinized by senior users, enterprise
architects, service management, and suppliers in the capability review procedure shown in Figure 3.
Figure 3 illustrates how those capabilities that would be retained in future were selected in the joint review by Senior Users from Sales,
Customer Service, Operations or Customer Accounting and local Subject Matter Experts from the same local function. Whenever a country
requested retaining a capability for future use, the country representative made a business case for it to show that it was a demonstrated best
practice to be made available globally.
Once a Senior User approved retaining a capability it was handed over to the Enterprise Architects to find a home where that capability
could be viewed as “future-proof,” i.e., that would be consistent with the enterprise architecture and therefore could be effective to use and
efficient to maintain and improve in the future. Once that new home was identified, the IT function and the associated vendor determined
the required course of action including cost and timelines.
Figure 3: The Clean Sweep capability review procedure
Surprisingly, a majority of the capabilities in CDW (253 out of 308) were obsolete, outdated or rejected as no longer adding value. Given
that CDW was developed before 2000, this suggests what might be called bad housekeeping. Most undocumented features used business
rules that were outdated. In those instances, customers received contractually required transit time reports that made performance appear
worse than the actual results.
The analysis did not dispute that many capabilities added value at the time they were created. But as with Romania’s Route load report,
many were superseded by global deployments over time. Good housekeeping for IT systems is only possible with documented capabilities.
Almost all undocumented capabilities either had a negative customer impact if still used or generated unnecessary costs related to
refurbishing, solution support, hosting, and licenses cost despite being outdated and overlooked.
11 capabilities were already available in global operations systems elsewhere. In those 11 cases, the staff had been trained to use the
legacy system years ago and were not aware of global deployments due to lack of training associated with the global deployments.
44 capabilities (almost all of them workarounds) were perceived as demonstrated best practices and were made globally available. Those
44 capabilities were incremental innovations that added additional benefits outside the original business case.
All interfaces were obsolete except for interfaces to three systems that used CDW as a data source. Strikingly, most interfaces sent data
to target systems that no longer existed. Unnecessary costs resulted from not documenting interfaces in interface agreements jointly
managed and updated by both the source and the target system service owner.
D. Joint Decision Making with Senior Users and other Stakeholders
A long-standing challenge in developing, maintaining, and improving information systems is the necessity of communicating effectively
with business professionals whose main attention and interests necessarily focuses on business and customer issues rather than IT
capabilities. One way of saying this is that business professionals tend to be less concerned with IT, and much more concerned with the IT-
6
Proceedings of CBI 2016 Industrial Track
reliant work systems that generate business results by producing or supporting products and services for customers. If they are more
concerned with those topics and if they are expected to participate fully in specifying user and customer needs, then much of the
communication and collaboration with them should be about those topics.
The Clean Sweep project addressed the issue of business/IT alignment through explicit use of work system ideas generally consistent
with work system theory (WST) and the work system method (WSM)4, which were designed to support business-oriented communication,
analysis, and design for IT-reliant work systems.
Figure 4 shows a variation on the original work system framework (part of WST) that was designed to make that framework more
directly useful in logistics situations. The original framework is based on the following definition of work system: a work system is a system
in which human participants and/or machines perform processes and activities using information, technology, and other resources to
produce product/services for internal or external customers. (Enterprises that grow beyond a largely improvised start-up phase can be
viewed as consisting of multiple work systems, e.g., work systems that procure materials from suppliers, produce products, deliver products,
find customers, and so on.) The work system framework identifies nine elements of even a basic understanding of a work system. The
variation in Figure 4 subdivides technologies into software assets and process technologies. It also changes product/services to products,
services & solutions. Those changes facilitated discussions of DHL Express logistics systems where, for example, it is often important to
remember to discuss both software assets and process technologies.
Figure 4: Logistics Work Systems (adapted and updated from Alter (2006, 2013))
Project 2 in the Clean Sweep program used Figure 4 as a tool for organizing discussions about specific capabilities in CDW. This
approach was especially helpful to the first author, who often started discussions with senior users by summarizing a work system that used
CDW and likely would be affected by the Clean Sweep project. Starting at the top, the diagram says that the purpose of the work system is
to produce products, services, and solutions for customers. Beyond simple delivery, those products, services, and solutions might include
insurance, Saturday delivery, customs services, packaging services duties and taxes paid, proactive tracking, delivery notification, and other
services that might be bundled in a variety of ways for specific customers. The business processes are the actions performed by DHL
employees (participants) using information, software assets, and process technologies that identify and move packages.
Once the analyst and senior user or other stakeholder agreed on exactly what work system was being discussed, it would be possible to
discuss how well that work system operates currently and to explain CDW’s role in supporting that work system. That mutual
understanding typically led to a discussion of how the refurbished infrastructure might support the same processes as effectively or more
effectively, and how current service levels for customers would be maintained or improved.
Within that discussion, users and other stakeholders were able to identify important strengths and shortcomings of CDW. That
discussion led to initial agreement about what could be expected from the replacement system. After the system development phase, senior
4
The ideas in WST and WSM have been discussed in many journal articles and conference presentations. The basic idea is to think of
systems in organizations as though they are work systems rather than software or IT systems. WST consists of the definition of work
system, the work system framework (nine elements of a basic understanding of a work system) and the work system life cycle model (a
model of how a work system changes over time through planned and unplanned change). WSM applies those ideas by outlining how to
summarize an existing work system, how to analyze it from a business viewpoint, and how to describe and justify improvements in the
work system. Those improvements might include software changes, process changes, changes related to work system participants, and
many other types of changes. A basic overview and many articles related to the work system approach are available through
www.stevenalter.com. Two of the most complete sources are:
1. Alter, S. (2006). The work system method: Connecting people, processes, and IT for business results. Larkspur, CA: Work System Press.
2. Alter, S. (2013). Work system theory: Overview of core concepts, extensions, and challenges for the future. Journal of the Association for
Information Systems, 14(2), 72-121.
7
Proceedings of CBI 2016 Industrial Track
users and other stakeholders revisited the earlier discussions to confirm that the new capabilities equaled or exceeded those provided by
CDW.
41 out of 44 CDW capabilities that were to be sustained were migrated to DHL’s global Operations Performance Management System
(OPMS), which was the predefined EGAP application for those IT capabilities. Consistent with DHL’s “one EGAP target only”
philosophy, an EGAP application was built to be the lead software asset for that IT capability.
OPMS measures, analyzes, controls and reports operational performance at various levels including global, region, country, and facility
It provides monitoring capabilities covering the entire shipment lifecycle from pickup to delivery. OPMS is composed of modules that
cover Pickup and Delivery, Hub & Gateways, Aviation, Network Efficiency, Capacity Management, Failure Pipeline Analysis, and ECom
integration, to name a few. It also provides the core transit time target calculations against which DHL’s service commitments to customers
are measured. This as well as several other incentivized key performance indicators derived from OPMS are used to populate global
scorecards and drive DHL’s overall service offering.
Table 3 illustrates the size of OPMS in terms of 2015 usage statistics.
OPMS 2015 usage statistics
Total active Users 7486
Reports run per month over 2,908,000
12 Teradata nodes + 6 Teradata nodes on
hot standby
192 CPU cores + 96 CPU cores on hot
standby
3,072 GB RAM + 1,536 GB RAM on hot
standby
OPMS 2013 infrastructure
180 * 400 GB SLC SSD Drives
1,872 + 300 GB HDD
Infiniband interconnect
2,004 TPerf total and 1,503 TPerf active
Table 3: Operational statistics for DHL's Operations Performance Management System (OPMS)
Based on the scope of OPMS, the local teams needed to be deeply involved end to end. Cross-functional involvement and commitment
from subject matter experts in all domains (especially Sales, Operations and Finance) was essential for understanding the functional
processes at the required level of detail. This was especially important for understanding interdependencies and business benefits. Because
complete participation by stakeholders was so important, the project’s communication plan included supporting material in the form of
mockups, wiki pages and presentations. Targets and timelines were proposed, discussed, and finally agreed with all stakeholders to help
everyone understand likely impacts of changes and to ensure that customers benefits were either sustained or improved.
E. Project 3: New system development
The third project was about implementing the capabilities that were to be retained in a globally available target application. All work system
components, not just the software, had to interact flawlessly prior deployment. Hence, the team conducted a technical acceptance test, a user
acceptance test and an operational acceptance test. No capability was switched off before the operation of the new system met specified test
criteria in a test environment during technical and user acceptance testing and in real life for four weeks during operational acceptance
testing.
The project for developing new systems saw two changes in perception about the entire program. First, demonstrated best practices
became global standards and now were viewed as unleashing hidden value. Second, the program was viewed as more than a refurbishment
program. Rather, it was viewed as an innovation program that exploited legacy applications to innovate the network as a whole.
F. Project 4: Clean Up
The clean-up was fairly generic. Once the new systems were deployed and confirmed to deliver in day to day business in an Operations
Acceptance Test, the interfaces were migrated to new global standard tools to ensure data feeds for all consumer systems previously using
CDW. This was followed by the code removal, decommissioning of the hardware, and cancellation of the licenses involved.
The only significant challenge in the clean-up project turned out to be several previously unknown bugs in one of the EGAP targets.
CDW was terminated after the bugs were fixed.
8
Proceedings of CBI 2016 Industrial Track
G. Business and Technical Payoffs
This Enterprise Architecture project immediately eliminated 263 obsolete, outdated or rejected IT capabilities, found 11 that were already
part of global application platform EGAP, and migrated 44 to EGAP to create a corporate platform that was improved further to the latest
corporate standards. The program took three years and was performed with the help of two consulting firms, four external IT suppliers, and
Deutsche Post IT Services, the internal IT supplier. The program comprised 4 projects that were subdivided into 26 work orders to vendors
to provide new system development activities that enabled a full blown sunset of CDW’s shared hardware.
In addition to large reductions in costs, the benefits included faster times to market, significant complexity reductions, and far greater
ability to build new applications based on clear documentation that conformed to enterprise standards globally. With much information
available in near real time, users also reported significant improvements in supporting their customers and their own operational
management and planning activities.
Many of the specific improvements recognized both by customers and internal DHL staff were less about earthshaking concepts and
innovations and more about providing previously defined information in the right form and at right time. The shift to the new architecture
made it possible to provide information that that customer and many others found extremely useful in monitoring and managing their own
supply chains.
The new Enterprise Architecture also helped with some of the rare cases of resistance that occurred when country users initially believed
that aspects of the architecture would not support work practices and reports that they viewed as necessary to run the business. The clarity of
the enterprise architecture helped in the process of recognizing important issues that the users highlighted and in ensuring that customer
interests were at the heart of many improvements. In particular, country users were invited to make a case for any capability in use they
wanted to retain.
Finally, Senior Users, Enterprise Architects, DHL Express’ Global Controlling, European Service Management department and all
vendors confirmed that important benefits were attained beyond the reduction of hardware and software costs, faster times to market, and
significantly reduced complexity. The joint review of capabilities in use was perceived as especially beneficial and was the main driver for
convergence.
Operating a network with only one dedicated (global) system for each purpose has begun to generate many benefits. In particular, it will
prevent having to implement innovations in several software assets before they are operational. It also avoids the unnecessary effort and cost
of doing two jobs when one is sufficient.
The clean sweep also allows DHL to avoid costs and disruptions due to using old and poorly documented legacy systems that were more
failure prone than new systems and harder to fix. An important outcome of the entire effort is in eliminating failure risks related to using
outdated legacy systems that support non-standard processes.
After the clean sweep the system landscape was clear of:
1. strategic legacy issues (i.e. related to deliberately abandoned business processes),
2. financial legacy issues (i.e. costs that are excessive in relation to profit contribution),
3. operational legacy issues (i.e. extraneous factors that no longer need to be considered for planned evolution related to changes in a work
system’s environment or infrastructure) or
4. technical legacy issues (i.e. no further need to support systems that have reached End of Life or End of Service).
Substantial benefits were harvested by triggering a critical review of how systems performing the work actually operated and how they
should operate. All IT capabilities that were retained from CDW were justified by users demonstrating how they added value. That hidden
value often seemed just as important as eliminating strategic, financial, and operational legacy issues related to the End of Life status of all
vendor products that supported the CDW infrastructure.
4 Lessons Learned
DHL’s experience with the CDW Clean Sweep led to a number of lessons learned that we believe are significant.
A. End of Service scenarios can trigger planned innovation cycles
The time when existing software assets and process technology transition from End of Life to End of Service is a time for investment. At
minimum, End of Service scenarios pave the way for much better housekeeping in the sense of eliminating capabilities that are no longer
adding value and along with the related costs. Since something needs to change, this is the time to seize the opportunity and innovate.
Within that process, demonstrated best practices should be made standard to help unleash hidden value.
B. The Clean Sweep approach is an effective way to tackle End of Life issues for infrastructure technologies
Clean Sweep projects are Enterprise Architecture-driven programs designed to enable:
9
Proceedings of CBI 2016 Industrial Track
1. baselining of a status quo,
2. defining and aligning a desired end-state of an evolution cycle for technology in use,
3. addressing strategic opportunities or threats and
4. transitioning (i.e. future proofing) toward an architecture that serves business needs more efficiently and effectively.
Based on those goals, Clean Sweep projects in large and mature organizations necessarily are cross-functional team efforts.
It is important to note that infrastructure refurbishment is not a green field project. Based on the assumption that old legacy systems
almost always have incomplete documentation, nobody knows upfront what capabilities will be discovered in the Legacy Assessment and
which of them should be retained. It is important to know the status quo to see what is working and what isn’t working. Thus, it is
impossible to plan the entire effort in detail prior to an initial overview of the current situation. This is why DHL separated the Clean Sweep
program into four separate projects that were budgeted separately based on results of the previous projects.
It is also important to have strategic goals. The end-state of an evolution cycle and all associated criteria to measure that state need to be
predefined, discussed, and agreed upon. Here the limiting factors found in the Legacy Assessment come into play, such as infrastructure that
is reaching End of Service and workarounds that need to be retained. As part of a business strategy, a legacy strategy for End of Service
work system components needs to address the threat of failure of technical legacies and ideally should exploit appropriate workarounds as
opportunities.
In relation to this project’s strategic goals, Clean Sweep CDW was designed to complement the ongoing releases of the EGAP landscape
that are part of a DHL Express “Focus” strategy. In turn, that strategy is the DHL Express part of the Deutsch Post DHL group strategy
called “Strategy 2020: Focus.Connect.Grow”.
C. Vendors dictate the necessity and timing of Clean Sweep activities
Vendors such as Microsoft usually publish End of Life and End of Service dates for their products (cf. Table below). It is time to trigger a
Clean Sweep when the End of Life date arrives.
Operating systems End of Life End of Service
Windows XP April 14, 2009 April 8, 2014
Windows Vista April 10, 2012 April 11, 2017
Windows 7 January 13, 2015 January 14, 2020
Windows 8 January 9, 2018 January 10, 2023
Windows 10 October 13, 2020 October 14, 2025
Table 4: Windows End of Support due dates5
End of Life due dates force an organization to act. This trigger is a superb reason to revisit the way an organization operates. In an
organization of DHL’s size and complexity, the revisit, the development activities, the deployment, and follow up enhancement to address
customer needs could absorb a year each, implying that the relevant business case analysis could cover five to six years. This type of project
is called for because something will have to be done about IT systems reaching the End of Life stage. Since costs associated with
maintenance and vendor support are inevitable, it makes sense to use the related efforts as a way to innovate and not just maintain the status
quo.
D. Senior Users and executives need to collaborate fully in evaluating existing capabilities and deciding how to exploit them to
innovate to better capabilities
The clean sweep was necessary because of technology End of Life issues, but it was pursued as Enterprise Architecture project, with Senior
Users and senior management participating fully. This stance was perceived as inevitable due to the strategic implications whenever parts of
systems performing the work start coming close to End of Service. The approach of scrutinizing every capability in use was chosen because
sun setting a capability may cause data losses or other malfunctions that can impact operational activities and ultimately the customer. The
ultimate decision makers were the Senior Users who served as the business owner and the interface to the customer.
5
Cf. http://windows.microsoft.com/en-us/windows/lifecycle
10
Proceedings of CBI 2016 Industrial Track
E. Oversized systems are a costly burden
IT assets such as data warehouses may be oversized in terms of providing unnecessary IT capabilities that are never used or that become
obsolete or outdated over time. Those outdated or obsolete IT capabilities sometimes are not removed from service in typical maintenance
activities. The result is unnecessary expenditures for supporting, hosting, and licensing unproductive assets. That budget could be devoted to
much more productive purposes.
In addition, poor housekeeping of this type creates a portfolio of strategic, financial, operational and technical legacy issues from which it
is difficult to escape. DHL Express Europe chose to tackle those issues using its rigorous clean sweep approach.
F. Software assets enabling opinion forming and decision making should be customized to specific business needs
Software assets like CDW operate at two levels: operational or strategic. At an operational level they support opinion forming and decision
making about work system execution (e.g., operation of business processes and activities to fix errors that occur). The 44 unique
workarounds were all at that operational level. The CDW workarounds were either perceived as best practices to be exploited as global
standards in the future or were required contractually or legally. An important lesson is that institutionalized workarounds are very likely
indicators of unanticipated best practices that may be a source for hidden value.
Software assets addressing strategic issues support gathering and processing distributed and non-homogeneous operational data and
combining it with business, market and competitor data. This provides decision makers with mission critical knowledge about status,
opportunities and threats. There was a high consensus among stakeholders that solutions for that type of need were unavailable off-the-shelf
and had to be built for a business.
G. An “Operational Acceptance Phase” can help to manage resistance when moving from old to new
Resistance to accepting new software assets is common when users lose a software asset they have used for a long time and feel
comfortable with.
Fear of losing control or a job, a competency, or a routine that has been used for years is quite understandable. To address any resistance
from the local teams, we had to show understanding and empathy with their needs and had to communicate how the global solution would
either match or improve the existing capabilities related to local needs and processes. This was managed by the Senior Users (all were senior
business representatives and not IT managers) and the Project Sponsor.
In addition we introduced a third test to prove fitness for use. The “standard” User Acceptance (users sign off that everything is working as
specified) and the Technical Acceptance Test demonstrates readiness for deployment (in our case performance testing, stress tests,
installation test and de-installation test and the like) in the test environment. Once deployed, the “Operational Acceptance Phase” was used
to demonstrate usability in everyday life while the legacy system was still available as a fallback. This sign off triggered the Clean-up phase
highlighted above. We pulled the plug only after users signed off that the new capabilities would deliver in real life.
This approach gave users the confidence that the software asset in use would not be switched off until the new software asset delivered as
well or even better than what they had previously. In most cases, users saw that they would receive better capabilities than were available
previously.
5 Concluding comments
All Clean Sweep programs conducted within Deutsche Post DHL group delivered the pre-defined benefits or exceeded them by seizing
opportunities that paid off, despite being very large multi-year programs comprising more than ten delivery projects. While the projects
differed, all were necessary for the same reason, the announced End of Life and End of Service dates for essential infrastructure.
A key reason for the success of the overall effort is that the projects were viewed as (strategic) business opportunities for innovation and
not just as technical projects even though the impetus came from technology issues. The results from the Clean Sweep projects illustrate that
End of Service can be viewed as a powerful cyclic trigger for both housekeeping and innovation.
Each Clean Sweep was run by Enterprise Architects translating a business vision into work system configurations that realized the
vision. IT personnel did much of the analysis of technology, but Senior Users from each relevant business function had to justify every
capability that would go into the new systems.
11