![P
xviii
the Google Workspace software does not have to be installed on user computers,
because it is provided in the cloud using the Software as a Service (SaaS) model.
According to recent reports, Google owns nearly 60% of the online office suite mar-
ket, surpassing even the share claimed by Microsoft.
As you can see from these industry leaders’ experiences, your organization
doesn’t need to sell software to earn market-leading revenues. It will, however, need
to use software to excel in business both now and over the years to follow.
What is more, to innovate using software, an organization must recognize that a
contingent of software architects and engineers—the best—matter. They matter so
much that the demand for the best makes them ridiculously difficult to hire. Think
of the significance of landing any one of the top 20 picks in the WNBA or NFL draft.
Of course, this description does not apply to every software developer. Many or even
most are content to “punch a clock,” pay their mortgage, and watch as much of the
WNBA and NFL on TV as they possibly can. If those are the prospects you want to
recruit, we strongly suggest that you stop reading this book right now. Conversely, if
that’s where you’ve been but now you want to make a meaningful change, read on.
For those organizations seeking to excel and accelerate their pace of innovation,
it’s important to realize that software development achievers are more than just
“valuable.” If a business is to innovate by means of software to the extent of ruling
its industry, it must recognize that software architects and engineers of that ilk are
“The New Kingmakers,” a term coined by Stephen O’Grady in his 2013 book The
New Kingmakers: How Developers Conquered the World [New-Kingmakers]. To
truly succeed with software, all businesses with audacious goals must understand
what drives this ilk of developer to transcend common software creation. The kinds
of software that they yearn to create are in no way ordinary or obvious. The most
valuable software developers want to make the kind of software that determines
the future of the industry, and that’s the recruiting message your organization must
sound to attract (1) the best and (2) those who care enough to become the best.
This book is meant for C-level and other business executives, as well as every
role and level involved in leading software development roles. Everyone responsi-
ble for delivering software that either directly results in strategic differentiation, or
supports it, must understand how to drive innovation with software.
The authors have found that today’s C-level and other executives are a different
breed than their predecessors from decades past. Many are tech savvy and might
even be considered experts in their business domain. They have a vision for making
things better in a specific place, and they attract other executives and deeply techni-
cal professionals who grok what the founder or founders are driving to accomplish:
• CEOs who are close to the technology vision, such as startup CEOs, and
those who want to be informed about the role of software in their future](https://image.slidesharecdn.com/25074925-250521110043-6af38133/85/Strategic-Monoliths-And-Microservices-Driving-Innovation-Using-Purposeful-Architecture-Vaughn-Vernon-23-320.jpg)
![P
xx
a dollop of realism, demonstrating that innovation can be achieved by means of
progressive practical steps rather than requiring instantaneous gigantic leaps.
There is always risk in attempting innovation. That said, not taking any risk at
all will likely be even more risky and damaging in the long run. The following sim-
ple graph makes this point very clear.
Figure P.1 There is a risk in taking a risk, but likely even a greater risk in playing it safe.
As Natalie Fratto [Natalie-Fratto-Risk] suggests, it is generally the case that the
risk of taking risks diminishes over time, but the risk of playing it safe increases over
time. The venture investor side of Natalie can be seen in her TED Talk [Natalie-
Fratto-TED], which explains the kinds of founders in whose businesses she invests.
As she explains, many investors seek business founders with a high intelligence
quotient (IQ), whereas others look for entrepreneurs with a high emotional quo-
tient (EQ). She looks primarily for those with a high adaptability quotient (AQ). In
fact, innovation calls for a great amount of adaptability. You’ll find that message
repeated in this book in several forms. Everything from experimentation to discov-
ery to architecture, design, and implementation requires adaptability. Risk takers
are unlikely to succeed unless they are very adaptable.
As we discuss our primary topic of innovation with software, it’s impossible
to entirely avoid the highly controversial topic of iterative and incremental devel-
opment. Indeed, some form of the “A-word”—yes, agile/Agile—cannot be side-
stepped. This book stays far away from promoting a specific and ceremonial way
to use Agile or to be a lean business. Sadly, the authors have found that most com-
panies and teams creating software claim to use Agile, yet don’t understand how
to be agile. The desire is to emphasize the latter rather than reinforce the former.
The original message of agile is quite simple: It’s focused on collaborative delivery.
If kept simple, this approach can be highly useful. That said, this is nowhere near
our primary message. We attempt only to draw attention to where “un-simple” use](https://image.slidesharecdn.com/25074925-250521110043-6af38133/85/Strategic-Monoliths-And-Microservices-Driving-Innovation-Using-Purposeful-Architecture-Vaughn-Vernon-25-320.jpg)
![P xxiii
References
[Natalie-Fratto-Risk] https://twitter.com/NatalieFratto/status/
1413123064896921602
[Natalie-Fratto-TED] https://www.ted.com/talks/
natalie_fratto_3_ways_to_measure_your_adaptability_and_how_to_improve_it
[New-Kingmakers] https://www.amazon.com/
New-Kingmakers-Developers-Conquered-World-ebook/dp/B0097E4MEU
Register your copy of Strategic Monoliths and Microservices on the InformIT
site for convenient access to updates and/or corrections as they become avail-
able. To start the registration process, go to informit.com/register and log in or
create an account. Enter the product ISBN (9780137355464) and click Submit.
Look on the Registered Products tab for an Access Bonus Content link next to
this product, and follow that link to access any available bonus materials. If
you would like to be notified of exclusive offers on new editions and updates,
please check the box to receive email from us.](https://image.slidesharecdn.com/25074925-250521110043-6af38133/85/Strategic-Monoliths-And-Microservices-Driving-Innovation-Using-Purposeful-Architecture-Vaughn-Vernon-28-320.jpg)
![7
Chapter 1
Business Goals and Digital
Transformation
The most outstanding business achievement is to create a product that is needed
by a great number of consumers, is completely unique, and is optimally priced.
Historically, and in a general sense, the realization of such an accomplishment
has depended on the ability to identify what is essential or highly desirable for a
key market demographic. This is reflected in a maxim captured by the writings of
Plato: “Our need will be the real creator.” Today, this statement is better known as
“Necessity is the mother of invention.”
Yet, the most profound innovators are those who invent an ingenious product
even before consumers realize it is needed. Such achievements have occurred seren-
dipitously, but have also been born from those daring enough to ask, “Why not?”1
Perhaps mathematician and philosopher Alfred North Whitehead struck on this
notion when he argued that “the basis of invention is science, and science is almost
wholly the outgrowth of pleasurable intellectual curiosity” [ANW].
Of course, the vast majority of businesses face a stark reality: Breakthroughs in
product development that lead to far-reaching market impact aren’t an everyday
happening. Inventing entirely unique products that capture whole markets might
seem as likely as aiming at nothing and hitting the center of a pot of gold.
As a result, the predominant business plan is to create competition. The unique-
ness is seen in pricing the replica rather than in creating the original. Hitting such
a large target is entirely ordinary and lacking in imagination and is not even a sure
means of success. If creating (more) competition seems to be the best play, consider
Steve Jobs’s advice: “You can’t look at the competition and say you’re going to do it
better. You have to look at the competition and say you’re going to do it differently.”
1. (George) Bernard Shaw: “Some men see things as they are and ask why. Others dream things that
never were and ask why not.”](https://image.slidesharecdn.com/25074925-250521110043-6af38133/85/Strategic-Monoliths-And-Microservices-Driving-Innovation-Using-Purposeful-Architecture-Vaughn-Vernon-44-320.jpg)
![C 1 B G D T
8
SpaceX Innovation
Between the years 1970 and 2000, the cost to launch a kilogram to space aver-
aged $18,500 US per kilogram. For a SpaceX Falcon 9, the cost is just $2,720
per kilogram. That’s a factor of 7:1 improvement, and so it’s no secret why
SpaceX has almost all of the space launch business these days. How did they
do it? What they did not do was work under contract to the government—that
is, the only funding mechanism up until then. Their goal was to dramatically
reduce the cost to launch stuff into space. Their main sub-goal under that was
to recover and reuse booster rockets. There’s a wonderful YouTube video of
all the boosters they crashed in order to achieve their goal. The strategy of
integrating events (in this case, test booster launches) is how multiple engi-
neering teams rapidly try out their latest version with all the other teams.
Government contracts would never have tolerated the crashes that SpaceX
suffered. Yet, the crashes speeded up the development of a reliable, cheap
booster rocket by perhaps a factor of 5, simply by trying things out to discover
the unknown unknowns, instead of trying to think everything through in
excruciating detail. That is a pretty classic engineering approach, but would
never be allowed in a contracting model. The SpaceX team said it was far
cheaper to have crashes and find the problems than to try to wait forever until
there was no risk. [Mary Poppendieck]
Imitation is not a strategy. Differentiation is.
Differentiation is the strategic business goal that must be constantly sought after.
If pure invention seems nearly impossible, continuous and tenacious improvement
toward innovation should not. In this book, we have undertaken the task of helping
readers achieve strategic business differentiation through relentless improvement in
digital transformation.
Digital Transformation: What Is the Goal?
Understanding that the making of the unordinary is a major feat should not dis-
suade anyone from taking small, scientific steps with ongoing determination toward
actual innovation. No matter the complexity in reaching Z, performing the science
of experimentation to arrive at B when starting from A is a realistic expectation.
After that, reaching C is doable, which then leads to D. It’s a matter of keeping our
lab coat and pocket protector on, and acknowledging that unique products that can
capture new markets have likely been staring us in the face all along.](https://image.slidesharecdn.com/25074925-250521110043-6af38133/85/Strategic-Monoliths-And-Microservices-Driving-Innovation-Using-Purposeful-Architecture-Vaughn-Vernon-45-320.jpg)
![D T: W I G? 9
Whether Microsoft Office was considered a worker-productivity innovation
from the outset, it certainly has been the most successful suite in that market. With
Office 365, Microsoft didn’t have to reinvent the word processor and the spread-
sheet to innovate. It did, however, add a new delivery mechanism and capabilities to
enable full teams to collaborate, among other features. Did Microsoft win yet again
by innovating through digital transformation?
Digital transformation is left to the eye of the business innovator, but commonly
businesses lose sight of the innovation part of transformation. Transformative
innovation requires that the business understands the difference between changing
infrastructural platforms and building new product value. For example, although
taking business digital assets from the on-premises datacenter to the cloud might be
an important IT initiative, it is not in itself a business initiative in innovation.
Does migrating your software to the cloud qualify as a digital transformation?
Possibly, but more so if the move supports future differentiation. It best qualifies
if the cloud delivers new opportunities to innovate or at least to unburden the
extremely high cost of digital asset operations and channel those funds to new prod-
ucts. Think of the cloud as creating opportunities by freeing you from most tradi-
tional datacenter responsibilities. It won’t be transformative, however, if the shift
to the cloud amounts to trading one set of costs for a different set of costs. Amazon
offering its already successful computing infrastructure to the outside world was a
digital transformation for the company that resulted in cloud innovation. Paying
a subscription to Amazon to use its cloud is not a transformative innovation to the
subscriber. The lesson is clear: Innovate or be innovated on.
Just as migrating to the cloud is not an innovation, neither is creating a new distrib-
uted computing architecture. Users don’t care about distributed computing, Micro-
services, or Monoliths, or even features. Users care about outcomes. Improved user
outcomes are needed rapidly and without negatively impacting their workflows. For
software to stand a chance at meaningful transformation, its architecture and design
must support the delivery of better user outcomes as rapidly as possible.
When using the cloud, an improved architecture and design approach (and any
additional well-tuned steps that lead to productivity gains) make reaching inno-
vative transformational goals possible. Using infrastructure as a service frees the
business to work on innovative business software rather than churning on trying
to innovate on its infrastructure. Not only are infrastructure innovations time-
consuming and costly, but they might not benefit the business’s bottom line, and
developing infrastructure in-house might never address infrastructure and opera-
tional needs as well as AWS, Google Cloud Platform, and Azure. Yet, this is not
always the case. For some businesses, it would be much more cost-effective to bring
operations in-house or keep them there [a16z-CloudCostParadox].
Remember, it’s A to B, B to C, C to D. . . . Be willing to iterate on any of these
steps so that you can learn enough to take the next one. Understanding that going](https://image.slidesharecdn.com/25074925-250521110043-6af38133/85/Strategic-Monoliths-And-Microservices-Driving-Innovation-Using-Purposeful-Architecture-Vaughn-Vernon-46-320.jpg)
![C 1 B G D T
12
Just as dangerous as producing no well-defined architecture at all is intro-
ducing architecture for merely technical reasons. A fascination often exists among
software architects and developers with regard to a novel development style rela-
tive to what they previously employed, or even a newly named software tool that is
the subject of a lot of hype and industry buzz. This generally introduces accidental
complexity2
because the IT professionals don’t fully understand what impacts their
ill-advised decisions will have on the overall system, including its execution environ-
ment and operations. Yes, Microservices architecture and tools such as Kubernetes,
although duly applicable in the proper context, drive a lot of unqualified adoption.
Unfortunately, such adoption is rarely driven by insights into business needs.
The prolonged buildup of software model inaccuracies within the system from
failure to perform urgent changes is described as the debt metaphor. In contrast, the
accumulation from accepting uncontrolled changes to a system is known as soft-
ware entropy. Both are worth a closer look.
Debt Metaphor
Decades ago, a very smart software developer, Ward Cunningham, who was
at the time working on financial software, needed to explain to his boss why the
current efforts directed toward software change were necessary [Cunningham].
The changes being made were not in any way ad hoc; in fact, they were quite the
opposite. The kinds of changes being made would make it look as if the software
developers had known all along what they were doing, and serve to make it look
like it was easy to do. The specific technique they used is now known as software
refactoring. In this case, the refactoring was done in the way it was meant to be
implemented—that is, to reflect the acquisition of new business knowledge into the
software model.
To justify this work, Cunningham needed to explain that if the team didn’t make
adjustments to the software to match their increased learning about the problem
domain, they would continue to stumble over the disagreement between the soft-
ware that existed and their current, refined understanding. In turn, the continued
stumbling would slow down the team’s progress on continued development, which
is like paying interest on a loan. Thus, the debt metaphor was born.
Anyone can borrow money to enable them to do things sooner than if they hadn’t
obtained the money. Of course, as long as the loan exists, the borrower will be
2. Accidental complexity is caused by developers trying to solve problems, and can be fixed. There
is also essential complexity inherent in some software, which is caused by the problems being
solved. Although essential complexity cannot be avoided, it can often be isolated in subsystems
and components specifically designed to tackle them.](https://image.slidesharecdn.com/25074925-250521110043-6af38133/85/Strategic-Monoliths-And-Microservices-Driving-Innovation-Using-Purposeful-Architecture-Vaughn-Vernon-49-320.jpg)
![W S G W 13
paying interest. The primary idea in taking on debt in the software is to be able to
release sooner, but with the idea that you must pay the debt sooner rather than later.
The debt is paid by refactoring the software to reflect the team’s newly acquired
knowledge of the business needs. In the industry at that time, just as it is today, soft-
ware was rushed out to users knowing that debt existed, but too often teams had the
idea that you never have to pay off the debt.
Of course, we all know what happens next. If debt continues to stack up and the
person borrows more and more, all the borrower’s money goes to paying interest
and they reach a point where they have zero buying power. Matters work the same
way with software debt, because eventually developers deep in debt will be severely
compromised. Adding new features will take longer and longer, to the point where
the team will make almost no progress.
One of the major problems with the contemporary understanding of the debt
metaphor is that many developers think this metaphor supports deliberately deliv-
ering poorly designed and implemented software so as to deliver sooner. Yet, the
metaphor doesn’t support that practice. Attempting that feat is more like borrowing
on subprime loans3
with upward adjustable interest rates, which often results in the
borrower becoming financially overextended to the point of defaulting. Debt is use-
ful only as long as it is controlled; otherwise, it creates instability within the entire
system.
Software Entropy
Software entropy4
is a different metaphor but closely related to the debt metaphor
in terms of the software system conditions it describes. The word entropy is used
in statistical mechanics in the field of thermodynamics to measure a system’s disor-
der. Without attempting to go too deep into this topic: “The second law of thermo-
dynamics states that the entropy of an isolated system never decreases over time.
Isolated systems spontaneously evolve towards thermodynamic equilibrium, the
state with maximum entropy” [Entropy]. The software entropy metaphor names
the condition of a software system where change is inevitable, and that change will
cause increasing uncontrolled complexity unless a vigorous effort is made to pre-
vent it [Jacobson].
3. It’s difficult to comprehend that some are unfamiliar with the 2008 financial crisis that extended
years into the future. This (ultimately global) crisis was triggered by subprime lending to unqual-
ified borrowers for home purchases. Some early readers of the manuscript for this book asked,
“What is a subprime loan?” Learning about that history could save those readers from a lot of
financial grief.
4. Other analogs besides entropy also paint a vivid picture of the problem, such as software rot,
software erosion, and software decay. The authors mostly use entropy.](https://image.slidesharecdn.com/25074925-250521110043-6af38133/85/Strategic-Monoliths-And-Microservices-Driving-Innovation-Using-Purposeful-Architecture-Vaughn-Vernon-50-320.jpg)
![C 1 B G D T
14
Big Ball of Mud
An application or system like the one previously described has become known as a Big
Ball of Mud. In terms of architecture, it has been further described as haphazardly
structured; sprawling; sloppy; duct-taped-and-baling-wired; jungle; unregulated
growth; repeated, expedient repair. “Information is shared promiscuously among
distant elements of the system, often to the point where nearly all the important
information becomes global or duplicated. The overall structure of the system may
never have been well defined. If it was, it may have eroded beyond recognition”
[BBoM].
It seems appropriate to describe the Big Ball of Mud “architecture” as the
unarchitecture.
Throughout the remainder of this chapter, as well as in this book in general, we
will key in on a few of these characteristics: haphazardly structured; unregulated
growth; repeated, expedient repair; information shared promiscuously; all import-
ant information global or duplicated.
An enterprise norm of the Big Ball of Mud results in organizations experiencing
competitive paralysis, which has spread across business industries. It is quite com-
mon for large enterprises, which once enjoyed competitive distinction, to become
hamstrung by systems with deep debt and nearly complete entropy.
You can easily contrast the Big Ball of Mud system in Figure 1.2 to that depicted
in Figure 1.1. Of course, the segment of the system in Figure 1.1 doesn’t represent
the number of features that are supported by the system in Figure 1.2, but clearly the
architecture of the first system brings order, whereas the lack thereof in the second
offers chaos.
Figure 1.2 The Big Ball of Mud might be classified as the unarchitecture.](https://image.slidesharecdn.com/25074925-250521110043-6af38133/85/Strategic-Monoliths-And-Microservices-Driving-Innovation-Using-Purposeful-Architecture-Vaughn-Vernon-51-320.jpg)
Strategic Monoliths And Microservices Driving Innovation Using Purposeful Architecture Vaughn Vernon
- 1. Strategic Monoliths And Microservices Driving Innovation Using Purposeful Architecture Vaughn Vernon download https://ebookbell.com/product/strategic-monoliths-and- microservices-driving-innovation-using-purposeful-architecture- vaughn-vernon-50149850 Explore and download more ebooks at ebookbell.com
- 2. Here are some recommended products that we believe you will be interested in. You can click the link to download. Strategic Monoliths And Microservices Driving Innovation Using Purposeful Architecture Tomasz Jaskula https://ebookbell.com/product/strategic-monoliths-and-microservices- driving-innovation-using-purposeful-architecture-tomasz- jaskula-44591310 Strategic Communication For Nonprofit Organisations Challenges And Alternative Approaches Evandro Oliveira https://ebookbell.com/product/strategic-communication-for-nonprofit- organisations-challenges-and-alternative-approaches-evandro- oliveira-44872080 Strategic It Governance 20 How Cios Succeed At Digital Innovation Philip Weinzimer https://ebookbell.com/product/strategic-it-governance-20-how-cios- succeed-at-digital-innovation-philip-weinzimer-45108126 Strategic Debriefing For Advanced Simulation Giorgio Capogna https://ebookbell.com/product/strategic-debriefing-for-advanced- simulation-giorgio-capogna-45333382
- 3. Strategic Market Relationships From Strategy To Implementation 2nd Edition Bill Donaldson https://ebookbell.com/product/strategic-market-relationships-from- strategy-to-implementation-2nd-edition-bill-donaldson-45848478 Strategic Autonomy And Economic Power The Economy As A Strategic Theater Vtor Bento https://ebookbell.com/product/strategic-autonomy-and-economic-power- the-economy-as-a-strategic-theater-vtor-bento-46098442 Strategic Public Relations Writing Proven Tactics And Techniques Jim Eggensperger https://ebookbell.com/product/strategic-public-relations-writing- proven-tactics-and-techniques-jim-eggensperger-46149782 Strategic Narratives Ontological Security And Global Policy Thomas Colley https://ebookbell.com/product/strategic-narratives-ontological- security-and-global-policy-thomas-colley-46303986 Strategic Spatial Planning Support System For Sustainable Development Agentbased Modelling And Simulation Yan Ma https://ebookbell.com/product/strategic-spatial-planning-support- system-for-sustainable-development-agentbased-modelling-and- simulation-yan-ma-46462824
- 6. Praise for Strategic Monoliths and Microservices “Most books address either the business of software or the technical details of building soft- ware. Strategic Monoliths and Microservices provides a comprehensive approach to blend- ing the needs of business and technology in an approachable way. It also dispels many of today’s myths while offering practical guidance that any team or organization can apply immediately and with confidence.” —James Higginbotham, Executive API Consultant, Founder of LaunchAny, and author of Principles of Web API Design “Digital Transformation cannot succeed as a ‘grass roots’ effort. Vaughn and Tomasz offer C-level execs a roadmap to software excellence that includes establishing the culture nec- essary to foster and sustain software innovation. Written with real-world understanding, Vaughn and Tomasz help the reader to appreciate that moving software development from a cost center to a profit center involves tradeoffs that need not sacrifice innovation. A must- read for decision makers.” —Tom Stockton, Principal Architect, MAXIMUS “In this book, Vaughn Vernon and Tomasz Jaskuła use their extensive experience with DDD to present a comprehensive guide to using the many different aspects of DDD for modern systems development and modernization. It will be a valuable guide for many technical lead- ers who need to understand how to use DDD to its full potential.” —Eoin Woods, software architect and author “There are common misconceptions and roots of failure around software engineering. One notable example is neglecting the rugged trek towards digital transformation. Such an endeavor comprises breakthrough innovations, failure culture, emphasis on the role of soft- ware architecture, as well as on the importance of efficient and effective inter-human com- munication. Fortunately, the authors offer the necessary help for mastering all hurdles and challenges. What I like most about this book is the holistic view it provides to all stakehold- ers involved in digital transformation and innovation. Vaughn Vernon and Tomasz Jaskuła introduce a clear path to successful innovation projects. They provide insights, tools, proven best practices, and architecture styles both from the business and engineering viewpoint. Their book sheds light on the implications of digital transformation and how to deal with them successfully. This book deserves to become a must-read for practicing software engi- neers, executives, as well as senior managers. It will always serve me as a precious source of guidance and as a navigator whenever I am entering unchartered territories.” —Michael Stal, Certified Senior Software Architect, Siemens Technology
- 7. “Digital transformation is a much used but little understood concept. This book provides valuable insight into this topic and how to leverage your existing assets on the journey. Mod- ern technical and social techniques are combined in the context of a single case study. Com- pelling reading for both business and technology practitioners.” —Murat Erder,ƛco-author of Continuous Architecture in Practice (2021) and Continuous Architecture (2015) “Packed with insightful recommendations for every executive leader seeking clarity on the distinction between when to strategically apply a monolith vs. microservice architectural approach for success. Highly encourage every CEO, CIO, CTO, and (S)VP of Software Development to start here with immersing themselves in Vaughn and Tomasz’s succinct distillation of the advantages, disadvantages, and allowance for a hybrid combination, and then go become a visionary thought leader in their respective business domain.” —Scott P. Murphy, Principal Architect, Maximus, Inc. “A ‘must-read’ for Enterprise leaders and architects who are planning for or executing a digital transformation! The book is a true guide for ensuring your enterprise software inno- vation program is successful.” —Chris Verlaine, DHL Express Global Aviation IT DevOps Director, Head of DHL Express Global Aviation IT Software Modernization Program “Strategic Monoliths and Microservices is a great resource to connect business value to an evolvable enterprise architecture. I am impressed with how the authors use their deep under- standing and experience to guide informed decisions on the modularization journey. Along the way every valuable tool and concept is explained and properly brought into context. Definitely a must-read for IT decision makers and architects. For me this book will be an inspiring reference and a constant reminder to seek the purpose in architecture. The Micro- services discussion has reached a completely new maturity level.” —Christian Deger, Head of Architecture and Platform at RIO | The Logistics Flow, organizer of over 60 Microservices Meetups “The choice of microservices or monoliths architecture goes far beyond technology. The cul- ture, organization, and communication that exist within a company are all important factors that a CTO must consider carefully in order to successfully build digital systems. The authors explain this extremely well from various perspectives and based on very interesting examples.” —Olivier Ulmer, CTO, Groupe La Française “Building a technology engine to move quickly, experiment, and learn is a competitive advantage in today’s digital world. Will ‘de-jour architecture’ help with this endeavor? This amazing book by Vaughn and Tomasz fills a void in the market and re-focuses on the core objectives of software architecture: move fast, experiment, focus on the outcomes that bring value. A reader will come away better suited to decide whether microservices architecture and all the complexity with it is right for them.” —Christian Posta, Global Field CTO, Solo.io
- 8. Strategic Monoliths and Microservices
- 9. The Pearson Addison-Wesley Signature Series provides readers with practical and authoritative information on the latest trends in modern technology for computer professionals. The series is based on one simple premise: great books come from great authors. Vaughn Vernon is a champion of simplifying software architecture and development, with an emphasis on reactive methods. He has a unique ability to teach and lead with Domain-Driven Design using lightweight tools to unveil unimagined value. He helps organizations achieve competitive advantages using enduring tools such as architectures, patterns, and approaches, and through partnerships between business stakeholders and software developers. Vaughn’s Signature Series guides readers toward advances in software development maturity and greater success with business-centric practices. The series emphasizes organic refinement with a variety of approaches—reactive, object, and functional architecture and programming; domain modeling; right-sized services; patterns; and APIs—and covers best uses of the associated underlying technologies. Visit informit.com/awss/vernon for a complete list of available publications. Pearson Addison-Wesley Signature Series Make sure to connect with us! informit.com/socialconnect
- 10. Strategic Monoliths and Microservices Driving Innovation Using Purposeful Architecture Vaughn Vernon Tomasz Jaskuła Boston • Columbus • New York • San Francisco • Amsterdam • Cape Town Dubai • London • Madrid • Milan • Munich • Paris • Montreal • Toronto • Delhi • Mexico City São Paulo • Sydney • Hong Kong • Seoul • Singapore • Taipei • Tokyo
- 11. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and the publisher was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals. The authors and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein. For information about buying this title in bulk quantities, or for special sales opportunities (which may include electronic versions; custom cover designs; and content particular to your business, training goals, marketing focus, or branding interests), please contact our corporate sales department at corpsales@pearsoned.com or (800) 382-3419. For government sales inquiries, please contact governmentsales@pearsoned.com. For questions about sales outside the U.S., please contact intlcs@pearson.com. Visit us on the Web: informit.com/aw Library of Congress Control Number: 2021943427 Copyright © 2022 Pearson Education, Inc. Cover image: John I Catlett/Shutterstock Figures 1.5, 1.6, 1.7: illustration by grop/Shutterstock Pages 109 and 152: Dictionary definitions from Merriam-Webster. Used with Permission. All rights reserved. This publication is protected by copyright, and permission must be obtained from the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or by any means, electronic, mechanical, photocopying, recording, or likewise. For information regarding permissions, request forms and the appropriate contacts within the Pearson Education Global Rights & Permissions Department, please visit www.pearson.com/permissions/. ISBN-13: 978-0-13-735546-4 ISBN-10: 0-13-735546-7 ScoutAutomatedPrintCode
- 12. vii Contents Foreword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxv About the Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxi Part I: Transformational Strategic Learning through Experimentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Chapter 1: Business Goals and Digital Transformation . . . . . . . . . . . . . . . . 7 Digital Transformation: What Is the Goal? . . . . . . . . . . . . . . . . . . . . . . 8 Software Architecture Quick Glance . . . . . . . . . . . . . . . . . . . . . 10 Why Software Goes Wrong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Debt Metaphor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Software Entropy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Big Ball of Mud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Running Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Your Enterprise and Conway’s Law . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Communication Is about Knowledge . . . . . . . . . . . . . . . . . . . . 19 The Telephone Game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Reaching Agreement Is Hard . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 But Not Impossible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 (Re)Thinking Software Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Thinking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Rethinking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Are Monoliths Bad? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Are Microservices Good? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Don’t Blame Agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
- 13. C viii Getting Unstuck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Chapter 2: Essential Strategic Learning Tools . . . . . . . . . . . . . . . . . . . . . . 39 Making Decisions Early and Late, Right and Wrong . . . . . . . . . . . . . . 40 Culture and Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Failure Is Not Fatal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Failure Culture Is Not Blame Culture . . . . . . . . . . . . . . . . . . . . 46 Getting Conway’s Law Right . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Enabling Safe Experimentations . . . . . . . . . . . . . . . . . . . . . . . . 51 Modules First . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Deployment Last . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Everything in Between . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Business Capabilities, Business Processes, and Strategic Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Strategic Delivery on Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Using Cynefin to Make Decisions . . . . . . . . . . . . . . . . . . . . . . . 66 Where Is Your Spaghetti and How Fast Does It Cook? . . . . . . . . . . . . 70 Strategic Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Applying the Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Chapter 3: Events-First Experimentation and Discovery . . . . . . . . . . . . . . 77 Commands and Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Using Software Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Rapid Learning with EventStorming . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 When Remote Sessions Are Demanded . . . . . . . . . . . . . . . . . . . 84 Facilitating Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Big-Picture Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Applying the Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
- 14. C ix Part II: Driving Business Innovation . . . . . . . . . . . . . . . . . . . 101 Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Chapter 4: Reaching Domain-Driven Results . . . . . . . . . . . . . . . . . . . . . 109 Domains and Subdomains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 Chapter 5: Contextual Expertise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Bounded Context and Ubiquitous Language . . . . . . . . . . . . . . . . . . . 117 Core Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Supporting Subdomains, Generic Subdomains, and Technical Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 Supporting Subdomains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 Generic Subdomains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 Technical Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Business Capabilities and Contexts . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Not Too Big, Not Too Small . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 Chapter 6: Mapping, Failing, and Succeeding—Choose Two . . . . . . . . . 131 Context Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 Partnership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Shared Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 Customer–Supplier Development . . . . . . . . . . . . . . . . . . . . . . 137 Conformist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Anticorruption Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 Open-Host Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 Published Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 Separate Ways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Topography Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Ways to Fail and Succeed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 Applying the Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
- 15. C x Chapter 7: Modeling Domain Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 165 Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Value Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 Aggregates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 Domain Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Functional Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 Applying the Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 Part III: Events-First Architecture . . . . . . . . . . . . . . . . . . . . . 175 Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 Chapter 8: Foundation Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 Architectural Styles, Patterns, and Decision Drivers . . . . . . . . . . . . . 183 Ports and Adapters (Hexagonal) . . . . . . . . . . . . . . . . . . . . . . . 183 Modularization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 REST Request–Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 Quality Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 Resilience: Reliability and Fault Tolerance . . . . . . . . . . . . . . . 204 Complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 Applying the Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 Chapter 9: Message- and Event-Driven Architectures . . . . . . . . . . . . . . . 211 Message- and Event-Based REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 Event Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 Subscriber Polling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 Server-Sent Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 Event-Driven and Process Management . . . . . . . . . . . . . . . . . . . . . . . 220 Event Sourcing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
- 16. C xi CQRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 Serverless and Function as a Service . . . . . . . . . . . . . . . . . . . . . . . . . . 229 Applying the Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 Part IV: The Two Paths for Purposeful Architecture . . . . . . 233 Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 Chapter 10: Building Monoliths Like You Mean It . . . . . . . . . . . . . . . . . 239 Historical Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 Right from the Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 Business Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 Architecture Decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 Right from Wrong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 Change within Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 Break the Coupling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 Keeping It Right . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 Chapter 11: Monolith to Microservices Like a Boss . . . . . . . . . . . . . . . . 267 Mental Preparation with Resolve . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 Modular Monolith to Microservices . . . . . . . . . . . . . . . . . . . . . . . . . . 271 Big Ball of Mud Monolith to Microservices . . . . . . . . . . . . . . . . . . . . 275 User Interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 Harmonizing Data Changes . . . . . . . . . . . . . . . . . . . . . . . . . . 278 Deciding What to Strangle . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 Unplugging the Legacy Monolith . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288 Chapter 12: Require Balance, Demand Strategy . . . . . . . . . . . . . . . . . . . 289 Balance and Quality Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 Strategy and Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 Business Goals Inform Digital Transformation . . . . . . . . . . . 291 Use Strategic Learning Tools . . . . . . . . . . . . . . . . . . . . . . . . . . 292
- 17. C xii Event-Driven Lightweight Modeling . . . . . . . . . . . . . . . . . . . . 292 Driving Business Innovation . . . . . . . . . . . . . . . . . . . . . . . . . . 293 Events-First Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294 Monoliths as a First-Order Concern . . . . . . . . . . . . . . . . . . . . 295 Purposeful Microservices from a Monolith . . . . . . . . . . . . . . 295 Balance Is Unbiased, Innovation Is Essential . . . . . . . . . . . . . 296 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
- 18. xiii Foreword We met the founders of Iterate in April 2007. Three of them had attended our first workshop in Oslo and invited us out to dinner. There, we learned they had just quit their jobs at a consulting firm and founded their own, so they could work in a place they loved using techniques they believed in. I thought to myself, “Good luck with that.” After all, they were just a few years out of college and had no experience running a business. But I kept my skepticism to myself as we talked about how to find good customers and negotiate agile contracts. We visited Iterate many times over the next decade and watched it grow into a successful consulting firm that was routinely listed as one of Norway’s best places to work. They had a few dozen consultants and evolved from writing software to coaching companies in Test-Driven Development to helping companies innovate with design sprints. So I should have seen it coming, but when they decided to trans- form the company in 2016, I was surprised. We decided to change course, they told us. We want to be a great place to work, where people can reach their full potential, but our best people are limited as con- sultants. They are always pursuing someone else’s dream. We want to create a com- pany where people can follow their own passion and create new companies. We want to nurture startups and fund this with our consulting revenue. Once again I thought to myself, “Good luck with that.” This time I did not keep my skepticism to myself. We talked about the base failure rate of new ventures and the mantra from my 3M days: “Try lots of stuff and keep what works.” That’s a great motto if you have a lot of time and money, but they had neither. One of the founders was not comfortable with the new approach and left the company. The others did what they had always done—move forward step-by-step and iterate toward their goal. It was not easy and there were no models to follow. Wary of outside funding, they decided to merge the diametrically opposed business models of consulting and venture funding by limiting to 3% the amount of profit they could make from con- sulting, pouring the rest back into funding ventures. They had to make sure that consultants did not feel like second-class citizens and those working on new ven- tures were committed to the success of the consulting business. And they had to learn how to successfully start up new businesses when all they’d ever started was a consulting business.
- 19. F xiv It’s been five years. Every year we visited to brainstorm ideas as the company struggled to make their unique approach work. When the pandemic hit, not only did their consulting business grind to a halt, but the farm-to-restaurant business they had nurtured for three years had no restaurants left to buy local farm goods. But think about it: Iterate had top talent with nothing to do and a venture that was poised to collect and deliver perishable goods. It took two weeks to pivot—they offered the food to consumers for curbside pickup—and the venture took off. While most Oslo consulting firms suffered in 2020, Iterate saw one venture (last- mile delivery) exit through a successful acquisition and three others spin off as separate entities, including a ship-locating system and a three-sided platform for knitters, yarn suppliers, and consumers. As a bonus, Iterate was number 50 on Fast Company’s 2020 list of Best Workplaces for Innovators, ahead of Slack and Square and Shopify. So how did Iterate succeed against all odds? They started by realizing that a con- sulting approach to software development did not give them the freedom to take a lead role. With software becoming a strategic innovation lever, they felt it was time to claim a seat at the decision-making table. This was scary, because it involved tak- ing responsibility for results—something consultants generally avoid. But they were confident that their experimental approach to solving challenging problems would work for business problems as well as technical problems, so they forged ahead. You might wonder what Iterate’s transformation has to do with the enterprise transformations that are the subject of this book. There is nothing in Iterate’s story about Monoliths or Microservices or agile practices—but these are not the essence of a transformation. As this book points out, a transformation begins with the articulation of a new and innovative business strategy, one that provides real, dif- ferentiated value to a market. The pursuit of that strategy will be a long and chal- lenging journey, requiring excellent people, deep thinking, and plenty of learning along the way. For those who are starting out on such a transformation, this book provides a lot of thinking tools for your journey. For example, as you head in a new direction, you probably do not want to blow up the structures that brought your current success, however outmoded they might be. You need that old Big Ball of Mud Monolith (or consulting services) to fund your transition. Another example: The first thing you want to consider is the right architecture for your new business model, and it probably won’t be the same as the old one. Just as Iterate moved from having a pool of consultants to having clearly distinct venture teams, you will probably want to structure your new architecture to fit the domain it operates in. This usually means clarifying the business capabilities that fit the new strategy and structuring complete teams around these capabilities. So instead of
- 20. F xv having a layered architecture, you are likely to want one based on the natural compo- nents and subcomponents of your product (also known as Bounded Contexts). Think of SpaceX: The architecture of a launch vehicle is determined by its components—first stage (which contains nine Merlin engines, a long fuselage, and some landing legs), interstage, second stage, and payload. Teams are not formed around engineering disciplines (e.g., materials engineering, structural engineering, software engineering), but rather around components and subcomponents. This gives each team a clear responsibility and set of constraints: Teams are expected to understand and accomplish the job their component must do to ensure the next launch is successful. As you clarify the product architecture in your new strategy, you will proba- bly want to create an organization that matches this architecture because, as the authors point out, you can’t violate Conway’s Law any more than you can violate the law of gravity. The heart of this book is a large set of thinking tools that will help you design a new architecture (quite possibly a modular Monolith to begin with) and the organization needed to support that architecture. The book then offers ways to gradually move from your existing architecture toward the new one, as well as presents ideas about when and how you might want to spin off appropri- ate services. Over time, Iterate learned that successful ventures have three things in common: • Good market timing • Team cohesion • Technical excellence Market timing requires patience; organizations that think transformations are about new processes or data structures tend to be impatient and generally get this wrong. Transformations are about creating an environment in which innovation can flourish to create new, differentiated offerings and bring them to market at the right time. The second element of success, team cohesion, comes from allowing the capa- bilities being developed (the Bounded Contexts) and the relevant team members to evolve over time, until the right combination of people and offering emerges. The third element, technical excellence, is rooted in a deep respect for the technical complexity of software. This book will help you appreciate the complexity of your existing system and future versions of that system, as well as the challenge of evolv- ing from one to the other. The Iterate story contains a final caution: Your transition will not be easy. Iterate had to figure out how to meld a consulting pool with venture teams in such a way
- 21. F xvi that everyone felt valuable and was committed to the organization’s overall success. This is something that every organization will struggle with as it goes through a transition. There is no formula for success other than the one offered in this book: highly skilled people, deep thinking, and constant experimentation. There is no silver bullet. —Mary Poppendieck, co-author of Lean Software Development
- 22. xvii Preface Chances are good that your organization doesn’t make money by selling software in the “traditional sense,” and perhaps it never will. That doesn’t mean that soft- ware can’t play a significant role in making money for your organization. Software is at the heart of the wealthiest companies. Take, for example, the companies represented by the acronym FAANG: Face- book, Apple, Amazon, Netflix, and Google (now held by Alphabet). Few of those companies sell any software at all, or at least they do not count on software sales to generate the greater part of their revenues. Approximately 98% of Facebook’s money is made by selling ads to companies that want access to the members of its social networking site. The ad space has such high value because Facebook’s platform provides for enormous engagement between members. Certain members care about what is happening with other mem- bers and overall trends, and that keeps them engaged with people, situations, and the social platform. Capturing the attention of Facebook members is worth a lot of money to advertisers. Apple is for the most part a hardware company, selling smartphones, tablets, wearables, and computers. Software brings out the value of said smartphones and other devices. Amazon uses a multipronged approach to revenue generation, selling goods as an online retailer; selling subscriptions to unlimited e-books, audio, music, and other services; and selling cloud computing infrastructure as a service. Netflix earns its revenues by selling multilevel subscriptions to movie and other video streaming services. The company still earns money through DVD subscrip- tions, but this part of the business has—as expected—fallen off sharply with the ris- ing popularity of on-demand streaming. The video streaming is enhanced for, and controlled by, the experience with user-facing software that runs on TVs and mobile devices. Yet, the real heavy lifting is done by the cloud-based system that serves the videos from Amazon’s AWS. These services provide video encoding in more than 50 different formats, serving up content through content delivery networks (CDN) and dealing with chaotic failures in the face of cloud and network outages. Google also makes its money through ad sales; these ads are served along with query results from its search engine software. In 2020, Google earned approxi- mately $4 billion from direct software usage, such as via Google Workspace. But
- 23. P xviii the Google Workspace software does not have to be installed on user computers, because it is provided in the cloud using the Software as a Service (SaaS) model. According to recent reports, Google owns nearly 60% of the online office suite mar- ket, surpassing even the share claimed by Microsoft. As you can see from these industry leaders’ experiences, your organization doesn’t need to sell software to earn market-leading revenues. It will, however, need to use software to excel in business both now and over the years to follow. What is more, to innovate using software, an organization must recognize that a contingent of software architects and engineers—the best—matter. They matter so much that the demand for the best makes them ridiculously difficult to hire. Think of the significance of landing any one of the top 20 picks in the WNBA or NFL draft. Of course, this description does not apply to every software developer. Many or even most are content to “punch a clock,” pay their mortgage, and watch as much of the WNBA and NFL on TV as they possibly can. If those are the prospects you want to recruit, we strongly suggest that you stop reading this book right now. Conversely, if that’s where you’ve been but now you want to make a meaningful change, read on. For those organizations seeking to excel and accelerate their pace of innovation, it’s important to realize that software development achievers are more than just “valuable.” If a business is to innovate by means of software to the extent of ruling its industry, it must recognize that software architects and engineers of that ilk are “The New Kingmakers,” a term coined by Stephen O’Grady in his 2013 book The New Kingmakers: How Developers Conquered the World [New-Kingmakers]. To truly succeed with software, all businesses with audacious goals must understand what drives this ilk of developer to transcend common software creation. The kinds of software that they yearn to create are in no way ordinary or obvious. The most valuable software developers want to make the kind of software that determines the future of the industry, and that’s the recruiting message your organization must sound to attract (1) the best and (2) those who care enough to become the best. This book is meant for C-level and other business executives, as well as every role and level involved in leading software development roles. Everyone responsi- ble for delivering software that either directly results in strategic differentiation, or supports it, must understand how to drive innovation with software. The authors have found that today’s C-level and other executives are a different breed than their predecessors from decades past. Many are tech savvy and might even be considered experts in their business domain. They have a vision for making things better in a specific place, and they attract other executives and deeply techni- cal professionals who grok what the founder or founders are driving to accomplish: • CEOs who are close to the technology vision, such as startup CEOs, and those who want to be informed about the role of software in their future
- 24. P xix • CIOs who are responsible for facilitating and enabling software development as a differentiator • CTOs who are leading software vision through innovation • Senior vice presidents, vice presidents, directors, project managers, and others who are charged with carrying the vision to realization • Chief architects, who will find this book inspiring and a forceful guide to motivate teams of software architects and senior developers to drive change with a business mindset and purposeful architecture • Software architects and developers of all levels, who are trying to firmly fix a business mentality in themselves—that is, a recognition that software devel- opment is not merely a means to a good paycheck, but to prospering beyond the ordinary and obvious through software innovation This is a vital message that all software professionals must learn from by con- suming, ruminating on, and practicing the expert techniques explored in this book. Strategic Monoliths and Microservices: Driving Innovation Using Purpose- ful Architecture is not a book on implementation details. We’ll provide that kind of information in our next book, Implementing Strategic Monoliths and Micro- services (Vernon & Jaskuła, Addison-Wesley, forthcoming). This volume is very much a book on software as part of business strategy. This book is definitely of interest to leaders who lack deep knowledge or experi- ence in the software industry. It informs by showing how every software initiative must discover big ideas, architect with purpose, design strategically, and implement to defeat complexity. At the same time, we vigorously warn readers to resist drag- ging accidental or intentional complexity into the software. The point of driving change is to deliver software that works even better than users/customers expect. Thus, this book is meant to shake up the thinking of those stuck in a rut of the sta- tus quo, defending their jobs rather than pushing forward relentlessly as champions of the next generation of ideas, methods, and devices—and perhaps becoming the creators of the future of industry as a result. The authors of this book have worked with many different clients and have seen firsthand the negative side of software development, where holding on to job secu- rity and defending turf is the aim rather than making the business thrive by driving prosperity. Many of the wealthiest companies are so large, and are engaged in so many initiatives under many layers of management and reporting structure, that their vision-to-implementation-to-acceptance pathway is far from a demonstration of continuity. With that in mind, we’re attempting to wake the masses up to the fact that the adage “software is eating the world” is true. Our lessons are served up with
- 25. P xx a dollop of realism, demonstrating that innovation can be achieved by means of progressive practical steps rather than requiring instantaneous gigantic leaps. There is always risk in attempting innovation. That said, not taking any risk at all will likely be even more risky and damaging in the long run. The following sim- ple graph makes this point very clear. Figure P.1 There is a risk in taking a risk, but likely even a greater risk in playing it safe. As Natalie Fratto [Natalie-Fratto-Risk] suggests, it is generally the case that the risk of taking risks diminishes over time, but the risk of playing it safe increases over time. The venture investor side of Natalie can be seen in her TED Talk [Natalie- Fratto-TED], which explains the kinds of founders in whose businesses she invests. As she explains, many investors seek business founders with a high intelligence quotient (IQ), whereas others look for entrepreneurs with a high emotional quo- tient (EQ). She looks primarily for those with a high adaptability quotient (AQ). In fact, innovation calls for a great amount of adaptability. You’ll find that message repeated in this book in several forms. Everything from experimentation to discov- ery to architecture, design, and implementation requires adaptability. Risk takers are unlikely to succeed unless they are very adaptable. As we discuss our primary topic of innovation with software, it’s impossible to entirely avoid the highly controversial topic of iterative and incremental devel- opment. Indeed, some form of the “A-word”—yes, agile/Agile—cannot be side- stepped. This book stays far away from promoting a specific and ceremonial way to use Agile or to be a lean business. Sadly, the authors have found that most com- panies and teams creating software claim to use Agile, yet don’t understand how to be agile. The desire is to emphasize the latter rather than reinforce the former. The original message of agile is quite simple: It’s focused on collaborative delivery. If kept simple, this approach can be highly useful. That said, this is nowhere near our primary message. We attempt only to draw attention to where “un-simple” use
- 26. P xxi causes damage and how being agile helps. For our brief discussion on how we think being agile can help, see the section “Don’t Blame Agile,” in Chapter 1, “Business Goals and Digital Transformation.” Given our background, it might surprise some readers to learn that we do not view Strategic Monoliths and Microservices as a Domain-Driven Design (DDD) book. To be sure, we introduce and explain the domain-driven approach and why and how it is helpful—but we haven’t limited our range. We also offer ideas above and beyond DDD. This is a “software is eating the world, so be smart and get on board, innovate, and make smart architectural decisions based on real purpose, before you are left behind” book. We are addressing the real needs of the kinds of companies with which we have been engaged for decades, and especially based on our observations over the past five to ten years. We have been slightly concerned that our drumbeat might sound too loud. Still, when considering the other drums beating all around technology-driven industries, we think a different kind of drumming is in order. When many others are on high mountains, constantly beating the “next over-hyped products as silver bullets” drum, there must be at least an equalizing attempt at promoting our brains as the best tooling. Our goal is to show that thinking and rethinking is the way to inno- vate, and that generic product acquisition and throwing more technology at hard problems is not a strategic plan. So, think of us as the people on an adjacent moun- tain beating the other drum to “be scientists and engineers” by advancing beyond the ordinary and obvious, by being innovative and just plain different. And, yes, we definitely broke a sweat doing that. If our intense drumbeat leaves readers with a lasting impression that our drums made that specific brain-stimulating rhythm, then we think we’ve achieved our goal. That’s especially so if the stimulation leads to greater success for our readers. Legend/Key for Diagrams Figure P.2 (on page xxii) shows the modeling elements used in most of the archi- tecture diagrams in this book. The elements used range from large- to small-scale, and those in between, depending on the topic of the diagram. Some are taken from EventStorming described on page 87. In Figure P.2, the top half, from the upper left, are strategic and architectural elements: Business/Bounded Context is a software subsystem and model boundary of a business capability and a sphere of knowledge; Big Ball of Mud is the “unarchi- tecture” in which most enterprises languish; Ports and Adapters Architecture is both a foundational and versatile style; and Modules are named packages that con- tain software components.
- 27. P xxii Figure P.2 Modeling elements used in architecture diagrams throughout this book. The bottom half of Figure P.2 depicts eight tactical component types, occurring within a subsystem and that sometimes flow to other subsystems: Commands cause state transitions; Events capture and carry record of state transitions across subsys- tem boundaries; Policy describes business rules; Aggregate/Entity holds state and offers software behavior; User Role interacts with the system and often represents a persona; View/Query collects and retrieves data that can be rendered on user interfaces; Process manages a multi-step operation through to an eventual comple- tion; and Domain Service provides cross-cutting software behavior. Refer to Figure P.2 for the legend/key of element types, especially when reading the black-and-white print book, which uses patterns in lieu of colors.
- 28. P xxiii References [Natalie-Fratto-Risk] https://twitter.com/NatalieFratto/status/ 1413123064896921602 [Natalie-Fratto-TED] https://www.ted.com/talks/ natalie_fratto_3_ways_to_measure_your_adaptability_and_how_to_improve_it [New-Kingmakers] https://www.amazon.com/ New-Kingmakers-Developers-Conquered-World-ebook/dp/B0097E4MEU Register your copy of Strategic Monoliths and Microservices on the InformIT site for convenient access to updates and/or corrections as they become avail- able. To start the registration process, go to informit.com/register and log in or create an account. Enter the product ISBN (9780137355464) and click Submit. Look on the Registered Products tab for an Access Bonus Content link next to this product, and follow that link to access any available bonus materials. If you would like to be notified of exclusive offers on new editions and updates, please check the box to receive email from us.
- 29. This page intentionally left blank
- 30. xxv Acknowledgments Writing a book is hard work. Readers might think that the more books written, the better the process is for the author. Multi-book authors would probably agree that the writing flows better as experience grows. Yet, most multi-book authors proba- bly aim higher each time than they knew how to do previously. Knowing what lies ahead before the writing begins can be unnerving. The experienced author knows that each book has a life of its own and requires more mental energy and writing precision than even their own expectations could predict. It happens every time, at least to one author involved in this effort. In the case of this book, one author knows what to fear and still did it anyway. The second author had translated a book from English to French, but his willingness to sign up for pure writing was based on the experienced author telling him not to worry. That might be what a shark cage guide says just before the steel around the rank amateur plunges them into the breathtakingly cold waters off of Cape Town, South Africa. Truth is, the spectators who gaze upon great whites in action are fairly safe, at least by statistical accounts, because no one has ever died from that extreme view- ing melee. Still, it’s a good thing that sharks aren’t as attracted to yellow and even brown in water as they are to blood. (We’ll leave the close-call research to you.) So, trying to write a book probably won’t kill you. Even so, have you ever wondered about the ratio between the people who have said they are going to write a book, but don’t, and those who actually do write a book? It’s probably similar to those who say they will one day dive with great white sharks and those who actually do. It might take one, two, or a few people to author a book. But it takes an army to review, edit, edit, edit—add more edits—produce, and publish that book. The first draft manuscript of this book was considered “very clean,” but there were still hundreds of additions, deletions, and general corrections made in every single chapter. And don’t bring up the illustrations. Please. Even the very best of writers— which these authors would never claim to be—are subject to a daunting battery of “live rounds” before their book is ready for the public. Actually, we’ll clarify that. That’s the case if you are an author under the prestigious Addison-Wesley brand. (We won’t go into the number of obvious errors you can find in the first few pages of books produced by other tech publishers.) The analogy of “live rounds” seems appropriate, because Pearson supports a small army of the best editors with the best aim that can be hired.
- 31. A xxvi We are grateful to Pearson Addison-Wesley for giving us the opportunity to pub- lish under their highly respected label. They have guided us through the process of writing this book until the publication was in sight. Special thanks go to our exec- utive editor, Haze Humbert, for driving the process of acquisition, review, develop- ment, and full editorial production so smoothly, and coddling the process when an overly optimistic author didn’t deliver all chapters as early as he anticipated. Haze’s assistant editor, Menka Mehta, kept correspondence and calendars in sync and flowing. Our development editors Sheri Replin and Chris Cleveland offered high- level edits and prepared our chapters for page layout. Thanks to Rachel Paul for keeping the publication process clipping along. Thanks also to Jill Hobbs for being so kind as she made our “very clean” manuscript read superbly; it’s amazing what a fine copy editor can do for a book, and especially a book written by tech authors. When you see things happening steadily but don’t know how, it’s probably due to a very competent director of product management, and in our case that is Julie Phifer. In case it is not abundantly clear, the vast majority of editorial professionals with whom we work are women, and we think it is fair to include this team as “women in tech.” If you are a woman in tech and want to be a book author, you can’t hope for a better team to work with. These authors are not only proud to collaborate with this team, but highly honored that they have trusted us enough to be their extended members. So, future women authors, or future multi-book women authors, please allow me to introduce Haze Humbert, as your gateway to the best experience that book authoring can offer. This book would not have been the same without the valuable feedback from our reviewers. In particular, we would like to thank Mary Poppendieck, who pro- vided an extensive review of our book and offered rich feedback, and wrote a great foreword. Mary gave us her in-depth perspective on the difference between a soft- ware developer and a software engineer. Of course, any company can hire for the position of software engineer, but Mary describes a role that goes far beyond a title. Readers will find many of her viewpoints highlighted by sidebars and boxes, but her gifts to our project are in no way “side anything”—her input is nothing less than pure gold. Pay attention to what she has to say. Other reviewers who offered particularly valuable reviews have served in such roles as CTO, chief architect, principal architect, and similar, and in a range of companies from very large to nimble startups. They are listed here in order by given (first) name: Benjamin Nitu, Eoin Woods, Frank Grimm, Olaf Zimmermann, Tom Stockton, and Vladik Khononov. There were several others who offered helpful feedback, including C-level executives, vice presidents, and other executives, who shall remain unnamed. We are honored to have gathered a group of highly expe- rienced tech executives who were early readers, and we are thrilled that they were very impressed with our book. We would be remiss if we did not mention the many
- 32. A xxvii people who offered to read and review our manuscript early on. We would have taken pleasure in that, but for various reasons it was not possible to include them. For every bit of help you provided and the confidence that you showed in us, thank you one and all. Vaughn Vernon This book would truly not have been possible without Haze Humbert. When Haze took over from my previous executive editor at Addison-Wesley, she actively suggested and discussed ideas for future books that I might write. Haze was very patient with me. After having three books published in roughly five years, I didn’t look forward to authoring another one anytime soon. I wasn’t burned out, just keenly aware of the commitment necessary to bring a new book to the world. And I was enjoying designing and creating software more than writing books. Being a creative person, during my discussions with Haze I pitched a number of ideas about which she could have laughed out loud. Yet, her kind demeanor and patience cov- ered my audacious and/or ludicrous project pitches. In early 2020, Haze offered an opportunity that was much more realistic, but completely unexpected and quite difficult to believe and digest, and whose accep- tance seemed daunting. Her offer was to become the editor of my own Vaughn Ver- non Signature Series. Knowing that my previous books had been successful—even best sellers—and appreciating that I could possibly achieve that feat again with another book, was far less earthshaking than fathoming the inception and deliv- ery of a signature series. It was mind-blowing stuff. After a few weeks and sev- eral discussions with my trusted advisor, Nicole, the idea sank in. One thought that solidified the possibility of succeeding was this: If Pearson Addison-Wesley, with its unmatched experience as an elite publisher, thought enough of my work to make that offer, it meant that the company was confident that I would succeed. There’s no way that such a publisher would pitch, invest in, and back this effort if it thought anything otherwise. Based on that alone, not on my own abilities, I accepted. So here I am today, deeply thankful to Haze and the others with whom she works and represents. Thank you all so much. I am grateful to Tomasz Jaskuła for accepting my offer to co-author this book with me. I hope the sharks didn’t get too close for comfort. Tomasz is smart and tenacious, and has also been a worthy business partner in our training and consult- ing efforts. He’s also done nearly all of the heavy lifting for the .NET implementa- tion of our open source reactive platform, VLINGO XOOM.
- 33. A xxviii Both of my parents have been a stabilizing force for me, and have taught me and supported my efforts for as long as I can remember. When I wrote my first pub- lished book, Implementing Domain-Driven Design, my parents were still full of life and mobile. More than eight years since, and after many months of lockdown have accumulated due to the pandemic, they now face additional challenges. It’s a relief that in-person visits with them are once again permitted, and our time together is so enjoyable. Mom still has her witty sense of humor, and her stamina has not entirely abandoned her. I am happy that Dad still yearns for handheld computers, books, and other tools that enable him to remain in touch with engineering. I look forward to seeing his eyes light up when I drop by with a new gadget or book. Mom and Dad, I can’t thank you enough. I can’t say enough about the ongoing support from my wife and our son. As crazy as the past 18 months or so have been, we’ve managed to grow together under con- tinually changing circumstances. Nicole has been incredibly resilient through what seemed like unavoidable damage to our businesses. Despite the challenges, she has led us to new highs in the growth of both our training and consulting company, Kalele, and our software product startup VLINGO. VLINGO XOOM, our open source reactive platform and our initial product, is healthy and its adoption is grow- ing. VLINGO is also building two new SaaS products. Not only have our teams been effective, but Nicole’s business savvy has only expanded under greater chal- lenges. It is inconceivable that I could have succeeded with anything at all, let alone a signature series and new book authoring, without her. Tomasz Jaskuła Back in 2013, Vaughn Vernon authored an outstanding book, Implementing Domain-Driven Design. He followed that with a world tour of workshops under the same name. His was the first book in which Domain-Driven Design was described from a practical point of view, shedding light on many theoretical concepts that were previously misunderstood or unclear for years in the Domain-Driven Design community. When I first learned about Vaughn’s IDDD Workshop, I didn’t hesitate to attend as soon as possible. It was a time when I was applying Domain-Driven Design on different projects, and I couldn’t miss the opportunity to meet one of the most prominent members of the community. So, in 2013 I met Vaughn in Leuven, Belgium, where one of the workshops took place. This was also where I met most of the Domain-Driven Design community influencers, who were there to learn from Vaughn! A few years later, I’m proud to have coauthored this book with Vaughn, who has become a friend. He has been supportive of me through the years and I’m really grateful for the confidence he has in me. Writing this book was a great
- 34. A xxix learning experience. Thank you, Vaughn, for all your help, your confidence in me, and your support. I would also like to thank Nicole Andrade, who, with all the kindness in the world, has supported us through the effort of writing this book. She has played an important role in strengthening the friendship between Vaughn and me through the years, and I know she will continue to do so for years to come. Writing the book without the support from my friend and business partner François Morin of our company, Luteceo, would have been much more difficult. His encouragement of my writing, and his willingness to take care of running the com- pany while I was not available, gave me the space I needed to take on this project. I would like to thank my parents Barbara and Stefan, who have always believed in me and supported me through my personal challenges. They taught me early the importance of being curious and learning continuously, which is one of the greatest pieces of advice I could have ever received. Finally, I would not have been able to write this book without the unconditional support and love from my wife Teresa and my lovely daughters Lola and Mila. Their encouragement and support were essential for me to complete this book. Thank you so much.
- 35. This page intentionally left blank
- 36. xxxi About the Authors Vaughn Vernon is an entrepreneur, software developer, and architect with more than 35 years of experience in a broad range of business domains. Vaughn is a lead- ing expert in Domain-Driven Design and reactive architecture and programming, and champions simplicity. Students of his workshops are consistently impressed by the breadth and depth of what he teaches and his unique approaches, and as a result have become ongoing students attending his other well-known workshops. He con- sults and trains around Domain-Driven Design, reactive software development, as well as EventStorming and Event-Driven Architecture, helping teams and organiza- tions realize the potential of business-driven and reactive systems as they transform their businesses from technology-driven legacy web implementation approaches. Vaughn is the author of four books, including the one you are now reading. His books and his Vaughn Vernon Signature Series are all published by Addison-Wesley. Kalele: https://kalele.io VLINGO: https://vlingo.io Twitter: @VaughnVernon LinkedIn: https://linkedin.com/in/vaughnvernon/ Tomasz Jaskuła is CTO and co-founder of Luteceo, a software consulting com- pany in Paris. Tomasz has more than 20 years of professional experience as a devel- oper and software architect, and worked for many companies in the e-commerce, industry, insurance, and financial fields. He has mainly focused on creating soft- ware that delivers true business value, aligns with strategic business initiatives, and provides solutions with clearly identifiable competitive advantages. Tomasz is also a main contributor to the OSS project XOOM for the .NET platform. In his free time, Tomasz perfects his guitar playing and spends time with his family. Twitter: @tjaskula LinkedIn: https://linkedin.com/in/tomasz-jaskula-16b2823/
- 37. This page intentionally left blank
- 38. 1 Part I Transformational Strategic Learning through Experimentation
- 39. This page intentionally left blank
- 40. 3 Executive Summary Part I of the book introduces the goals of this book by establishing digital transfor- mation as a revenue-generating business strategy. Every nontrivial business must take seriously the vital need to focus on software building as the only way to survive the next few decades of interindustry competition. Yet, survival all too often results from delivering from a position of weakness and fear, or simply lack of innovative thinking. To lead with boldness, courage, and confidence requires delivering business- driven differentiating software that transcends the obvious and ordinary benefits that the survivors manage to shove in front of users. The clear winners turn up the dial on innovation. This kind of success can be fostered by improving what a given industry has already achieved, and by realizing the improvements as software prod- ucts. Some winners will, as inventors, entirely change the way an industry works. Even so, invention is not necessary to be a winning innovator. Accomplishing innovation as an industry leader happens deliberately. The great- est innovations have come from relentless experimentation coupled with continu- ous improvement. The mindset and tools that support this kind of drive are taught in the first three chapters. Chapter 1: Business Goals and Digital Transformation SpaceX didn’t invent the rocket or space travel and exploration. Instead, SpaceX innovated to the extreme in a preexisting but relatively closed industry. • Understand that the real goal is business-driven breakthroughs rather than a steady stream of shiny new technical products to excite the geeks. Unless the shiny things have a clear and justifiable purpose, they will likely serve only to sidetrack real business-centric innovations. The focus should be on innova- tion with software products. • Recognize that innovation in general consists of realizing breakthrough improvements on what exists. There is a strong possibility that the poten- tial for uniquely innovative products that can capture new markets has been
- 41. P I T S L E 4 staring everyone in the face. What exists can be the catalyst for innovation that delivers even greater value than was available yesterday, given new deliv- ery mechanisms and revenue models. • Perceive where software efforts go wrong. Doing so can be a great way to recognize when the same problems start to happen in a local system project, or already have occurred. Such problems usually begin with a lack of effective collaborative communication, or when communication occurs but without recognizing when topics shift from one area of expertise to another. Both sit- uations lead to large, mud-like software that just won’t die. • Communication is about knowledge, and knowledge sharing is the only way to go beyond the obvious and ordinary. Continuously challenging assumptions that are based on ordinary thinking—what is obvious—is the first step toward experimentation that leads to discovery. • Thinking like a product company is not wrong for any business. Many busi- nesses sell nontechnology products. When businesses invest in software as products, that adds a new dimension in quality and elicits motivations to improve through clear customer-based revenue goals rather than the internal desire for endless pet features. If a business is not there yet, it’s time to get unstuck. Chapter 2: Essential Strategic Learning Tools SpaceX would not have been successful as quickly as it was, or possibly not ever, unless team members allowed themselves to crash rockets in an effort to learn quickly. Crashing rockets is a lot more expensive than rapidly failing software experiments. The SpaceX outcome led to market domination. • Put business initiatives before software architecture and technical platforms. Tell potential customers that the software they should use sports a Microser- vices architecture or runs in the cloud, and that message will likely be received with blank stares. Users don’t care about Microservices or the cloud; they care about outcomes. • The quickest way to deliver the best outcomes for users is by driving in the straightest possible lines of incremental improvement. Select from the best service-level architecture and deployment options based on full knowledge of need and purpose.
- 42. E S 5 • Experiments fail, and failure is not a bad thing. Every fast failure results in rapid learning. Employ an engineering model that depends on an experimen- tation mindset, not a contractor model that freezes in the face of the unknown. • Embrace failure culture, but understand that failure culture is not blame cul- ture. Innovation is difficult enough without troubling the vulnerable scientific minds with threats of reprisals for tiptoeing on the razor’s edge. When con- trolled failures lead to success, those failures look like the red carpet leading to a pot of gold. • Recognizing the business capabilities of the business enterprise is a sound way to see where investing in strategic software initiatives matters most. Don’t build what you can buy or download for free, because these solutions are generic and non-differentiating, and often complex to implement. Your busi- ness is defined by its core capabilities and will deliver value if given proper focus and investment. Chapter 3: Events-First Experimentation and Discovery How can the broad range of personality types overcome communication challenges to achieve deep dives into collaborative communication, learning, experimentation- and discovery-based innovation, and improved software construction? • Don’t segregate the extroverts and the introverts. Pushing business and tech- nical minds in separate directions will lead to software that reflects that intentional segregation. It won’t be fulfilling—more so the polar opposite. Find ways to bring the two mindsets together with an unending drive toward discovery-based innovation. The “ways” are introduced in Chapter 3 and fur- ther explored in Part 2. • “Events-first” might sound foreign or even intimidating. It need not be. Considering that nearly everything (and possibly everything) in everyday life is done due to events that stimulate our reactions. In software, events are records of things that have happened and that cause additional things to hap- pen in response. Focusing on events as a learning and discovery tool is first- rate experience in experimentation. • Experimentation is effective when your organization is iterating quickly by means of rapid learning tools. Rapid learning requires collaborative commu- nication between business and technical experts. These fundamental skills
- 43. P I T S L E 6 are enhanced with lightweight modeling tools that are as expensive as paper and pens, or the use of free online collaboration tools. • Whether in-person or remote, or a hybrid experimentation session of mixed in-person and remote participants, inexpensive and free tools are available to support a lightweight, exploratory activity, known as EventStorming. The important detail is to make sure that the session includes both business and technical experts who can answer the obvious questions and are willing to challenge the ordinary. Prepare for a potentially new way of thinking. Computing and software are no longer ways to avoid repetitive, manual, paper-based tasks. That thinking is at least 30 years behind the curve. Don’t treat software as a cost center. Today’s thinking seeks to deliver software that changes everything, as a new era of business emerges in every industry. Promote software to a profit center, and demand strategic innova- tion as the only acceptable results.
- 44. 7 Chapter 1 Business Goals and Digital Transformation The most outstanding business achievement is to create a product that is needed by a great number of consumers, is completely unique, and is optimally priced. Historically, and in a general sense, the realization of such an accomplishment has depended on the ability to identify what is essential or highly desirable for a key market demographic. This is reflected in a maxim captured by the writings of Plato: “Our need will be the real creator.” Today, this statement is better known as “Necessity is the mother of invention.” Yet, the most profound innovators are those who invent an ingenious product even before consumers realize it is needed. Such achievements have occurred seren- dipitously, but have also been born from those daring enough to ask, “Why not?”1 Perhaps mathematician and philosopher Alfred North Whitehead struck on this notion when he argued that “the basis of invention is science, and science is almost wholly the outgrowth of pleasurable intellectual curiosity” [ANW]. Of course, the vast majority of businesses face a stark reality: Breakthroughs in product development that lead to far-reaching market impact aren’t an everyday happening. Inventing entirely unique products that capture whole markets might seem as likely as aiming at nothing and hitting the center of a pot of gold. As a result, the predominant business plan is to create competition. The unique- ness is seen in pricing the replica rather than in creating the original. Hitting such a large target is entirely ordinary and lacking in imagination and is not even a sure means of success. If creating (more) competition seems to be the best play, consider Steve Jobs’s advice: “You can’t look at the competition and say you’re going to do it better. You have to look at the competition and say you’re going to do it differently.” 1. (George) Bernard Shaw: “Some men see things as they are and ask why. Others dream things that never were and ask why not.”
- 45. C 1 B G D T 8 SpaceX Innovation Between the years 1970 and 2000, the cost to launch a kilogram to space aver- aged $18,500 US per kilogram. For a SpaceX Falcon 9, the cost is just $2,720 per kilogram. That’s a factor of 7:1 improvement, and so it’s no secret why SpaceX has almost all of the space launch business these days. How did they do it? What they did not do was work under contract to the government—that is, the only funding mechanism up until then. Their goal was to dramatically reduce the cost to launch stuff into space. Their main sub-goal under that was to recover and reuse booster rockets. There’s a wonderful YouTube video of all the boosters they crashed in order to achieve their goal. The strategy of integrating events (in this case, test booster launches) is how multiple engi- neering teams rapidly try out their latest version with all the other teams. Government contracts would never have tolerated the crashes that SpaceX suffered. Yet, the crashes speeded up the development of a reliable, cheap booster rocket by perhaps a factor of 5, simply by trying things out to discover the unknown unknowns, instead of trying to think everything through in excruciating detail. That is a pretty classic engineering approach, but would never be allowed in a contracting model. The SpaceX team said it was far cheaper to have crashes and find the problems than to try to wait forever until there was no risk. [Mary Poppendieck] Imitation is not a strategy. Differentiation is. Differentiation is the strategic business goal that must be constantly sought after. If pure invention seems nearly impossible, continuous and tenacious improvement toward innovation should not. In this book, we have undertaken the task of helping readers achieve strategic business differentiation through relentless improvement in digital transformation. Digital Transformation: What Is the Goal? Understanding that the making of the unordinary is a major feat should not dis- suade anyone from taking small, scientific steps with ongoing determination toward actual innovation. No matter the complexity in reaching Z, performing the science of experimentation to arrive at B when starting from A is a realistic expectation. After that, reaching C is doable, which then leads to D. It’s a matter of keeping our lab coat and pocket protector on, and acknowledging that unique products that can capture new markets have likely been staring us in the face all along.
- 46. D T: W I G? 9 Whether Microsoft Office was considered a worker-productivity innovation from the outset, it certainly has been the most successful suite in that market. With Office 365, Microsoft didn’t have to reinvent the word processor and the spread- sheet to innovate. It did, however, add a new delivery mechanism and capabilities to enable full teams to collaborate, among other features. Did Microsoft win yet again by innovating through digital transformation? Digital transformation is left to the eye of the business innovator, but commonly businesses lose sight of the innovation part of transformation. Transformative innovation requires that the business understands the difference between changing infrastructural platforms and building new product value. For example, although taking business digital assets from the on-premises datacenter to the cloud might be an important IT initiative, it is not in itself a business initiative in innovation. Does migrating your software to the cloud qualify as a digital transformation? Possibly, but more so if the move supports future differentiation. It best qualifies if the cloud delivers new opportunities to innovate or at least to unburden the extremely high cost of digital asset operations and channel those funds to new prod- ucts. Think of the cloud as creating opportunities by freeing you from most tradi- tional datacenter responsibilities. It won’t be transformative, however, if the shift to the cloud amounts to trading one set of costs for a different set of costs. Amazon offering its already successful computing infrastructure to the outside world was a digital transformation for the company that resulted in cloud innovation. Paying a subscription to Amazon to use its cloud is not a transformative innovation to the subscriber. The lesson is clear: Innovate or be innovated on. Just as migrating to the cloud is not an innovation, neither is creating a new distrib- uted computing architecture. Users don’t care about distributed computing, Micro- services, or Monoliths, or even features. Users care about outcomes. Improved user outcomes are needed rapidly and without negatively impacting their workflows. For software to stand a chance at meaningful transformation, its architecture and design must support the delivery of better user outcomes as rapidly as possible. When using the cloud, an improved architecture and design approach (and any additional well-tuned steps that lead to productivity gains) make reaching inno- vative transformational goals possible. Using infrastructure as a service frees the business to work on innovative business software rather than churning on trying to innovate on its infrastructure. Not only are infrastructure innovations time- consuming and costly, but they might not benefit the business’s bottom line, and developing infrastructure in-house might never address infrastructure and opera- tional needs as well as AWS, Google Cloud Platform, and Azure. Yet, this is not always the case. For some businesses, it would be much more cost-effective to bring operations in-house or keep them there [a16z-CloudCostParadox]. Remember, it’s A to B, B to C, C to D. . . . Be willing to iterate on any of these steps so that you can learn enough to take the next one. Understanding that going
- 47. C 1 B G D T 10 back from J to G before reaching K is expected, and that Z need not ever happen, is liberating. Teams can innovate, but none of these transformational steps can tol- erate lengthy cycles. Chapter 2, “Essential Strategic Learning Tools,” shows how experimentation is the friend of innovation and the enemy of indecision. Software Architecture Quick Glance This section introduces the term software architecture—a term that is referred to often herein. It’s a rather broad topic that is covered in more detail throughout this book. For now, think of software architecture as similar to building architecture. A building has structure, and it reflects the results of communication that has taken place between the architect and the owner regarding the design features, by pro- viding the features as specified. A building forms a whole system of various sub- systems, each of which has its own specific purpose and role. These subsystems are all loosely or more tightly connected with other parts of the building, working sep- arately or in conjunction with others to make the building serve its purpose. For example, a building’s air conditioning requires electrical power, duct work, a ther- mostat, insulation, and even a closed area of the building to cool, if that subsystem is to be effective. Likewise, a software architecture provides structural design—that is, the for- mulation of many structures, not one. The structural design organizes the system components, affording them the means to communicate as they work together. The structure also serves to segregate clusters of components so they can function inde- pendently. The structures must, therefore, help achieve quality attributes rather than functional ones, while the components within implement the functionality specified by teams of system builders. Figure 1.1 illustrates two subsystems (showing only a fragment of a whole system), each having components that work together internally but in isolation from the other subsystem. The two subsystems exchange information through a communication channel, with the box in between representing the information that is exchanged. Assume that these two subsystems are physically separated into two deployment units, and communicate via a network. This forms a portion of a distributed system. Figure 1.1 A software architecture provides structure within subsystems and supports communication between them.
- 48. W S G W 11 Another important aspect of both building and software architecture is that they must support inevitable change. If existing components fail to meet new demands in either architecture, they must be replaceable without extreme cost or effort. The architecture must also be able to accommodate possible needed expansion, again without major impact to the overall architecture. Why Software Goes Wrong We don’t want to overstate the seriousness of the poor state of enterprise software development, and we don’t think it can be overstated. When discussing enterprise software system conditions with Fortune and Global companies, we quickly learn about their major pain points. These are always related to aged software that has undergone decades of maintenance, long after innova- tion took place. Most discussions identify that software development is considered a cost center to the business, which makes it that much more difficult to invest in improvements. Today, however, software should be a profit center. Unfortunately, the collective corporate mindset is stuck 30-plus years back when software was meant to make some operations work faster than manual labor. A specific application (or subsystem) starts with a core business reason to be built. Over time, its core purpose will be enhanced or even altered considerably. Continuous additions of features can become so extensive that the application’s original purpose is lost and it likely means different things to different business functions, with the full diversity of those understandings not readily known. This often leads to many hands stirring the pot. Eventually the urgent development tran- sitions from strategic to keeping the software running by fixing urgent bugs and patching data directly in the database in an effort to compensate for failures. New features are generally added slowly and gingerly in an attempt to avoid producing even more bugs. Even so, injecting new bugs is inevitable: With the ever-increasing level of system disorder and lost historical perspective, it’s impossible to determine the full impact a single given change will have on the greater body of software. Teams admit that there is no clear and intentional expression of software archi- tecture, either in individual applications (subsystems) or even overall in any large system. Where some sense of architecture exists, it is generally brittle and obsolete given advances in hardware design and operational environments such as the cloud. Software design is also unintentional, and thus appears to be nonexistent. In conse- quence, most ideas behind an implementation are implicit, committed to the mem- ories of a few people who worked on it. Both architecture and design are by and large ad hoc and just plain weird. These unrecognized failures make for some really sloppy results due to slipshod work.
- 49. C 1 B G D T 12 Just as dangerous as producing no well-defined architecture at all is intro- ducing architecture for merely technical reasons. A fascination often exists among software architects and developers with regard to a novel development style rela- tive to what they previously employed, or even a newly named software tool that is the subject of a lot of hype and industry buzz. This generally introduces accidental complexity2 because the IT professionals don’t fully understand what impacts their ill-advised decisions will have on the overall system, including its execution environ- ment and operations. Yes, Microservices architecture and tools such as Kubernetes, although duly applicable in the proper context, drive a lot of unqualified adoption. Unfortunately, such adoption is rarely driven by insights into business needs. The prolonged buildup of software model inaccuracies within the system from failure to perform urgent changes is described as the debt metaphor. In contrast, the accumulation from accepting uncontrolled changes to a system is known as soft- ware entropy. Both are worth a closer look. Debt Metaphor Decades ago, a very smart software developer, Ward Cunningham, who was at the time working on financial software, needed to explain to his boss why the current efforts directed toward software change were necessary [Cunningham]. The changes being made were not in any way ad hoc; in fact, they were quite the opposite. The kinds of changes being made would make it look as if the software developers had known all along what they were doing, and serve to make it look like it was easy to do. The specific technique they used is now known as software refactoring. In this case, the refactoring was done in the way it was meant to be implemented—that is, to reflect the acquisition of new business knowledge into the software model. To justify this work, Cunningham needed to explain that if the team didn’t make adjustments to the software to match their increased learning about the problem domain, they would continue to stumble over the disagreement between the soft- ware that existed and their current, refined understanding. In turn, the continued stumbling would slow down the team’s progress on continued development, which is like paying interest on a loan. Thus, the debt metaphor was born. Anyone can borrow money to enable them to do things sooner than if they hadn’t obtained the money. Of course, as long as the loan exists, the borrower will be 2. Accidental complexity is caused by developers trying to solve problems, and can be fixed. There is also essential complexity inherent in some software, which is caused by the problems being solved. Although essential complexity cannot be avoided, it can often be isolated in subsystems and components specifically designed to tackle them.
- 50. W S G W 13 paying interest. The primary idea in taking on debt in the software is to be able to release sooner, but with the idea that you must pay the debt sooner rather than later. The debt is paid by refactoring the software to reflect the team’s newly acquired knowledge of the business needs. In the industry at that time, just as it is today, soft- ware was rushed out to users knowing that debt existed, but too often teams had the idea that you never have to pay off the debt. Of course, we all know what happens next. If debt continues to stack up and the person borrows more and more, all the borrower’s money goes to paying interest and they reach a point where they have zero buying power. Matters work the same way with software debt, because eventually developers deep in debt will be severely compromised. Adding new features will take longer and longer, to the point where the team will make almost no progress. One of the major problems with the contemporary understanding of the debt metaphor is that many developers think this metaphor supports deliberately deliv- ering poorly designed and implemented software so as to deliver sooner. Yet, the metaphor doesn’t support that practice. Attempting that feat is more like borrowing on subprime loans3 with upward adjustable interest rates, which often results in the borrower becoming financially overextended to the point of defaulting. Debt is use- ful only as long as it is controlled; otherwise, it creates instability within the entire system. Software Entropy Software entropy4 is a different metaphor but closely related to the debt metaphor in terms of the software system conditions it describes. The word entropy is used in statistical mechanics in the field of thermodynamics to measure a system’s disor- der. Without attempting to go too deep into this topic: “The second law of thermo- dynamics states that the entropy of an isolated system never decreases over time. Isolated systems spontaneously evolve towards thermodynamic equilibrium, the state with maximum entropy” [Entropy]. The software entropy metaphor names the condition of a software system where change is inevitable, and that change will cause increasing uncontrolled complexity unless a vigorous effort is made to pre- vent it [Jacobson]. 3. It’s difficult to comprehend that some are unfamiliar with the 2008 financial crisis that extended years into the future. This (ultimately global) crisis was triggered by subprime lending to unqual- ified borrowers for home purchases. Some early readers of the manuscript for this book asked, “What is a subprime loan?” Learning about that history could save those readers from a lot of financial grief. 4. Other analogs besides entropy also paint a vivid picture of the problem, such as software rot, software erosion, and software decay. The authors mostly use entropy.
- 51. C 1 B G D T 14 Big Ball of Mud An application or system like the one previously described has become known as a Big Ball of Mud. In terms of architecture, it has been further described as haphazardly structured; sprawling; sloppy; duct-taped-and-baling-wired; jungle; unregulated growth; repeated, expedient repair. “Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated. The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recognition” [BBoM]. It seems appropriate to describe the Big Ball of Mud “architecture” as the unarchitecture. Throughout the remainder of this chapter, as well as in this book in general, we will key in on a few of these characteristics: haphazardly structured; unregulated growth; repeated, expedient repair; information shared promiscuously; all import- ant information global or duplicated. An enterprise norm of the Big Ball of Mud results in organizations experiencing competitive paralysis, which has spread across business industries. It is quite com- mon for large enterprises, which once enjoyed competitive distinction, to become hamstrung by systems with deep debt and nearly complete entropy. You can easily contrast the Big Ball of Mud system in Figure 1.2 to that depicted in Figure 1.1. Of course, the segment of the system in Figure 1.1 doesn’t represent the number of features that are supported by the system in Figure 1.2, but clearly the architecture of the first system brings order, whereas the lack thereof in the second offers chaos. Figure 1.2 The Big Ball of Mud might be classified as the unarchitecture.
- 52. W S G W 15 These chaotic conditions prevent more than a few software releases per year, which result in even worse problems than the software releases of previous years. Individuals and the teams to which they belong tend to become indifferent and com- placent because they know they can’t produce the change they see as necessary to turn things around. The next level from there is becoming disillusioned and demor- alized. Businesses facing this situation cannot innovate in software and continue to compete under such conditions. Eventually they fall victim to a nimble startup that can make significant strides forward, to the point where within a few months to a few years, it can displace previous market leaders. Running Example From this point forward, we present a case study using an existing Big Ball of Mud and describe a situation where the affected business struggles to innovate as it faces the realities of the associated deep debt and entropy. Because you might already be tired of reading bad news, here’s a spoiler: The situation improves over time. There is no better way to explain the issues every company has to face with soft- ware development than with examples borrowed from the real world. The example offered here as a case study in dealing with an existing Big Ball of Mud comes from the insurance industry. At some point in life, just about everyone has to deal with an insurance company. There are various reasons why people seek to obtain diverse insurance policies. Some are to address legal requirements, and some provide security measures for the future. These policies include protection for health, personal lines such as life, automobile, home, mortgage, financial products investments, international travel, and even the loss of a favorite set of golf clubs. Policy product innovation in the field of insurance seems endless, where almost any risk imaginable can be covered. If there is a potential risk, you’re likely to find an insurance company that will provide coverage for it. The basic idea behind insurance is that some person or thing is at risk of loss, and for a fee, the calculated financial value of the insured person or thing may be recovered when such loss occurs. Insurance is a successful business proposition due to the law of large numbers. This law says that given a large number of persons and things being covered for risks, the overall risk of loss among all of those covered persons and things is quite small, so the fees paid by all will be far greater than the actual payments made for losses. Also, the greater the probability of loss, the greater the fee that the insurance company will receive to provide coverage. Imagine the complexity of the insurance domain. Is coverage for automobiles and homes the same? Does adjusting a few business rules that apply to automo- biles make covering homes possible? Even if automobile and home policies might
- 53. C 1 B G D T 16 be considered “close enough” to hold a lot in common, think of the different risks involved in these two policy types. Consider some example scenarios. There is a much higher possibility of an automobile striking another automobile than there is of a part of a house striking another house and causing damage. The likelihood of a fire occurring in a kitchen due to normal everyday use is greater than the likelihood of the car’s engine catch- ing fire due to normal everyday use. As we can see, the difference between the two kinds of insurance isn’t subtle. When considering the variety of possible kinds of coverage, it requires substantial investment to provide policies that have value to those facing risk and that won’t be a losing proposition to the insurance company. Thus, it’s understandable that the complexity among insurance firms in terms of business strategy, operations, and software development is considerable. That is why insurance companies tend to specialize in a small subset of insurable prod- ucts. It’s not that they wouldn’t want to be a larger player in the market, but rather that costs could easily outweigh the benefits of competing in all possible segments. It’s not surprising, then, that insurance companies more often attempt to lead in insurance products in which they have already earned expertise. Even so, adjusting business strategies, accepting unfamiliar yet measured risks, and developing new products might be too lucrative an opportunity to pass up. It is time to introduce NuCoverage Insurance. This fictitious company is based on real-world scenarios previously experienced by the authors. NuCoverage has become the leader in low-cost auto insurance in the United States. The company was founded in 2001 with a business plan to focus on providing lower-cost premi- ums for safe drivers. It saw a clear opportunity in focusing on this specific market, and it succeeded. The success came from the company’s ability to assess risks and premiums very accurately and offer the lowest-cost policies on the market. Almost 20 years later, the company is insuring 23% of the overall US market, but nearly 70% in the specialized lower-cost safe-driver market. Current Business Context Although NuCoverage is a leader in auto insurance, it would like to expand its business to other kinds of insurance products. The company has recently added home insurance and is working on adding personal lines of insurance. However, adding new insurance products became more complex than was originally perceived. While the development process of personal lines of insurance was ongoing, man- agement had an opportunity to sign a partnership with one of the largest US banks, WellBank. The deal involves enabling WellBank to sell auto insurance under its own brand. WellBank sees great potential in selling auto insurance along with its famil- iar auto loans. Behind the WellBank auto insurance policies is NuCoverage.
- 54. W S G W 17 Of course, there are differences between NuCoverage auto insurance products and the ones to be sold by WellBank. The most prominent differences relate to the following areas: • Premiums and coverages • Rules and premium price calculation • Risk assessment Although NuCoverage has never before experienced this kind of partnership, the business leaders immediately saw the potential to expand their reach, and possibly even introduce a completely new and innovative business strategy. But in what form? Business Opportunity NuCoverage’s board of directors and executives recognized an even larger strategic opportunity than the WellBank partnership: They could introduce a white-label5 insurance platform that would support any number of fledgling insurers. Many types of businesses might potentially support selling insurance products under the busi- ness’s own brand. Each business best knows its customers and grasps what insur- ance products could be offered. The recently inked partnership with WellBank is just one example. NuCoverage can certainly identify other forward-thinking part- ners that would share the vision of selling insurance products under a white label. For example, NuCoverage could establish partnerships with car makers that offer their own financing. When a customer purchases a car, the dealer could offer both financing and manufacturer-branded insurance. The possibilities are endless, due to the fact that any random company cannot easily become an insurance com- pany, but can still benefit from the margins gained through insurance sales. In the long run, NuCoverage considered diversifying with new insurance products such as motorcycle, yacht, and even pet insurance. This possibility seems very exciting to the board and executives, but when the software management team learned about the plans, a few of them had to swallow hard. The original auto insurance application was built quickly under a lot of pressure to deliver, which quickly led to a Big Ball of Mud Monolith. As Figure 1.3 illustrates, with more than 20 years of changes and deep unpaid debt, and the ongoing devel- opment of the system for the personal lines of insurance, the teams have reached a point of stifling unplanned complexity. The existing software will absolutely not support current business goals. All the same, development needs to answer the call. 5. A white-label product is a product or service produced by one company (the producer) that other companies (the marketers) rebrand to make it appear as if they had made it.
- 55. Random documents with unrelated content Scribd suggests to you:
- 56. KASHTANKA (A Story) I |Misbehaviour A YOUNG dog, a reddish mongrel, between a dachshund and a “yard-dog,” very like a fox in face, was running up and down the pavement looking uneasily from side to side. From time to time she stopped and, whining and lifting first one chilled paw and then another, tried to make up her mind how it could have happened that she was lost. She remembered very well how she had passed the day, and how, in the end, she had found herself on this unfamiliar pavement. The day had begun by her master Luka Alexandritch’s putting on his hat, taking something wooden under his arm wrapped up in a red handkerchief, and calling: “Kashtanka, come along!” Hearing her name the mongrel had come out from under the work-table, where she slept on the shavings, stretched herself voluptuously and run after her master. The people Luka Alexandritch worked for lived a very long way off, so that, before he could get to any one of them, the carpenter had several times to step into a tavern to fortify himself. Kashtanka remembered that on the way she had behaved extremely improperly. In her delight that she was being taken for a walk she jumped about, dashed barking after the trains, ran into yards, and chased other dogs. The carpenter was continually losing sight of her, stopping, and angrily shouting at her. Once he had even, with an expression of fury in his face, taken her
- 57. fox-like ear in his fist, smacked her, and said emphatically: “Pla-a- ague take you, you pest!” After having left the work where it had been bespoken, Luka Alexandritch went into his sister’s and there had something to eat and drink; from his sister’s he had gone to see a bookbinder he knew; from the bookbinder’s to a tavern, from the tavern to another crony’s, and so on. In short, by the time Kashtanka found herself on the unfamiliar pavement, it was getting dusk, and the carpenter was as drunk as a cobbler. He was waving his arms and, breathing heavily, muttered: “In sin my mother bore me! Ah, sins, sins! Here now we are walking along the street and looking at the street lamps, but when we die, we shall burn in a fiery Gehenna. . . .” Or he fell into a good-natured tone, called Kashtanka to him, and said to her: “You, Kashtanka, are an insect of a creature, and nothing else. Beside a man, you are much the same as a joiner beside a cabinet-maker. . . .” While he talked to her in that way, there was suddenly a burst of music. Kashtanka looked round and saw that a regiment of soldiers was coming straight towards her. Unable to endure the music, which unhinged her nerves, she turned round and round and wailed. To her great surprise, the carpenter, instead of being frightened, whining and barking, gave a broad grin, drew himself up to attention, and saluted with all his five fingers. Seeing that her master did not protest, Kashtanka whined louder than ever, and dashed across the road to the opposite pavement. When she recovered herself, the band was not playing and the regiment was no longer there. She ran across the road to the spot where she had left her master, but alas, the carpenter was no longer there. She dashed forward, then back again and ran across the road once more, but the carpenter seemed to have vanished into the earth. Kashtanka began sniffing the pavement, hoping to find her
- 58. master by the scent of his tracks, but some wretch had been that way just before in new rubber goloshes, and now all delicate scents were mixed with an acute stench of india-rubber, so that it was impossible to make out anything. Kashtanka ran up and down and did not find her master, and meanwhile it had got dark. The street lamps were lighted on both sides of the road, and lights appeared in the windows. Big, fluffy snowflakes were falling and painting white the pavement, the horses’ backs and the cabmen’s caps, and the darker the evening grew the whiter were all these objects. Unknown customers kept walking incessantly to and fro, obstructing her field of vision and shoving against her with their feet. (All mankind Kashtanka divided into two uneven parts: masters and customers; between them there was an essential difference: the first had the right to beat her, and the second she had the right to nip by the calves of their legs.) These customers were hurrying off somewhere and paid no attention to her. When it got quite dark, Kashtanka was overcome by despair and horror. She huddled up in an entrance and began whining piteously. The long day’s journeying with Luka Alexandritch had exhausted her, her ears and her paws were freezing, and, what was more, she was terribly hungry. Only twice in the whole day had she tasted a morsel: she had eaten a little paste at the bookbinder’s, and in one of the taverns she had found a sausage skin on the floor, near the counter —that was all. If she had been a human being she would have certainly thought: “No, it is impossible to live like this! I must shoot myself!” II |A Mysterious Stranger But she thought of nothing, she simply whined. When her head and back were entirely plastered over with the soft feathery snow,
- 59. and she had sunk into a painful doze of exhaustion, all at once the door of the entrance clicked, creaked, and struck her on the side. She jumped up. A man belonging to the class of customers came out. As Kashtanka whined and got under his feet, he could not help noticing her. He bent down to her and asked: “Doggy, where do you come from? Have I hurt you? O, poor thing, poor thing. . . . Come, don’t be cross, don’t be cross. . . . I am sorry.” Kashtanka looked at the stranger through the snow-flakes that hung on her eyelashes, and saw before her a short, fat little man, with a plump, shaven face wearing a top hat and a fur coat that swung open. “What are you whining for?” he went on, knocking the snow off her back with his fingers. “Where is your master? I suppose you are lost? Ah, poor doggy! What are we going to do now?” Catching in the stranger’s voice a warm, cordial note, Kashtanka licked his hand, and whined still more pitifully. “Oh, you nice funny thing!” said the stranger. “A regular fox! Well, there’s nothing for it, you must come along with me! Perhaps you will be of use for something. . . . Well!” He clicked with his lips, and made a sign to Kashtanka with his hand, which could only mean one thing: “Come along!” Kashtanka went. Not more than half an hour later she was sitting on the floor in a big, light room, and, leaning her head against her side, was looking with tenderness and curiosity at the stranger who was sitting at the table, dining. He ate and threw pieces to her. . . . At first he gave her bread and the green rind of cheese, then a piece of meat, half a pie and chicken bones, while through hunger she ate so quickly that she had not time to distinguish the taste, and the more she ate the more acute was the feeling of hunger.
- 60. “Your masters don’t feed you properly,” said the stranger, seeing with what ferocious greediness she swallowed the morsels without munching them. “And how thin you are! Nothing but skin and bones. . . .” Kashtanka ate a great deal and yet did not satisfy her hunger, but was simply stupefied with eating. After dinner she lay down in the middle of the room, stretched her legs and, conscious of an agreeable weariness all over her body, wagged her tail. While her new master, lounging in an easy-chair, smoked a cigar, she wagged her tail and considered the question, whether it was better at the stranger’s or at the carpenter’s. The stranger’s surroundings were poor and ugly; besides the easy-chairs, the sofa, the lamps and the rugs, there was nothing, and the room seemed empty. At the carpenter’s the whole place was stuffed full of things: he had a table, a bench, a heap of shavings, planes, chisels, saws, a cage with a goldfinch, a basin. . . . The stranger’s room smelt of nothing, while there was always a thick fog in the carpenter’s room, and a glorious smell of glue, varnish, and shavings. On the other hand, the stranger had one great superiority—he gave her a great deal to eat and, to do him full justice, when Kashtanka sat facing the table and looking wistfully at him, he did not once hit or kick her, and did not once shout: “Go away, damned brute!” When he had finished his cigar her new master went out, and a minute later came back holding a little mattress in his hands. “Hey, you dog, come here!” he said, laying the mattress in the corner near the dog. “Lie down here, go to sleep!” Then he put out the lamp and went away. Kashtanka lay down on the mattress and shut her eyes; the sound of a bark rose from the street, and she would have liked to answer it, but all at once she was overcome with unexpected melancholy. She thought of Luka Alexandritch, of his son Fedyushka, and her snug little place under the bench. . . . She remembered on the long winter evenings, when the carpenter was planing or reading the paper aloud, Fedyushka
- 61. usually played with her. . . . He used to pull her from under the bench by her hind legs, and play such tricks with her, that she saw green before her eyes, and ached in every joint. He would make her walk on her hind legs, use her as a bell, that is, shake her violently by the tail so that she squealed and barked, and give her tobacco to sniff . . . . The following trick was particularly agonising: Fedyushka would tie a piece of meat to a thread and give it to Kashtanka, and then, when she had swallowed it he would, with a loud laugh, pull it back again from her stomach, and the more lurid were her memories the more loudly and miserably Kashtanka whined. But soon exhaustion and warmth prevailed over melancholy. She began to fall asleep. Dogs ran by in her imagination: among them a shaggy old poodle, whom she had seen that day in the street with a white patch on his eye and tufts of wool by his nose. Fedyushka ran after the poodle with a chisel in his hand, then all at once he too was covered with shaggy wool, and began merrily barking beside Kashtanka. Kashtanka and he goodnaturedly sniffed each other’s noses and merrily ran down the street. . . . III |New and Very Agreeable Acquaintances When Kashtanka woke up it was already light, and a sound rose from the street, such as only comes in the day-time. There was not a soul in the room. Kashtanka stretched, yawned and, cross and ill- humoured, walked about the room. She sniffed the corners and the furniture, looked into the passage and found nothing of interest there. Besides the door that led into the passage there was another door. After thinking a little Kashtanka scratched on it with both paws, opened it, and went into the adjoining room. Here on the bed, covered with a rug, a customer, in whom she recognised the stranger of yesterday, lay asleep.
- 62. “Rrrrr . . .” she growled, but recollecting yesterday’s dinner, wagged her tail, and began sniffing. She sniffed the stranger’s clothes and boots and thought they smelt of horses. In the bedroom was another door, also closed. Kashtanka scratched at the door, leaned her chest against it, opened it, and was instantly aware of a strange and very suspicious smell. Foreseeing an unpleasant encounter, growling and looking about her, Kashtanka walked into a little room with a dirty wall-paper and drew back in alarm. She saw something surprising and terrible. A grey gander came straight towards her, hissing, with its neck bowed down to the floor and its wings outspread. Not far from him, on a little mattress, lay a white tom-cat; seeing Kashtanka, he jumped up, arched his back, wagged his tail with his hair standing on end and he, too, hissed at her. The dog was frightened in earnest, but not caring to betray her alarm, began barking loudly and dashed at the cat . . . . The cat arched his back more than ever, mewed and gave Kashtanka a smack on the head with his paw. Kashtanka jumped back, squatted on all four paws, and craning her nose towards the cat, went off into loud, shrill barks; meanwhile the gander came up behind and gave her a painful peck in the back. Kashtanka leapt up and dashed at the gander. “What’s this?” They heard a loud angry voice, and the stranger came into the room in his dressing-gown, with a cigar between his teeth. “What’s the meaning of this? To your places!” He went up to the cat, flicked him on his arched back, and said: “Fyodor Timofeyitch, what’s the meaning of this? Have you got up a fight? Ah, you old rascal! Lie down!” And turning to the gander he shouted: “Ivan Ivanitch, go home!” The cat obediently lay down on his mattress and closed his eyes. Judging from the expression of his face and whiskers, he was displeased with himself for having lost his temper and got into a fight.
- 63. Kashtanka began whining resentfully, while the gander craned his neck and began saying something rapidly, excitedly, distinctly, but quite unintelligibly. “All right, all right,” said his master, yawning. “You must live in peace and friendship.” He stroked Kashtanka and went on: “And you, redhair, don’t be frightened. . . . They are capital company, they won’t annoy you. Stay, what are we to call you? You can’t go on without a name, my dear.” The stranger thought a moment and said: “I tell you what . . . you shall be Auntie. . . . Do you understand? Auntie!” And repeating the word “Auntie” several times he went out. Kashtanka sat down and began watching. The cat sat motionless on his little mattress, and pretended to be asleep. The gander, craning his neck and stamping, went on talking rapidly and excitedly about something. Apparently it was a very clever gander; after every long tirade, he always stepped back with an air of wonder and made a show of being highly delighted with his own speech. . . . Listening to him and answering “R-r-r-r,” Kashtanka fell to sniffing the corners. In one of the corners she found a little trough in which she saw some soaked peas and a sop of rye crusts. She tried the peas; they were not nice; she tried the sopped bread and began eating it. The gander was not at all offended that the strange dog was eating his food, but, on the contrary, talked even more excitedly, and to show his confidence went to the trough and ate a few peas himself. IV |Marvels on a Hurdle A little while afterwards the stranger came in again, and brought a strange thing with him like a hurdle, or like the figure II. On the crosspiece on the top of this roughly made wooden frame hung a bell, and a pistol was also tied to it; there were strings from the tongue of the bell, and the trigger of the pistol. The stranger put the
- 64. frame in the middle of the room, spent a long time tying and untying something, then looked at the gander and said: “Ivan Ivanitch, if you please!” The gander went up to him and stood in an expectant attitude. “Now then,” said the stranger, “let us begin at the very beginning. First of all, bow and make a curtsey! Look sharp!” Ivan Ivanitch craned his neck, nodded in all directions, and scraped with his foot. “Right. Bravo. . . . Now die!” The gander lay on his back and stuck his legs in the air. After performing a few more similar, unimportant tricks, the stranger suddenly clutched at his head, and assuming an expression of horror, shouted: “Help! Fire! We are burning!” Ivan Ivanitch ran to the frame, took the string in his beak, and set the bell ringing. The stranger was very much pleased. He stroked the gander’s neck and said: “Bravo, Ivan Ivanitch! Now pretend that you are a jeweller selling gold and diamonds. Imagine now that you go to your shop and find thieves there. What would you do in that case?” The gander took the other string in his beak and pulled it, and at once a deafening report was heard. Kashtanka was highly delighted with the bell ringing, and the shot threw her into so much ecstasy that she ran round the frame barking. “Auntie, lie down!” cried the stranger; “be quiet!” Ivan Ivanitch’s task was not ended with the shooting. For a whole hour afterwards the stranger drove the gander round him on a cord, cracking a whip, and the gander had to jump over barriers and through hoops; he had to rear, that is, sit on his tail and wave his
- 65. legs in the air. Kashtanka could not take her eyes off Ivan Ivanitch, wriggled with delight, and several times fell to running after him with shrill barks. After exhausting the gander and himself, the stranger wiped the sweat from his brow and cried: “Marya, fetch Havronya Ivanovna here!” A minute later there was the sound of grunting. Kashtanka growled, assumed a very valiant air, and to be on the safe side, went nearer to the stranger. The door opened, an old woman looked in, and, saying something, led in a black and very ugly sow. Paying no attention to Kashtanka’s growls, the sow lifted up her little hoof and grunted good-humouredly. Apparently it was very agreeable to her to see her master, the cat, and Ivan Ivanitch. When she went up to the cat and gave him a light tap on the stomach with her hoof, and then made some remark to the gander, a great deal of good-nature was expressed in her movements, and the quivering of her tail. Kashtanka realised at once that to growl and bark at such a character was useless. The master took away the frame and cried. “Fyodor Timofeyitch, if you please!” The cat stretched lazily, and reluctantly, as though performing a duty, went up to the sow. “Come, let us begin with the Egyptian pyramid,” began the master. He spent a long time explaining something, then gave the word of command, “One . . . two . . . three!” At the word “three” Ivan Ivanitch flapped his wings and jumped on to the sow’s back. . . . When, balancing himself with his wings and his neck, he got a firm foothold on the bristly back, Fyodor Timofeyitch listlessly and lazily, with manifest disdain, and with an air of scorning his art and not caring a pin for it, climbed on to the sow’s back, then reluctantly mounted on to the gander, and stood on his hind legs. The result was what the stranger called the Egyptian pyramid. Kashtanka yapped with delight, but at that moment the old cat yawned and,
- 66. losing his balance, rolled off the gander. Ivan Ivanitch lurched and fell off too. The stranger shouted, waved his hands, and began explaining something again. After spending an hour over the pyramid their indefatigable master proceeded to teach Ivan Ivanitch to ride on the cat, then began to teach the cat to smoke, and so on. The lesson ended in the stranger’s wiping the sweat off his brow and going away. Fyodor Timofeyitch gave a disdainful sniff, lay down on his mattress, and closed his eyes; Ivan Ivanitch went to the trough, and the pig was taken away by the old woman. Thanks to the number of her new impressions, Kashranka hardly noticed how the day passed, and in the evening she was installed with her mattress in the room with the dirty wall-paper, and spent the night in the society of Fyodor Timofeyitch and the gander. V |Talent! Talent! A month passed. Kashtanka had grown used to having a nice dinner every evening, and being called Auntie. She had grown used to the stranger too, and to her new companions. Life was comfortable and easy. Every day began in the same way. As a rule, Ivan Ivanitch was the first to wake up, and at once went up to Auntie or to the cat, twisting his neck, and beginning to talk excitedly and persuasively, but, as before, unintelligibly. Sometimes he would crane up his head in the air and utter a long monologue. At first Kashtanka thought he talked so much because he was very clever, but after a little time had passed, she lost all her respect for him; when he went up to her with his long speeches she no longer wagged her tail, but treated him as a tiresome chatterbox, who would not let anyone sleep and, without the slightest ceremony, answered him with “R-r-r-r!”
- 67. Fyodor Timofeyitch was a gentleman of a very different sort. When he woke he did not utter a sound, did not stir, and did not even open his eyes. He would have been glad not to wake, for, as was evident, he was not greatly in love with life. Nothing interested him, he showed an apathetic and nonchalant attitude to everything, he disdained everything and, even while eating his delicious dinner, sniffed contemptuously. When she woke Kashtanka began walking about the room and sniffing the corners. She and the cat were the only ones allowed to go all over the flat; the gander had not the right to cross the threshold of the room with the dirty wall-paper, and Hayronya Ivanovna lived somewhere in a little outhouse in the yard and made her appearance only during the lessons. Their master got up late, and immediately after drinking his tea began teaching them their tricks. Every day the frame, the whip, and the hoop were brought in, and every day almost the same performance took place. The lesson lasted three or four hours, so that sometimes Fyodor Timofeyitch was so tired that he staggered about like a drunken man, and Ivan Ivanitch opened his beak and breathed heavily, while their master became red in the face and could not mop the sweat from his brow fast enough. The lesson and the dinner made the day very interesting, but the evenings were tedious. As a rule, their master went off somewhere in the evening and took the cat and the gander with him. Left alone, Auntie lay down on her little mattress and began to feel sad. Melancholy crept on her imperceptibly and took possession of her by degrees, as darkness does of a room. It began with the dog’s losing every inclination to bark, to eat, to run about the rooms, and even to look at things; then vague figures, half dogs, half human beings, with countenances attractive, pleasant, but incomprehensible, would appear in her imagination; when they came Auntie wagged her tail, and it seemed to her that she had somewhere, at some time, seen them and loved them. And as she
- 68. dropped asleep, she always felt that those figures smelt of glue, shavings, and varnish. When she had grown quite used to her new life, and from a thin, long mongrel, had changed into a sleek, well-groomed dog, her master looked at her one day before the lesson and said: “It’s high time, Auntie, to get to business. You have kicked up your heels in idleness long enough. I want to make an artiste of you. . . . Do you want to be an artiste?” And he began teaching her various accomplishments. At the first lesson he taught her to stand and walk on her hind legs, which she liked extremely. At the second lesson she had to jump on her hind legs and catch some sugar, which her teacher held high above her head. After that, in the following lessons she danced, ran tied to a cord, howled to music, rang the bell, and fired the pistol, and in a month could successfully replace Fyodor Timofeyitch in the “Egyptian Pyramid.” She learned very eagerly and was pleased with her own success; running with her tongue out on the cord, leaping through the hoop, and riding on old Fyodor Timofeyitch, gave her the greatest enjoyment. She accompanied every successful trick with a shrill, delighted bark, while her teacher wondered, was also delighted, and rubbed his hands. “It’s talent! It’s talent!” he said. “Unquestionable talent! You will certainly be successful!” And Auntie grew so used to the word talent, that every time her master pronounced it, she jumped up as if it had been her name. VI |An Uneasy Night Auntie had a doggy dream that a porter ran after her with a broom, and she woke up in a fright.
- 69. It was quite dark and very stuffy in the room. The fleas were biting. Auntie had never been afraid of darkness before, but now, for some reason, she felt frightened and inclined to bark. Her master heaved a loud sigh in the next room, then soon afterwards the sow grunted in her sty, and then all was still again. When one thinks about eating one’s heart grows lighter, and Auntie began thinking how that day she had stolen the leg of a chicken from Fyodor Timofeyitch, and had hidden it in the drawing-room, between the cupboard and the wall, where there were a great many spiders’ webs and a great deal of dust. Would it not be as well to go now and look whether the chicken leg were still there or not? It was very possible that her master had found it and eaten it. But she must not go out of the room before morning, that was the rule. Auntie shut her eyes to go to sleep as quickly as possible, for she knew by experience that the sooner you go to sleep the sooner the morning comes. But all at once there was a strange scream not far from her which made her start and jump up on all four legs. It was Ivan Ivanitch, and his cry was not babbling and persuasive as usual, but a wild, shrill, unnatural scream like the squeak of a door opening. Unable to distinguish anything in the darkness, and not understanding what was wrong, Auntie felt still more frightened and growled: “R-r-r-r. . . .” Some time passed, as long as it takes to eat a good bone; the scream was not repeated. Little by little Auntie’s uneasiness passed off and she began to doze. She dreamed of two big black dogs with tufts of last year’s coat left on their haunches and sides; they were eating out of a big basin some swill, from which there came a white steam and a most appetising smell; from time to time they looked round at Auntie, showed their teeth and growled: “We are not going to give you any!” But a peasant in a fur-coat ran out of the house and drove them away with a whip; then Auntie went up to the basin and began eating, but as soon as the peasant went out of the gate, the two black dogs rushed at her growling, and all at once there was again a shrill scream.
- 70. “K-gee! K-gee-gee!” cried Ivan Ivanitch. Auntie woke, jumped up and, without leaving her mattress, went off into a yelping bark. It seemed to her that it was not Ivan Ivanitch that was screaming but someone else, and for some reason the sow again grunted in her sty. Then there was the sound of shuffling slippers, and the master came into the room in his dressing-gown with a candle in his hand. The flickering light danced over the dirty wall-paper and the ceiling, and chased away the darkness. Auntie saw that there was no stranger in the room. Ivan Ivanitch was sitting on the floor and was not asleep. His wings were spread out and his beak was open, and altogether he looked as though he were very tired and thirsty. Old Fyodor Timofeyitch was not asleep either. He, too, must have been awakened by the scream. “Ivan Ivanitch, what’s the matter with you?” the master asked the gander. “Why are you screaming? Are you ill?” The gander did not answer. The master touched him on the neck, stroked his back, and said: “You are a queer chap. You don’t sleep yourself, and you don’t let other people. . . .” When the master went out, carrying the candle with him, there was darkness again. Auntie felt frightened. The gander did not scream, but again she fancied that there was some stranger in the room. What was most dreadful was that this stranger could not be bitten, as he was unseen and had no shape. And for some reason she thought that something very bad would certainly happen that night. Fyodor Timofeyitch was uneasy too. Auntie could hear him shifting on his mattress, yawning and shaking his head. Somewhere in the street there was a knocking at a gate and the sow grunted in her sty. Auntie began to whine, stretched out her front-paws and laid her head down upon them. She fancied that in
- 71. the knocking at the gate, in the grunting of the sow, who was for some reason awake, in the darkness and the stillness, there was something as miserable and dreadful as in Ivan Ivanitch’s scream. Everything was in agitation and anxiety, but why? Who was the stranger who could not be seen? Then two dim flashes of green gleamed for a minute near Auntie. It was Fyodor Timofeyitch, for the first time of their whole acquaintance coming up to her. What did he want? Auntie licked his paw, and not asking why he had come, howled softly and on various notes. “K-gee!” cried Ivan Ivanitch, “K-g-ee!” The door opened again and the master came in with a candle. The gander was sitting in the same attitude as before, with his beak open, and his wings spread out, his eyes were closed. “Ivan Ivanitch!” his master called him. The gander did not stir. His master sat down before him on the floor, looked at him in silence for a minute, and said: “Ivan Ivanitch, what is it? Are you dying? Oh, I remember now, I remember!” he cried out, and clutched at his head. “I know why it is! It’s because the horse stepped on you to-day! My God! My God!” Auntie did not understand what her master was saying, but she saw from his face that he, too, was expecting something dreadful. She stretched out her head towards the dark window, where it seemed to her some stranger was looking in, and howled. “He is dying, Auntie!” said her master, and wrung his hands. “Yes, yes, he is dying! Death has come into your room. What are we to do?” Pale and agitated, the master went back into his room, sighing and shaking his head. Auntie was afraid to remain in the darkness, and followed her master into his bedroom. He sat down on the bed and repeated several times: “My God, what’s to be done?”
- 72. Auntie walked about round his feet, and not understanding why she was wretched and why they were all so uneasy, and trying to understand, watched every movement he made. Fyodor Timofeyitch, who rarely left his little mattress, came into the master’s bedroom too, and began rubbing himself against his feet. He shook his head as though he wanted to shake painful thoughts out of it, and kept peeping suspiciously under the bed. The master took a saucer, poured some water from his wash- stand into it, and went to the gander again. “Drink, Ivan Ivanitch!” he said tenderly, setting the saucer before him; “drink, darling.” But Ivan Ivanitch did not stir and did not open his eyes. His master bent his head down to the saucer and dipped his beak into the water, but the gander did not drink, he spread his wings wider than ever, and his head remained lying in the saucer. “No, there’s nothing to be done now,” sighed his master. “It’s all over. Ivan Ivanitch is gone!” And shining drops, such as one sees on the window-pane when it rains, trickled down his cheeks. Not understanding what was the matter, Auntie and Fyodor Timofeyitch snuggled up to him and looked with horror at the gander. “Poor Ivan Ivanitch!” said the master, sighing mournfully. “And I was dreaming I would take you in the spring into the country, and would walk with you on the green grass. Dear creature, my good comrade, you are no more! How shall I do without you now?” It seemed to Auntie that the same thing would happen to her, that is, that she too, there was no knowing why, would close her eyes, stretch out her paws, open her mouth, and everyone would look at her with horror. Apparently the same reflections were passing through the brain of Fyodor Timofeyitch. Never before had the old cat been so morose and gloomy.
- 73. It began to get light, and the unseen stranger who had so frightened Auntie was no longer in the room. When it was quite daylight, the porter came in, took the gander, and carried him away. And soon afterwards the old woman came in and took away the trough. Auntie went into the drawing-room and looked behind the cupboard: her master had not eaten the chicken bone, it was lying in its place among the dust and spiders’ webs. But Auntie felt sad and dreary and wanted to cry. She did not even sniff at the bone, but went under the sofa, sat down there, and began softly whining in a thin voice. VII |An Unsuccessful Début One fine evening the master came into the room with the dirty wall-paper, and, rubbing his hands, said: “Well. . . .” He meant to say something more, but went away without saying it. Auntie, who during her lessons had thoroughly studied his face and intonations, divined that he was agitated, anxious and, she fancied, angry. Soon afterwards he came back and said: “To-day I shall take with me Auntie and F’yodor Timofeyitch. To- day, Auntie, you will take the place of poor Ivan Ivanitch in the ‘Egyptian Pyramid.’ Goodness knows how it will be! Nothing is ready, nothing has been thoroughly studied, there have been few rehearsals! We shall be disgraced, we shall come to grief!” Then he went out again, and a minute later, came back in his fur- coat and top hat. Going up to the cat he took him by the fore-paws and put him inside the front of his coat, while Fyodor Timofeyitch appeared completely unconcerned, and did not even trouble to open
- 74. his eyes. To him it was apparently a matter of absolute indifference whether he remained lying down, or were lifted up by his paws, whether he rested on his mattress or under his master’s fur-coat. “Come along, Auntie,” said her master. Wagging her tail, and understanding nothing, Auntie followed him. A minute later she was sitting in a sledge by her master’s feet and heard him, shrinking with cold and anxiety, mutter to himself: “We shall be disgraced! We shall come to grief!” The sledge stopped at a big strange-looking house, like a soup- ladle turned upside down. The long entrance to this house, with its three glass doors, was lighted up with a dozen brilliant lamps. The doors opened with a resounding noise and, like jaws, swallowed up the people who were moving to and fro at the entrance. There were a great many people, horses, too, often ran up to the entrance, but no dogs were to be seen. The master took Auntie in his arms and thrust her in his coat, where Fyodor Timofeyirch already was. It was dark and stuffy there, but warm. For an instant two green sparks flashed at her; it was the cat, who opened his eyes on being disturbed by his neighbour’s cold rough paws. Auntie licked his ear, and, trying to settle herself as comfortably as possible, moved uneasily, crushed him under her cold paws, and casually poked her head out from under the coat, but at once growled angrily, and tucked it in again. It seemed to her that she had seen a huge, badly lighted room, full of monsters; from behind screens and gratings, which stretched on both sides of the room, horrible faces looked out: faces of horses with horns, with long ears, and one fat, huge countenance with a tail instead of a nose, and two long gnawed bones sticking out of his mouth. The cat mewed huskily under Auntie’s paws, but at that moment the coat was flung open, the master said, “Hop!” and Fyodor Timofeyitch and Auntie jumped to the floor. They were now in a little room with grey plank walls; there was no other furniture in it but a
- 75. little table with a looking-glass on it, a stool, and some rags hung about the corners, and instead of a lamp or candles, there was a bright fan-shaped light attached to a little pipe fixed in the wall. Fyodor Timofeyitch licked his coat which had been ruffled by Auntie, went under the stool, and lay down. Their master, still agitated and rubbing his hands, began undressing. . . . He undressed as he usually did at home when he was preparing to get under the rug, that is, took off everything but his underlinen, then he sat down on the stool, and, looking in the looking-glass, began playing the most surprising tricks with himself. . . . First of all he put on his head a wig, with a parting and with two tufts of hair standing up like horns, then he smeared his face thickly with something white, and over the white colour painted his eyebrows, his moustaches, and red on his cheeks. His antics did not end with that. After smearing his face and neck, he began putting himself into an extraordinary and incongruous costume, such as Auntie had never seen before, either in houses or in the street. Imagine very full trousers, made of chintz covered with big flowers, such as is used in working-class houses for curtains and covering furniture, trousers which buttoned up just under his armpits. One trouser leg was made of brown chintz, the other of bright yellow. Almost lost in these, he then put on a short chintz jacket, with a big scalloped collar, and a gold star on the back, stockings of different colours, and green slippers. Everything seemed going round before Auntie’s eyes and in her soul. The white-faced, sack-like figure smelt like her master, its voice, too, was the familiar master’s voice, but there were moments when Auntie was tortured by doubts, and then she was ready to run away from the parti-coloured figure and to bark. The new place, the fan-shaped light, the smell, the transformation that had taken place in her master—all this aroused in her a vague dread and a foreboding that she would certainly meet with some horror such as the big face with the tail instead of a nose. And then, somewhere through the wall, some hateful band was playing, and from time to time she heard an incomprehensible roar. Only one thing reassured her—that was the imperturbability of Fyodor Timofeyitch. He dozed
- 76. with the utmost tranquillity under the stool, and did not open his eyes even when it was moved. A man in a dress coat and a white waistcoat peeped into the little room and said: “Miss Arabella has just gone on. After her—you.” Their master made no answer. He drew a small box from under the table, sat down, and waited. From his lips and his hands it could be seen that he was agitated, and Auntie could hear how his breathing came in gasps. “Monsieur George, come on!” someone shouted behind the door. Their master got up and crossed himself three times, then took the cat from under the stool and put him in the box. “Come, Auntie,” he said softly. Auntie, who could make nothing out of it, went up to his hands, he kissed her on the head, and put her beside Fyodor Timofeyitch. Then followed darkness. . . . Auntie trampled on the cat, scratched at the walls of the box, and was so frightened that she could not utter a sound, while the box swayed and quivered, as though it were on the waves. . . . “Here we are again!” her master shouted aloud: “here we are again!” Auntie felt that after that shout the box struck against something hard and left off swaying. There was a loud deep roar, someone was being slapped, and that someone, probably the monster with the tail instead of a nose, roared and laughed so loud that the locks of the box trembled. In response to the roar, there came a shrill, squeaky laugh from her master, such as he never laughed at home. “Ha!” he shouted, trying to shout above the roar. “Honoured friends! I have only just come from the station! My granny’s kicked the bucket and left me a fortune! There is something very heavy in
- 77. the box, it must be gold, ha! ha! I bet there’s a million here! We’ll open it and look. . . .” The lock of the box clicked. The bright light dazzled Auntie’s eyes, she jumped out of the box, and, deafened by the roar, ran quickly round her master, and broke into a shrill bark. “Ha!” exclaimed her master. “Uncle Fyodor Timofeyitch! Beloved Aunt, dear relations! The devil take you!” He fell on his stomach on the sand, seized the cat and Auntie, and fell to embracing them. While he held Auntie tight in his arms, she glanced round into the world into which fate had brought her and, impressed by its immensity, was for a minute dumbfounded with amazement and delight, then jumped out of her master’s arms, and to express the intensity of her emotions, whirled round and round on one spot like a top. This new world was big and full of bright light; wherever she looked, on all sides, from floor to ceiling there were faces, faces, faces, and nothing else. “Auntie, I beg you to sit down!” shouted her master. Remembering what that meant, Auntie jumped on to a chair, and sat down. She looked at her master. His eyes looked at her gravely and kindly as always, but his face, especially his mouth and teeth, were made grotesque by a broad immovable grin. He laughed, skipped about, twitched his shoulders, and made a show of being very merry in the presence of the thousands of faces. Auntie believed in his merriment, all at once felt all over her that those thousands of faces were looking at her, lifted up her fox-like head, and howled joyously. “You sit there, Auntie,” her master said to her, “while Uncle and I will dance the Kamarinsky.” Fyodor Timofeyitch stood looking about him indifferently, waiting to be made to do something silly. He danced listlessly, carelessly, sullenly, and one could see from his movements, his tail and his ears, that he had a profound contempt for the crowd, the bright
- 78. light, his master and himself. When he had performed his allotted task, he gave a yawn and sat down. “Now, Auntie!” said her master, “we’ll have first a song, and then a dance, shall we?” He took a pipe out of his pocket, and began playing. Auntie, who could not endure music, began moving uneasily in her chair and howled. A roar of applause rose from all sides. Her master bowed, and when all was still again, went on playing. . . . Just as he took one very high note, someone high up among the audience uttered a loud exclamation: “Auntie!” cried a child’s voice, “why it’s Kashtanka!” “Kashtanka it is!” declared a cracked drunken tenor. “Kashtanka! Strike me dead, Fedyushka, it is Kashtanka. Kashtanka! here!” Someone in the gallery gave a whistle, and two voices, one a boy’s and one a man’s, called loudly: “Kashtanka! Kashtanka!” Auntie started, and looked where the shouting came from. Two faces, one hairy, drunken and grinning, the other chubby, rosy- cheeked and frightened-looking, dazed her eyes as the bright light had dazed them before. . . . She remembered, fell off the chair, struggled on the sand, then jumped up, and with a delighted yap dashed towards those faces. There was a deafening roar, interspersed with whistles and a shrill childish shout: “Kashtanka! Kashtanka!” Auntie leaped over the barrier, then across someone’s shoulders. She found herself in a box: to get into the next tier she had to leap over a high wall. Auntie jumped, but did not jump high enough, and slipped back down the wall. Then she was passed from hand to hand, licked hands and faces, kept mounting higher and higher, and at last got into the gallery. . . . ——
- 79. Half an hour afterwards, Kashtanka was in the street, following the people who smelt of glue and varnish. Luka Alexandritch staggered and instinctively, taught by experience, tried to keep as far from the gutter as possible. “In sin my mother bore me,” he muttered. “And you, Kashtanka, are a thing of little understanding. Beside a man, you are like a joiner beside a cabinetmaker.” Fedyushka walked beside him, wearing his father’s cap. Kashtanka looked at their backs, and it seemed to her that she had been following them for ages, and was glad that there had not been a break for a minute in her life. She remembered the little room with dirty wall-paper, the gander, Fyodor Timofeyitch, the delicious dinners, the lessons, the circus, but all that seemed to her now like a long, tangled, oppressive dream.
- 80. T A CHAMELEON HE police superintendent Otchumyelov is walking across the market square wearing a new overcoat and carrying a parcel under his arm. A red-haired policeman strides after him with a sieve full of confiscated gooseberries in his hands. There is silence all around. Not a soul in the square. . . . The open doors of the shops and taverns look out upon God’s world disconsolately, like hungry mouths; there is not even a beggar near them. “So you bite, you damned brute?” Otchumyelov hears suddenly. “Lads, don’t let him go! Biting is prohibited nowadays! Hold him! ah . . . ah!” There is the sound of a dog yelping. Otchumyelov looks in the direction of the sound and sees a dog, hopping on three legs and looking about her, run out of Pitchugin’s timber-yard. A man in a starched cotton shirt, with his waistcoat unbuttoned, is chasing her. He runs after her, and throwing his body forward falls down and seizes the dog by her hind legs. Once more there is a yelping and a shout of “Don’t let go!” Sleepy countenances are protruded from the shops, and soon a crowd, which seems to have sprung out of the earth, is gathered round the timber-yard. “It looks like a row, your honour . . .” says the policeman. Otchumyelov makes a half turn to the left and strides towards the crowd. He sees the aforementioned man in the unbuttoned waistcoat standing close by the gate of the timber-yard, holding his right hand in the air and displaying a bleeding finger to the crowd. On his half- drunken face there is plainly written: “I’ll pay you out, you rogue!” and indeed the very finger has the look of a flag of victory. In this
- 81. man Otchumyelov recognises Hryukin, the goldsmith. The culprit who has caused the sensation, a white borzoy puppy with a sharp muzzle and a yellow patch on her back, is sitting on the ground with her fore-paws outstretched in the middle of the crowd, trembling all over. There is an expression of misery and terror in her tearful eyes. “What’s it all about?” Otchumyelov inquires, pushing his way through the crowd. “What are you here for? Why are you waving your finger . . . ? Who was it shouted?” “I was walking along here, not interfering with anyone, your honour,” Hryukin begins, coughing into his fist. “I was talking about firewood to Mitry Mitritch, when this low brute for no rhyme or reason bit my finger. . . . You must excuse me, I am a working man. . . . Mine is fine work. I must have damages, for I shan’t be able to use this finger for a week, may be. . . . It’s not even the law, your honour, that one should put up with it from a beast. . . . If everyone is going to be bitten, life won’t be worth living. . . .” “H’m. Very good,” says Otchumyelov sternly, coughing and raising his eyebrows. “Very good. Whose dog is it? I won’t let this pass! I’ll teach them to let their dogs run all over the place! It’s time these gentry were looked after, if they won’t obey the regulations! When he’s fined, the blackguard, I’ll teach him what it means to keep dogs and such stray cattle! I’ll give him a lesson! . . . Yeldyrin,” cries the superintendent, addressing the policeman, “find out whose dog this is and draw up a report! And the dog must be strangled. Without delay! It’s sure to be mad. . . . Whose dog is it, I ask?” “I fancy it’s General Zhigalov’s,” says someone in the crowd. “General Zhigalov’s, h’m. . . . Help me off with my coat, Yeldyrin . . . it’s frightfully hot! It must be a sign of rain. . . . There’s one thing I can’t make out, how it came to bite you?” Otchumyelov turns to Hryukin. “Surely it couldn’t reach your finger. It’s a little dog, and you are a great hulking fellow! You must have scratched your finger
- 82. with a nail, and then the idea struck you to get damages for it. We all know . . . your sort! I know you devils!” “He put a cigarette in her face, your honour, for a joke, and she had the sense to snap at him. . . . He is a nonsensical fellow, your honour!” “That’s a lie, Squinteye! You didn’t see, so why tell lies about it? His honour is a wise gentleman, and will see who is telling lies and who is telling the truth, as in God’s sight. . . . And if I am lying let the court decide. It’s written in the law. . . . We are all equal nowadays. My own brother is in the gendarmes . . . let me tell you. . . .” “Don’t argue!” “No, that’s not the General’s dog,” says the policeman, with profound conviction, “the General hasn’t got one like that. His are mostly setters.” “Do you know that for a fact?” “Yes, your honour.” “I know it, too. The General has valuable dogs, thoroughbred, and this is goodness knows what! No coat, no shape. . . . A low creature. And to keep a dog like that! . . . where’s the sense of it. If a dog like that were to turn up in Petersburg or Moscow, do you know what would happen? They would not worry about the law, they would strangle it in a twinkling! You’ve been injured, Hryukin, and we can’t let the matter drop. . . . We must give them a lesson! It is high time . . . . !” “Yet maybe it is the General’s,” says the policeman, thinking aloud. “It’s not written on its face. . . . I saw one like it the other day in his yard.” “It is the General’s, that’s certain!” says a voice in the crowd.
- 83. “H’m, help me on with my overcoat, Yeldyrin, my lad . . . the wind’s getting up. . . . I am cold. . . . You take it to the General’s, and inquire there. Say I found it and sent it. And tell them not to let it out into the street. . . . It may be a valuable dog, and if every swine goes sticking a cigar in its mouth, it will soon be ruined. A dog is a delicate animal. . . . And you put your hand down, you blockhead. It’s no use your displaying your fool of a finger. It’s your own fault. . . .” “Here comes the General’s cook, ask him. . . Hi, Prohor! Come here, my dear man! Look at this dog. . . . Is it one of yours?” “What an idea! We have never had one like that!” “There’s no need to waste time asking,” says Otchumyelov. “It’s a stray dog! There’s no need to waste time talking about it. . . . Since he says it’s a stray dog, a stray dog it is. . . . It must be destroyed, that’s all about it.” “It is not our dog,” Prohor goes on. “It belongs to the General’s brother, who arrived the other day. Our master does not care for hounds. But his honour is fond of them. . . .” “You don’t say his Excellency’s brother is here? Vladimir Ivanitch?” inquires Otchumyelov, and his whole face beams with an ecstatic smile. “‘Well, I never! And I didn’t know! Has he come on a visit? “Yes.” “Well, I never. . . . He couldn’t stay away from his brother. . . . And there I didn’t know! So this is his honour’s dog? Delighted to hear it. . . . Take it. It’s not a bad pup. . . . A lively creature. . . . Snapped at this fellow’s finger! Ha-ha-ha. . . . Come, why are you shivering? Rrr . . . Rrrr. . . . The rogue’s angry . . . a nice little pup.” Prohor calls the dog, and walks away from the timber-yard with her. The crowd laughs at Hryukin.
- 84. “I’ll make you smart yet!” Otchumyelov threatens him, and wrapping himself in his greatcoat, goes on his way across the square.
- 85. Welcome to our website – the perfect destination for book lovers and knowledge seekers. We believe that every book holds a new world, offering opportunities for learning, discovery, and personal growth. That’s why we are dedicated to bringing you a diverse collection of books, ranging from classic literature and specialized publications to self-development guides and children's books. More than just a book-buying platform, we strive to be a bridge connecting you with timeless cultural and intellectual values. With an elegant, user-friendly interface and a smart search system, you can quickly find the books that best suit your interests. Additionally, our special promotions and home delivery services help you save time and fully enjoy the joy of reading. Join us on a journey of knowledge exploration, passion nurturing, and personal growth every day! ebookbell.com