1. Chapter 3: Identifying the First Digital Twin
In Chapter 2, Planning Your Digital Twin, we discussed the key criteria for Digital
Twins in enterprises and their expected business outcomes. We looked at this from
the perspective of different industry sectors and their ecosystems. We analyzed the
prerequisites for Digital Twins, including the organizational and cultural factors.
Finally, we went over the technology requirements for Digital Twins.
In this chapter, we will discuss the evaluation process for a Digital Twin in the
context of a wide range of companies. This will provide you with wide exposure to
the relevance of Digital Twins both for internal and external opportunities. We will
tie this to the actual roles and responsibilities being created and advertised by
companies today. We will cover these topics:
Evaluating Digital Twin candidates
Roles and responsibilities
Experimentation and interactions
The finalist
In a nutshell, this chapter will cover the process of arriving at the first Digital Twin
to build, in alignment with the nature of the business and achievable outcomes.
This makes the identification and evaluation of the first Digital Twin crucial. This
process will be covered comprehensively here.
Evaluating Digital Twin candidates
In this section, we will identify the prospects for industrial Digital Twins and then
evaluate the one we want to move forward with. This evaluation has to be done in
the context of your company or initiative, to be relevant to you. We will do the
evaluation for multiple scenarios here and that should help for a wide range of
cases.
Here are a few settings where a Digital Twin may be evaluated:
An industrial conglomerate
A large enterprise in a single industry sector
A public sector entity
2. A large software company or public cloud provider
An Independent Software Vendor (ISV)
A large System Integrator (SI) or management consulting firm
A small/niche service
company Let's now look at each of these
scenarios.
Industrial conglomerates
Companies that would fit in this category are General Electric (GE), Siemens, ABB,
Hitachi, Honeywell, Johnson Controls, Schneider Electric, Bosch, and Emerson
Electric. Such industrial global companies have in recent years created a
digital competency center within their company, with the goal of accelerating the
industrial digital transformation. Some examples are GE Digital and Honeywell
Connected Enterprise. We will look at both scenarios where the digital
organization is evaluating the Digital Twin candidate or the Line of
Business (LOB). Let's look at the digital organization first.
Digital twin at digital competency
The digital competency is usually a horizontal LOB with the goal of servicing
different LOBs as well as, in some cases, external customers directly, with the goal
of developing new markets or new digital revenue streams. When the digital group
evaluates the candidates for a Digital Twin, it will look at considerations such as
the following:
Which LOB has identified one or more business use cases for the Digital
Twin?
Is the Digital Twin going to drive internal efficiency in the LOB or is it
going to be adopted by its customers?
Is the LOB willing to commit its Subject Matter Experts (SMEs) to work
with the digital group?
Will the Digital Twin framework be reusable for another LOB?
What is the current status of the data from the physical asset, such as
availability and ownership of the data?
What is the current status of the physics- or math-based models and do
these need to be developed from scratch for the Digital Twin of the
physical asset or the process?
3. Now that we have listed the key considerations for the Digital Twin, we are ready
to identify the candidates. Let's take a scenario where the digital group is working
with an aviation and power generation business. The aviation business builds jet
engines for aircraft and provides services to airline customers. The power business
builds generators that are used by electric utility companies. The utility company
also buys long-term service contracts from the manufacturer. Based on these, the
digital group is evaluating three candidates for its first Digital Twin. These are the
following:
Work with the aviation LOB to build the Digital Twin of the engine, E, that
it manufactures.
Work with the power LOB to build the Digital Twin of the gas generator,
G, that it manufactures.
Build a generic Digital Twin of a generator that is agnostic of the
manufacturer. Since there are only a few engine providers for
commercial aircraft, a generic jet engine model will not be very useful.
Now, let's compare each of the three scenarios in the following table:
The preceding table shows how the digital group may list the objective criteria to
help decide the pecking order for the Digital Twin identification for the starting
point. The table shows that the twin of the engine, E, and gas generator, G, would
primarily be internal use cases driven by the LOB. The investments can be justified
by productivity gains obtained by the business by the use of the twins. However,
when the use case for the twin involves only external customers, it may require a
higher initial investment.
In the next section, let's look at similar scenarios from the viewpoint of the LOB.
4. Digital twin at the LOB
The LOB of an industrial conglomerate may look at the same scenario through
their own lens before deciding to invest in the Digital Twin initiative. In this case,
the LOB may look at three different criteria:
The LOB's own readiness for the Digital Twin initiative, whether is it
complementary to its own business strategy or could be a possible
distraction
The ability to quantify productivity or efficiency delivered by the twin
Technology direction
The LOB would look at its current business strategy and then see where the Digital
Twin would be a good fit. For instance, aviation and power generation businesses
would normally sell the physical asset once and then sell long-term services to their
customers. In such cases, the LOB would invest in the Digital Twin, to help improve
the predictive maintenance services. Since these contracts are long-term, the top-
line revenue is not likely to change due to the introduction of the use of a Digital
Twin for predictive maintenance. However, the delivery of the services and margin
on them could be substantially improved by the use of a Digital Twin. Hence, it will
go well with the business strategy for the LOB. A similar case study of the Digital
Twin of an aircraft's landing gear is available
here: https://www.ge.com/digital/customers/predictive-insights-aid-aircraft-
landing-gear-performance. This prototype of the Digital Twin was built by GE and
Infosys and one of the authors of this book (Nath) was involved in it.
While we see that qualitatively speaking, the investment in the Digital Twin makes
sense for the aviation LOB, it may further have to build the business case
quantitatively. In order to do so, the LOB would have to estimate with sufficient
confidence the improvement in the service contract margins due to proper use of
the Digital Twin versus additional investments. This business case has to make
sense in the long term, but should be measurable in the short to mid-term as well,
to ensure they are moving in the right direction.
Finally, the LOB has to look at the technology considerations. This may include the
software platform as well as the infrastructure for data and connectivity of the
physical asset. The LOB would have to work with the asset owner or operator to
obtain the data for the purposes of the Digital Twin. If the LOB decides to work
with the digital group, or its conglomerate, then they need to make sure the digital
platform can handle the data and modeling needs of their asset. For instance, while
5. the gas generators, as shown in Figure 3.1, work in a fixed location, such as in a
power plant, it is easy to connect them to a high-speed network for data collection,
as long as the utility customer is on board with that:
Figure 3.1 – Gas generator
NOTE
Image source: http://commons.wikimedia.org/wiki/File:Turboprop_T-53.jpg
Power plants such as the one shown in Figure 3.2 house the gas generators. Often,
the utility company buys a long-term service contract from the manufacturer,
to transfer the risk of maintenance and downtime to them. In turn, the utility
company would often agree to allow the collection and sharing of the data from
the generator and its operation with the manufacturer, for the perceived value of
better services and lower downtime:
6. Figure 3.2 – Electric power plant
NOTE
Image source: https://commons.wikimedia.org/wiki/File:Turboprop_T-53.jpg
Aircraft are typically only connected with very low-bandwidth satellite
connections that are used for critical data transmission only. As a result, the
collection of detailed data from jet engines would need an offline mechanism to
collect massive amounts of data from the prior flight(s). The LOB would have to
make sure that the digital group can provide the digital platform to facilitate such
data collection for the Digital Twin of the engine, E, such as the one shown in Figure
3.3:
7. Figure 3.3 – Rolls-Royce aircraft engine and landing gear
NOTE
Image source: https://www.aeronef.net/2011/12/boeing-777-300-with-rolls-royces-
jet.html
Here, we looked at the key considerations in industrial conglomerate companies
about the adoption and investment of a Digital Twin. We looked at the decision
process for the central digital group as well as from the viewpoint of the LOBs.
Large enterprises in a single industry sector
Continuing the theme of aviation and power, let's look at some large enterprises
that primarily operate in a single industry. Some examples of such companies are
Boeing and Airbus, which are the two largest aircraft manufacturers, as well as
8. Exelon, which is a large energy company. Such companies would be comparable
to our LOB assessment in a conglomerate.
Let's take the example of Boeing or Airbus. They manufacture aircraft that are
primarily sold to airlines or, in some cases, to the defense sector. However, the
definition of "airlines" has changed over time and companies such as FedEx, UPS,
DHL, and Amazon operate like an "airline" as well. FedEx, UPS, and DHL each have
over 250 aircraft. According to an article from September 2018
(see https://www.aviationtoday.com/2018/09/14/boeing-ceo-talks-digital-twin-
era- aviation/), the CEO of Boeing claimed that they were able to improve their
first- time quality of the sub-systems and parts of aircraft by 40% by leveraging
Digital Twin asset development models.
The aircraft manufacturers will have to evaluate how they will monetize the
Digital Twin before making investment decisions. They would likely consider the
following:
Improvement of the product quality during manufacturing by using a
Digital Twin for simulations and as part of the digital thread
Improvement in the Maintenance, Repair, and Overhaul (MRO)
services provided to the commercial airlines and cargo handlers while
considering the relationships with large parts providers such as GE, Rolls-
Royce, and Honeywell
Digital twin-based offerings sold as new revenues including to defense
customers (see
https://www.machinedesign.com/automation-
iiot/article/21139448/full-throttle-digital-twins-boost-airworthiness-in-
legacy-airplanes)
Such considerations will help decide which type of Digital Twin to prioritize in the
aviation industry. Dassault Systèmes, which is a company with about 20,000
employees, has built Digital Twin capabilities as well
(see https://www.3ds.com/3dexperience/cloud/digital-transformation/digital-
twin- technology). It had a big presence in the aviation industry but is not limited
to that industry.
Energy sector companies such as Exelon operate in power generation,
transmission, and distribution. Power generation would be from renewable and
non-renewable sources. A company such as Exelon would typically purchase the
majority of its equipment (including generators) from other manufacturers. As a
result, they would have to decide whether to go to the manufacturer to obtain the
9. Digital Twin of their equipment such as GE's power generator or to build a generic
model that can be used across different manufacturers' generation equipment.
Likewise, Exelon would have to look at internally prioritizing whether generation
efficiency is more important than reducing any outages caused by the transmission
and distribution capabilities. Exelon could focus on working with Siemens and
Bentley Systems for their digital services for brownfield transmission and
distribution (see
https://www.bentley.com/en/about- us/news/2019/october/22/bentley-systems-
introduces-assetwise-digital-twin- services). In this case, Exelon would adopt and
build upon the OpenUtilities Digital Twin services for asset and network
performance for its own use.
If renewable power generation is a priority for Exelon, they may start with the
Digital Twin of a wind turbine or the wind farm as a whole. Often, wind farms are
in the middle of a desert or on top of a mountain and connectivity is a key
consideration. The alternative can be the deployment of the Digital Twin of the
asset and the fleet at the wind farm level.
Finally, let's look at a large medical device manufacturing company for the use of a
Digital Twin. In 2020, due to the pandemic (Covid-19), there has been a renewed
focus on medical devices and life sciences companies. Some large medical device
companies include Medtronic, Thermofisher, Johnson & Johnson (J&J), and
Abbott. Medtronic makes medical devices such as pacemakers, and while the
Digital Twin for a complex device such as a pacemaker would seem like a good
starting point, Medtronic has talked about the Digital Twin of its supply chain in
2020 (see
https://www.forbes.com/sites/stevebanker/2020/06/19/medtronics- digital-twin-
supports-their-ability-to-respond-in-the- pandemic/?sh=d4819b6857ee). The Digital
Twin of the supply chain helps to make the operations and decision processes
more agile, which is definitely needed in 2020, as part of industrial digital
transformation.
Public sector
The public sector is usually not driven by profitability or competitive advantage,
but rather by the focus on citizen experience. As a result, leaders in the public
sector may look at the use of Digital Twins to improve the public health, safety, and
convenience of their constituencies. In the context of public health, the concept of
a human Digital Twin is gaining popularity. "Over time, my medical record could be
a Digital Twin of me" (see https://www.challenge.org/insights/the-next-era-
of-
10. public-sector-digital-transformation/). This is a concept different from the Digital
Twin of an industrial physical asset, but here the human being is the "asset."
Digital twins of cities have been considered in Europe
(see https://www.digitalurbantwins.com/post/why-the-public-sector-should-look-
to-digital-twins-for-better-policy-making). Such twins of cities can be used for the
analysis of public policy changes, traffic analysis, and air quality analysis.
The China Academy of Information and Communications Technology (CAICT)
has also done some work on the architecture for Digital Twins of cities.
The public sector may have to prioritize its Digital Twin-related initiatives based
on funding and grants from higher levels of governmental bodies, as well as other
non-technical considerations. However, it does not limit cities and counties from
seeking public-private partnerships and being creative in the initial stages to pilot
the Digital Twin.
Federal and defense agencies such as the US Navy are also exploring the use of
Digital Twins, such as for naval ships (see https://federalnewsnetwork.com/federal-
insights/2020/05/navy-using-digital-twins-to-speed-innovation-to-the-fleet/):
Figure 3.4 – Digital twin of a navy ship
11. We looked at a few examples of the use of Digital Twins in the public sector. Next,
let's look at software and public cloud providers and their adoption of Digital Twins
and related capabilities.
Software and public cloud providers
We will cover two main categories of software providers here. These are the
following:
Business application software providers such as Oracle, SAP, and
Saleforce.com
Public cloud providers such as Amazon – AWS, Microsoft – Azure, Google
– GCP, Oracle – OCI, IBM, and Alibaba
Business applications providers such as Oracle and SAP have a large customer base
of enterprises who use Enterprise Resource Planning (ERP), Human Capital
Management (HCM), Customer Relationship Management (CRM), and related
software. These enterprises often look to their business application providers for
emerging technology solutions as well. So, when they are considering a Digital
Twin, they may often look at these providers to see whether they have Digital Twin
offerings and how well these are integrated into their current business application
offerings. As a result, companies such as Oracle and SAP have invested
in the Internet of Things (IoT) platforms and built capabilities for a Digital Twin
around that. Companies such as Oracle and SAP are less likely to use a Digital Twin
for their internal use; they are mainly concerned about providing a framework to
allow their customers to build an industrial Digital Twin. They may provide a
sample of Digital Twins, to help accelerate the customer's own journey. Such
business software companies may provide use cases for integration of the Digital
Twin with enterprise software such as ERP with a focus on manufacturing
and Supply Chain Management (SCM) modules.
NOTE
SAP has talked about its customers Kaeser Kompressoren and Netzsch using a
Digital Twin here: https://www.sap.com/products/supply-chain-management/digital-
twin.html.
Now, let's look at public cloud providers. You would have noticed that Oracle
appears in both categories – namely business applications and public cloud
12. providers. Public cloud providers have focused on cloud infrastructure,
namely Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and in
some cases Software as a Service (SaaS). Most large enterprises run their
software systems on the public cloud, to a varying degree. As a result, these
enterprises often look at the available IoT and digital capabilities in the public
cloud of their choice. They try to minimize the number of cloud providers for their
IT and Operation Technology (OT) solutions. As a result, public cloud providers
have started to add IoT and Digital Twin capabilities to their public cloud
platforms. Microsoft Azure Digital Twins and the Oracle Digital Twin framework
are such examples. The public cloud providers are again focused on providing the
tools and capabilities to their customers for building Digital Twins and are not the
primary consumers of Digital Twins for their own operations. The public cloud
providers may, however, provide a security framework as data flows from the edge to
the cloud.
ISVs
ISVs include companies such as AspenTech, AVEVA, and Bentley. However,
Schneider Electric acquired AVEVA in 2018. Companies in this category would
work with other larger software providers, whether it is a public cloud provider or
a similar company, to provide a Digital Twin solution to the end user or operating
companies. Earlier in this chapter, we read that Bentley was working with SAP to
provide a Digital Twin solution for Exelon. Likewise, AspenTech is working with
their partner Equinox, helping to implement a Digital Twin for Abu Dhabi
National Oil Company (ADNOC), for the Shah gas plant
(see https://www.aspentech.com/en/blog/blog/GLOBal_Threads_of_Sustainability_
From_Digital_Transformation).
We can see that ISVs maintain a symbiotic relationship with other software and
service providers to bring Digital Twin offerings to operating enterprises. ISVs tend
to build reusable software offerings around the Digital Twin and usually try to stay
focused on a narrow range of industries. They often rely on the first few pilot
customers to help enrich their offering.
SIs
SIs and management consulting companies such as Accenture, Deloitte, Tata
Consultancy Services (TCS), Infosys, and Capgemini focus on consulting
13. services around strategy and implementation, for industry 4.0-related solutions.
Typically, their customer bases are large enterprises. Generally, SIs do not build
any reusable software products and instead partner with the technology provider
of the IoT platform and Digital Twin systems. They may, however, decide to invest in
the education and training of their consulting workforce, as well as building
prototypes of the Digital Twin, to help evangelize their services. The Digital Twin
of an aircraft's landing gear was built by Infosys with the help of GE. In this case,
Infosys was the SI partner to GE, who provided the domain knowledge and
the Industrial IoT (IIoT) platform.
Niche companies
As Digital Twins are still an emerging technology, many specialized and niche
providers are in this space. To name a few companies, we have C3.ai, Uptake, and
XMPro (see https://xmpro.com/digital-twins-the-ultimate-guide/). We
will increasingly see specialized offerings from such niche providers, often via
the marketplace of public cloud providers, such as the following:
iGeneration – Digital Twin on
Azure (see https://azuremarketplace.microsoft.com/en-
us/marketplace/apps/adfolks.igenerations-implement?tab=Overview)
Asset Performance Management – L&T Technology
Services
(see https://azuremarketplace.microsoft.com/en-
us/marketplace/apps/ltts.rapm_asset_performance_management?tab=ov
erview)
These are primarily offerings for use by operating companies in their Digital Twin
journey. We will increasingly see start-ups entering this space, to build a new
business around Digital Twin technology. Different kinds of Digital Twins have a
prominent place in Gartner's Hype Curve of Emerging Technology, 2020.
In this section, we looked at different ways to evaluate the value of Digital Twins
in different business settings. Now, let's look at the people and roles that are often
responsible for the Digital Twin in different organizations.
Roles and responsibilities
14. In this section, we will identify the different personas and roles that would be part
of the Digital Twin initiatives. One of the standard ways to represent roles and
responsibilities is with a RACI matrix. The origin of the acronym RACI is from the
four major responsibilities:
Responsible
Accountable
Consulted
Informed
The level of ownership decreases down the list, as shown in Figure 3.5:
Figure 3.5 – Description of the RACI matrix
Let's construct a sample RACI matrix for the industrial conglomerate example:
15. This sample RACI matrix provides pointers to roles that will be part of the Digital
Twin initiative according to the specific situation in the company. Often, once the
business leaders decide to transition from selling products to bundles of products
and services, they will start focusing on the Digital Twin as an enabler. This stage
is often called the servitization of the product. The CEO and board of the company
may set the direction of the company for servitization or may delegate it to a role
such as the Chief Digital Officer (CDO). In some organizations, instead of the CDO,
a Chief Technology Officer (CTO) role may take the lead to work with the LOB
leaders on ideation of the Digital Twin. According to a recent Wall Street
Journal article, the Digital Twin market was worth $3.8 billion in 2019, and is
expected to reach $35.8 billion by the year 2025
(see https://deloitte.wsj.com/cio/2020/06/23/digital-twins-bridging-the-physical-
and-digital).
Usually, technology initiatives are driven by CIOs; however, in our experience,
Digital Twin initiatives are primarily led by other technologist roles in large
enterprises, who work closely with the LOB leaders. The CIO's team would typically
get involved when the technology, platform, and infrastructure decisions are being
made. In an interesting article about the possible role of CIOs in the Digital Twin
landscape, the concept of Engineering Technology (ET) has been introduced
(see https://thansyn.com/why-cios-must-better-engage-with-engineering-
technologists-to-leverage-digital-twins/). The following table summarizes the
information from the article:
16. While the concept of the Digital Twin has now been around for almost two decades,
mainstream adoption is still an emerging area. It is an important question as to
whether innovation and reinvention can be done by professionals who have been
working for a long time in that area or by those who have come from different
fields. Professionals working for decades in the same field understand the area
very well and have built products and solutions that work a certain way today.
Sometimes asking them to reinvent and think in different ways is a very difficult
proposition. Let's take an example of an aircraft on the runway during landing. A
commercial aircraft with two or four jet engines only needs one engine for the
purpose of taxiing, whereas most pilots in different airlines do not switch off the
other engines right after landing, as that is how it has been done for years.
17. The Federal Aviation Administration (FAA) handbook does not address that
(see https://www.faa.gov/regulations_policies/handbooks_manuals/aviation/airpla
ne_handbook/media/10_afh_ch8.pdf). However, the airline Air Asia was able to
save about 9 liters of fuel per flight by adopting this process
(see https://climatechange-theneweconomy.com/aviation-airasia). This reduced
the CO2 footprint by 28 kilograms per flight. In this case, GE had provided this
innovative, fuel-saving tip to Air Asia.
The preceding example shows that when we look at the roles and responsibilities
for any Digital Twin initiative, it is important to form a team that consists of
insiders and outsiders. Outsider could simply mean individuals who are not from
the same domain and does not necessarily mean those who are from outside the
company.
We did a brief survey of job descriptions where Digital Twin-related skills were
explicitly mentioned. In the table below are a few examples as of December 2020:
19. The preceding jobs span large and medium companies from the public to the
private sector as well as consulting services companies such as IBM. Thus, different
companies are addressing their roles and responsibilities related to Digital Twins,
by both hiring for such skills as well as internally grooming them. This is good news
for those of you who may want to explore new directions in your career. It is
important to know that sometimes Digital Twin-related offerings may cannibalize
existing business and services and it is important to be cognizant of this and plan
for disruption around it.
20. In the next section, let's look at the methodologies that can be used to ideate,
develop, and validate the ideas around the Digital Twin, with the goal to accelerate
the decision cycle and the time to market.
Experimentation and interactions
Emerging technologies often require a lot of experimentation and the ability to
learn from previous iterations. Figure 3.6 shows the process of rapid
experimentation and iterations, leading to a smaller set of success stories:
Figure 3.6 – Rapid exploration and discovery of the Digital Twin candidate
Agile Manifesto
The Agile Manifesto refers to a document that explains the values and principles
of Agile software development. It is visually shown in Figure 3.7 and was first
published in 2001. These values and principles are described
here: https://www.visual-paradigm.com/scrum/agile-manifesto-and-agile-
principles/. The Agile methodology provides an alternative to the traditional heavy-
weight waterfall method of developing software. The Agile methodology fits the
rapid experimentation that Digital Twin initiatives often need. The use of the Agile
methodology in the context of Digital Twins, by Siemens and Accenture, is
described here: https://blogs.sw.siemens.com/thought-
leadership/2018/01/26/using-agile-processes-and-digital-twin-technology. We
21. suggest you view the video shared on this Siemens blog page, from the Digital Twin
Summit (see https://youtu.be/ETTlTq88oHU).
Figure 3.7 – Agile Manifesto
Figure 3.7 summarizes the spirit of the Agile methodology where smaller iterations
lead to bigger outcomes while reducing the risks. The development work is often
divided into the following:
Releases
Epics
Stories
Sprints
Daily standups
Test cases
Demo and user acceptances
Iterations (pivot or persevere)
Another way to look at the Agile methodology at work is visually shown in Figure
3.8, in their natural order:
22. Figure 3.8 – Scrum methodology
The product backlog is defined in terms of releases, epics, and stories. The stories
and epics are worked on during the Sprints, which can often be as short as 1-2
weeks. The Sprints involve their own planning so that stories are mapped to the
Sprint Backlog. Once the developer completes the assigned tasks measured in story
points, their work is reviewed or may be demoed to the business users. This leads
to the wrapup of the Sprint and iteratively working on the product backlog.
As we further explain this terminology, let's use a realistic example. Western
Digital Corporation (WDC) described their 12-week-long Digital Twin
experimentation here: https://blog.westerndigital.com/digital-twins-optimize-
robot-manufacturing-ops/. They called it a rapid learning cycle with the goal to
create an Autonomous Robot Vehicle (ARV). Let's attempt to create the high-level
Scrum artifacts for this initiative.
Release
A release is defined as an application that can be distributed to business users or a
control group. This can be beta software or a pilot product or can be a generally
available version of the software product. In the WDC case, the release would
consist of some version of the ARV application, developed with the help of the
Digital Twin process. A release is usually defined in terms of features that are on
the product roadmap. These features may be described as epics.
Epic
An epic is a unit of work for development that logically groups related requests or
needs of the user community of the application. Epics help the team to estimate the
time and effort required for a logical grouping of work. Epics should be written in
a manner that the business users can easily understand and validate at the end of
the cycle. In the case of WDC, the epic can be stated as "the ARV pilot using the
23. Digital Twin." Epics are broken down into stories, which can then be estimated
more precisely and allocated to the members of the development team.
Story
The story, also referred to as the user story, is a description of the characteristics
of the software application from the different stakeholders' perspectives. Stories
are meant to be small units of work but tangible in nature. These stakeholders may
be the end users or IT folks who maintain the final solution or the business sponsor
of the project. A story should have these characteristics:
Articulate how the characteristics of the application are valuable to the
stakeholders.
Describe how these can be demonstrated, tested, and verified for
acceptance.
Focus on the "what" and not particularly on the "how." This allows the
technical team to figure out the best way to build the application.
Be easy to estimate the work effort required by the Scrum team, while
reducing the risk.
The best practice is to vertically slice the story. To take a simple analogy, a pizza
consists of layers of dough, pizza sauce, cheese, and toppings. If a story only
contains the dough, the user or the tester will only get to taste the dough by itself
and will not be able to provide good feedback on the "acceptance" of the final pizza.
On the other hand, by the principle of "vertical slice," if the story is to make a small
slice of pizza, then the user can provide a lot more meaningful feedback and the
risk to the acceptance of the final pizza will be much lower. While this "vertically
sliced story" is highly desired, it may not always be feasible.
To look at the possible stories for the WDC epic, here are some possible stories:
Twin of ARV movement in the second floor of the semiconductor
fabrication plant (fab) of Shanghai, China
History of the wait time and service time distribution for the Device
Under Test (DUT) at the fab
This can be the starting point with two stories for the WDC epic. The stories can be
finished in one or more Sprints. However, the goal is to be able to demo the
progress at the end of each Sprint to the stakeholders.
24. Sprints
A Sprint is a short interval of time, often 1-2 weeks. Sprints are used to complete
work such as the user stories. A release is often broken down into multiple Sprints.
In the WDC example, for instance, the 12-week exercise could be broken down into
6 sprints of 2 weeks each. As these sprints progress, the measurable units of work
are completed and tested according to the often-documented test cases.
Daily standups
A daily stand-up meeting is an Agile ritual used for tracking daily progress. It can
be held once or twice a day. When twice, it is at the beginning and then end of the
working day. Good communication is key to the success of Agile methodology and
the daily standups are the key part of synchronizing the whole team. Often, each
member may discuss these three items:
What work did you do yesterday or today (when the standup is at the end
of the day)?
What work will you do today or tomorrow?
Are there any blockers to your work?
When the whole or the majority of the team is working from a single office, the
team gathers around the information radiator or the Scrum board during the daily
standups. Figure 3.9 shows such an information radiator:
25. Figure 3.9 – Scrum information radiator
NOTE
Image source: http://agileconsulting.blogspot.com/2013/09/agile-transformation-
cadence-model_495.html
The use of the information radiator during the daily standups and in the area
where the Scrum teams work provides a high level of visibility to the overall
progress of the Sprints and the releases. In scenarios where the majority of the
team is not working under a single roof, electronic versions of such information
radiators and Scrum boards are used and the daily standup may take place via
video conferencing systems. Figure 3.10 shows one such electronic Scrum board:
26. Figure 3.10 – Electronic Scrum board for the Agile methodology
NOTE
Image source: http://phdesign.com.au/general/excel-templates-for-scrum-product-
and-sprint-backlogs/
While the daily standup has been described in a generic sense, here it will apply to
the WDC scenario as well.
Test cases
Test cases are the scenarios that are used to validate that Sprints are producing
work on the stories and epics in a manner that will meet the stakeholder
requirements. These test cases can be used by the Quality Assurance (QA) team of
the users to check and accept the work along the way. The set of conditions or
variables used to determine whether a system under test satisfies requirements is
created manually from specifications, which are later used to create tests used by
the QA team. In the WDC scenario, the test cases will help the stakeholders to
validate the progress toward the ARV pilot using the Digital Twin over the Sprints.
Demo and user acceptance
27. At the end of each Sprint, the whole team meets in a conference, wherever possible,
and the development team responsible for the story demonstrates progress to
the stakeholders. The use of vertically sliced stories helps to make these demos
tangible in nature to the business users. For instance, during the demo for the
story, the twin of ARV movement on the second floor of the semiconductor
fabrication plant (fab) of Shanghai, China, the team may show the 2D plot of the
movement of a single ARV, in one small part of the fab. This would be meaningful to
the business SME and they can provide the acceptance or rejection easily.
Iterations
The Agile development process is iterative in nature. As discussed previously, the
stakeholder may accept or reject the outcome of the Sprint, the story, or the whole
epic at the end of the cycle. Based on such feedback from the stakeholders, the team
decides to persevere or pivot as the next step. In the WDC scenario, the team
decided to persevere or take it forward for improvements. Their overall business
objective was to improve the overall service time at the fab. This in turn would
help WDC to improve the throughput and efficiency at the second floor of the fab.
Once achieved, this success can be replicated in the entire fab and then in the other
WDC locations.
More details about these artifacts and Agile rituals can be found
here: https://www.atlassian.com/agile/scrum/artifacts.
In this section, we learned about the value of experimentation and iterations, for
Digital Twin-related initiatives. The use of established software mythologies such
as the Agile Manifesto helps to adopt practices that are likely to provide
incremental value and reduce risks. While we used the example in the context of
a software application, a similar process can be applied for the convergence of the
physical and the digital world where the final solution involves hardware such as
sensors and an IoT gateway as well as the software pieces.
In the next section, we will look at ways to arrive at the finalist candidate for the
Digital Twin initiatives.
The finalist
28. After going through the evaluation process of the candidates for building the first
Digital Twin, we selected a wind turbine as the asset. Let's look at some of the
reasons for the choice of building the Digital Twin of a wind turbine:
Overall, there is increased focus on renewable sources of energy, to help
control the carbon footprint. A wind turbine uses air speed or the wind
as fuel for generating electricity.
A wind turbine is a relatively less complex physical asset compared to a
gas generator-powered power plant or a nuclear reactor. Hence, a wind
turbine is a better candidate for the first Digital Twin, to keep the
complexity lower.
The Digital Twin of the wind turbine would benefit both the
manufacturer/service provider of the turbine as well as the
owner/operator, which would often be the utility company. Additionally,
the SIs and cloud platform and business software providers will be
interested in providing the implementation and technology capabilities.
Given renewable energy is commercially feasible, driving efficiency via
the Digital Twin of the wind turbine and the wind farm would provide
immediate value to its stakeholders.
With the selected asset in mind, for building an industrial-grade Digital Twin, we
will look at the planning and prerequisites in the next chapter. In the remainder of
this book, we will build the first Digital Twin for the wind turbine, and evaluate it
both technically and economically to calculate the ROI. Finally, in Chapter 8,
Enhancing the Digital Twin, we will extend this to other assets for renewable energy
such as a hydroelectric power plant as well as a solar power plant, to provide wider
coverage, from a utility perspective, of who may own all such power generation
assets.
Summary
In this chapter, we looked at the evaluation process for Digital Twins, from the
perspective of different organizations and stakeholders. This provides a
framework to analyze the opportunities provided by the Digital Twin and make an
informed decision. We looked at the different roles and responsibilities in
enterprises around Digital Twin initiatives, including how these roles are being
fulfilled. We then looked at the process of experimentation and iterations
associated with the development of Digital Twins and related initiatives.
29. Questions
1. What are the different kinds of enterprises that may be interested in
digital twin initiatives?
2. Can you drive efficiency as well as new revenues by using Digital Twins?
3. Give one example of a Digital Twin related to aircraft.
4. What is the use of the RACI matrix in the context of Digital Twins?
5. What is the role of rapid experimentation in the adoption of Digital
Twins?
