The document discusses challenges that can arise when migrating a monolithic application to a more modern architecture. It notes that while monolithic applications may have started out small and focused, they often become large and unwieldy over time as new features are added without consideration for maintainability. Migrating such a legacy application is difficult due to issues like tightly coupled code, complex dependencies, and architectural inconsistencies. The document outlines some of the key challenges that would need to be addressed as part of such a migration, such as adopting a multi-tenant architecture, properly separating the application into domains, restructuring data models, and supporting various deployment scenarios."

1. Demonolithing The Monolith?
B
U
L
L
O
C
K
S
!
"Fontainbleau SEPT2011 ext 2" by Mark B. Schlemmer is licensed under CC BY 2.0.

2. Can It Be Done?
A n o f t - b l o g g e d , o f t - p r e s e n te d , o f t - d i s c u s s e d
to p i c i n e n g i n e e r i n g c i r c l e s i s h o w to m i g r a te
a n o r g ’ s l o n g - i n - t h e - to o t h , l e g a c y a p p l i c a t i o n
i n to t h e 2 1 s t c e n t u r y : c l o u d - b a s e d , s t a te l e s s ,
A P I F i r s t , D o m a i n - D r i v e n , N o S Q L , m i c r o -
s e r v i c e s a n d m i c r o - f r o n te n d s , e v e n t - d r i v e n ,
s c a l a b l e , r o b u s t , s e c u r e d . A n y t h i n g e l s e?
I M O I t ’ s a F a i r y T a l e
I o n c e b e l i e v e d i n c r a c k i n g o p e n a m o n o l i t h i c
a p p ’ s c o d e b a s e , s u r g i c a l l y r e v a m p i n g i n
w e l l - d e f i n e d c h u n k s , c r e a t i n g ( te c h n i c a l )
b e a u t y w h e r e n o n e e x i s te d . N o t a n y m o r e . A t
m o s t , i t ’ s p u t t i n g l i p s t i c k o n a p i g : p e r c e i v e d
b e n e f i t s a r e m u te d , f u n d a m e n t a l p r o b l e m s
r e m a i n , R O I u n a c h i e v e d …
a s s u m i n g i t ’s e v e r c o m p l e te d !
"Chateau Fountainbleau" by Marcel 'MadJo' de Jong is licensed under CC BY 2.0.

3. SCOTT SOSNA
W h o A m I ?
D a t a s i t e
W h e r e d e a l s a r e m a d e :
D i g i t a l L e a d e r s i n M e r g e r s
a n d A c q u i s i t i o n s
H o m e
L i v e i n M i n n e s o t a w i t h w i f e
a n d c a t , h a v e 3 s te p -
c h i l d r e n , 7 g r a n d c h i l d r e n .
R u n i n s i d e w a tc h i n g E P L .
T r a v e l
R e v e n g e T r a v e l 2 0 2 2 :
L o n d o n , S c o t l a n d , I c e l a n d ,
C a n a d a , J a p a n , N YC
C o n t a c t
m e @ s c o t t s o s n a .d e v
A r c h i te c t , E n g i n e e r , Te c h L e a d e r , M e n to r , S p e a ke r

4. Where I
Live
M y h o u s e i s f r o m 1 8 8 6 , a n c i e n t b y
M i n n e s o t a s t a n d a r d s … p r o b a b l y
q u a l i f i e s a s n e w h o u s i n g i n L o n d o n !
1950s(?)
London Maps
L o o k i n g a t t r a i n s t a t i o n s l i s te d ,
c o u l d b e a n y w h e r e f r o m 1 9 3 7 to
1 9 6 2 .
Angel,
Islington
T h e R o y a l A g r i c u l t u r e H a l l i s n o w
k n o w n a s B u s i n e s s D e s i g n Ce n t r e

5. DISCLAIMER
T H E O B L I G A T O R Y
V I E W S
T h e v i e w s e x p r e s s e d a r e
m i n e a n d m a y n o t r e f l e c t
t h e v i e w s o f m y e m p l o y e r .
E X P E R I E N C E S
T h e s e v i e w s a r e b a s e d o n
m y e x p e r i e n c e s , n o t y o u r s .
E v e r y s i t u a t i o n i s d i f f e r e n t .
I N T E R P R E T A T I O N
I g u a r a n te e y o u w i l l n o t
a g r e e 1 0 0 % w i t h m e . We
c a n a g r e e to d i s a g r e e .
A C T I O N
I a m n o t r e s p o n s i b l e f o r
a n y a c t i o n t a ke n - o r n o t -
f r o m t h e i n f o p r e s e n te d .
"Vincent Price" by twm1340 is licensed under CC BY-SA 2.0.

6. don’t
tl;dr:

7. DEFINE
IDENTIFY
APPROACH
WRAPUP
What makes (your)
application monolithic
Challenges and
surprises await!
Leadership may not
know the details, but
do know buzzwords!
Question/Answer
Closing Remarks
A
G
E
N
D
A
"Fallingwater"
by
orangejack
is
licensed
under
CC
BY-NC-SA
2.0.
"Detail,
Taliesin,
Frank
Lloyd
Wright,
Architect"
by
sswj
is
licensed
under
CC
BY-NC-ND
2.0.
"Start
your
engine"
by
pobre.ch
is
licensed
under
CC
BY
2.0.

8. “After 10 years, we’re almost
done de-monolithing our
business-critical app.”
< r e d a c t e d > , C h i e f A r c h i t e c t , C T O a n d f r i e n d

9. …and, of course, there’s…

10. Java Development Kit
H e r m a n M e l v i l l e

11. September
2010
Plan B, Jigsaw
moved from J7 to J8
Java Jigsaw History
T h e ( V e r y ) A b r i d g e d V e r s i o n
Tw e l v e y e a r s f r o m i n c e p t i o n to r e l e a s e s h o w s h o w R E A L LY i n v a s i v e a n d d i f f i c u l t i n t r o d u c i n g m o d u l e s i n to
J a v a w a s . M o s t e v e r y t h i n g w a s to u c h e d a n d w i t h o u t ( r e a l l y ) i n c o n v e n i e n c i n g e n g i n e e r s a n d u s e r s .
June 2005
JSR 277 Java Module
System, exploratory
phase starts in
August 2008
September
2012
On The Next Train:
moved from J8 to J9
December
2011
Bringing the big
picture into focus
September
2017
Java 9 Released
July 2014
Phase Two: move
from research to
implementation

12. What makes (your)
application monolithic
DEFINE

13. if (!easy) why ?;
U n i v e r s a l a n g s t , e s p e c i a l l y w i t h
n o n - f u n c t i o n a l r e q u i r e m e n t s -
m u s t b e a n e a s i e r/ b e t te r w a y,
WEB APPS
W e a l l l o v e
M o s t ( a l l ? ) o f u s a r e b u i l d i n g
w e b a p p s - f r o n t - e n d , b a c k- e n d ,
d a t a - o r i t s e c o s y s te m s .

14. MONOLITHIC APPS
C H A R A C T E R I S T I C S O F
N o t w o m o n o l i t h s a r e i d e n t i c a l , b u t l o t s o f c o m m o n a l i t i e s
Tightly-coupled, “isolated”
change has unexpected
impact elsewhere (usually
when deployed in prod).
C O U P L E D
Setup for local development
requires patience and outside
intervention, often hear “Don’t
ask, have no idea why it works.”
F I C K L E
New team members take
months to grok enough to
contribute.
C O M P L E X
Outdated tech, out-of-
support libraries, security-
through-obscurity,
disabled DB integrity, etc.
O M D
Uncontrollable shaking
when tasks assigned, self-
promise to look for new gig
S C A R Y
Single code base, database
model, user interface,
deployment model,
process management, …
S I N G L E
All perceive it as monolithic
- age, appearance, flow;
apps never start as
monolithic, they just don’t
age well.
L E G A C Y
From any angle: code base,
data model, dependencies,
build time, critical fix cycle,
deployment windows.
L A R G E
UI design, terminology, data
types, error handling,
authentication/authorization,
job handling, technologies.
I N C O N S I S T E N T

15. MONOLITH
T y p i c a l L i f e c y c l e
L A T E R R E L E A S E S
The battle is lost, anything and everything is
added without impact analysis: code
maintainability, code extensibility, runtime
performance/scalability, etc., ignored. Just do it!
"What a mess..." by geo462rge is licensed under CC BY-NC-ND 2.0.
F I R S T R E L E A S E
Tiny, compact, functionality well-defined
"Uverse telecom closet Netgear switch" by stevencko is licensed under CC BY-NC-ND 2.0.
E A R L Y R E L E A S E S
Though functionality extended, primary intent
maintained; Engineering challenges Product
on more extreme dreams/desires/whims.
"Cable closet" by sampsyo is licensed under CC BY 2.0.

16. Challenges and
surprises await!
IDENTIFY

17. “Design first, then
code to design.”
R i c h U r b a n , f o r m e r b o s s

18. TENANCY
A multi-tenant application allows the deployment
infrastructure to support multiple customers
simultaneously, without customers realizing it. As
load increases - e.g., new or growing customers -
the infrastructure vertically scales to handle the
additional load. The expense is spread out
between all customers.
Monoliths are often single-tenant, dedicated
deployment infrastructure sized to the max
expected load. Conceptually simpler to
implement, test, secure, but substantially more
expensive to deploy, configure, administer.
Paradigm change challenges the org: engineering,
dev ops, product, finance, sales, etc.
P R O J E C T D E S C R I P T I O N
University of Southern Denmark Student Housing/C.F. Møller Architects

19. Single-Tenant
Monolith
I T ’ S A L R E A D Y B A D
Single-Tenant
Monolith and
Service
I T C A N G E T W O R S E

20. DOMAIN
DISCIPLINE
Whether formally designing or informally breaking
down major business concepts, the end result are
domains for which responsibilities are identified,
functionality assigned, screens created, data
stored, etc.
Over time, maintaining clear delineations between
the domains becomes difficult - subject-matter
experts leave, customers ask for changes, sales
want more to sale - and the time-to-delivery often
doesn’t match the effort required.
P R O J E C T D E S C R I P T I O N

21. Domains for Tech
Conference System
Before the conference, potential topics are
submitted to the conference. These submissions
are reviewed and evaluated and either accepted or
rejected.
The accepted sessions are then assigned to an
appropriate time, length, and room. Attendees
review the the published schedule and attends
what is relevant or interesting.

22. New Domain: Pets
The tech conference is pet-friendly and your
favorite four-legged friend can also attend - as
long as he’s well-behaved. Pets cannot attend the
conference or individual sessions alone, and must
show the appropriate licenses, health permits, etc.
The new domain seems to have substantially
different requirements than the People domain,
though it is associated with it. Proper design
shows that Pets should be a separate domain
within your application.

23. Time-to-Market
Unfortunately, the decision to allow pets was made
too late to implement, so instead the Person
domain is extended to support pets as attendees.
This impacts all implementation aspects: UI/UX,
APIs, data capture, reporting, etc. Because Pets
are an exception to all other People domain usage,
it’s guaranteed you’ll be squashing bugs daily
instead of enjoying the conference!

24. DATA PULL-A-PART
In most cases, monolithic apps persist their
transactional data in a relational database - e.g.,
PostgreSQL, MySQL, Oracle, SQLServer - stored
(hopefully) in a normalized form: the key, the whole
key, nothing but the key.
A well-designed data model simplifies data access
(e.g., SQL DML) and data quality (e.g., foreign keys,
constraints, data types, triggers) at cost of
performance, complexity, and understandability.
What happens to the data when migrating to
microservices?
P R O J E C T D E S C R I P T I O N
"monkey bubble bread" by thethrillstheyyield is licensed under CC BY-ND 2.0.

25. Tech Conference Relational Data Model
25

26. Updated Relational Data Model
26

27. DEPLOYMENT
MODELS
Customers may not be willing or able to use your
cloud offering for multiple reasons: cloud aversion,
security concerns, industry compliance, back-end
integrations behind firewall, control freaks, costs.
Installers for monoliths are well-understood and is
decently easy to do successfully. Conversely, apps
built on microservices and micro-frontends are
more complex to deploy and will challenge a
customer’s IT department.
P R O J E C T D E S C R I P T I O N
"Getting some RAM installed" by Daniel Dionne is licensed under CC BY-SA 2.0.

28. ON-PREMISE CUSTOMERS
H O W T O D E A L W I T H E X I S T I N G
D i f f i c u l t i e s e x i s t w i t h c u s to m e r s l i c e n s e d to r u n o n - p r e m - t h e i r d a t a c e n te r , t h e i r i n te r n a l c l o u d ,
t h e i r c l o u d v e n d o r o f c h o i c e - e s p e c i a l l y w h e n t h e c u s to m e r i s l a r g e a n d i n f l u e n t i a l . T h e r e a r e
p o s s i b l e a p p r o a c h e s … .
STA RT
OVER
Sunset the existing application, new
features only in forked code.
E n d - o f - L i f e
END - O F-LIFE
Fork the original code base and
ensure the features/functionality
remain indistinguishable.
C o n s i s t e n c y
CONSI STEN CY
Shared code based provides multiple
ways to deploy the application.
M u l t i D e p l o y
MULTI
DEPLOY
Fork the original code base and allow
each to evolve naturally, ultimately
resulting in separate products
D i f f e r e n t P a t h
DIFFER ENT
PATH
Only support deployment in manner
of new architecture: Kubernetes,
messaging, cloud, etc.
S i n g l e D e p l o y
SINGL E
DE PLOY
Show leadership that starting over
has the most benefits: engineering
and runtime costs, technology,
support, functionality, etc.
S t a r t O v e r
STA RT
OVE R

29. SHORTCOMINGS
The technical shortcomings of your app directly
affect any effort to refactor or de-monolith it: initial
architecture, implementation decisions, problem
simplification.
Before attempting to de-monolith, you may need
to attack the technical shortcomings to avoid
continuing in re-work. This begs the question: at
what point am I better off starting from scratch?
P R O J E C T D E S C R I P T I O N
"An aerial view of the R.H. Thomson 'Ramps to Nowhere'" by WSDOT

30. TECHNICAL SHORTCOMINGS
F R A M E W O R K S
O u t - o f - f a v o r , n i c h e ,
c u s to m
"Vivaldi
cutters
for
windows
center
2"
by
Kitmondo.com
is
licensed
under
CC
BY
2.0
C U S T O M A U T H
N o I D P, S S O, O A u t h 2 ,
O I D C , S A M L , e tc .
"Carol
Channing
Certi
fi
cate
of
Authenticity"
by
zoomar
is
licensed
under
CC
BY-NC-SA
2.0.
B U S I N E S S L O G I C
E x i s t s i n m u l t i p l e
l a y e r s = =
m a i n t a i n a b i l i t y i s s u e
"CCF
Use
Flows"
by
Rob
Enslin
is
licensed
under
CC
BY
2.0.
S T A T E F U L
T r a n s a c t i o n a l , d o e s n ’ t
s c a l e , p a r a d i g m s h i f t
to m a ke s t a te l e s s
"File:Stateful
ejb
lifecycle
diagram.jpg"
by
Zbyněk
Šlajchrt
is
licensed
under
CC
BY-SA
3.0.

31. TECHNICAL SHORTCOMINGS
T E S T C O V E R A G E
I n s u f f i c i e n t , i n c o r r e c t ,
n o n - e x i s te n t
"Testing
1,
2,
3"
by
alisdair
is
licensed
under
CC
BY
2.0.
R E S O U R C E S
Av a i l a b l e r e s o u r c e s
n o t a l w a y s e n o u g h to
c o m p l e te t a s k s
"THE
PYRA"
by
EL
JOKER
is
licensed
under
CC
BY-NC-ND
2.0.
S K E L E T O N S
To t a l l y u n e x p e c te d
b o m b s h e l l s to d e f u s e
https://terriblerealestateagentphotos.com/post/95654243206
T E C H D E B T
U n p r i o r i t i z e d , i g n o r e d ,
m a n y m u l t i p l e p e r s o n -
y e a r s to a d d r e s s
https://medium.com/the-andela-way/what-technical-debt-is-and-how-its-measured-ff41603005e3

32. “Most of the effort in the
software business goes into
the maintenance of code
that already exists.”
W i e t s e Ve n e m a

33. CH-CH-CHANGES
An app is monolithic, in part, due to its initial
design as well as how enhanced or extended; this
understanding impacts the de-monolithing or
reimplementation to avoid any repeats.
However, the new design may impact more than
just engineering: product, delivery management,
sales, finance, compliance, legal may all be
affected by the upcoming changes.
P R O J E C T D E S C R I P T I O N
"Raspberry Pi lego case" by lsbardel is licensed under CC BY 2.0.

34. Agents of Change
C H - C H - C H A N G E S
T h e m o r e t h i n g s c h a n g e , t h e m o r e t h e n d o n ’ t s t a y t h e s a m e
Te c h n o l o g i e s
Platform-as-a-Service, Languages, Frameworks, NoSQL,
Event Streaming, Containers, Observability, Version Control
D e s i g n P a r a d i g m s
Microservices, API First, Reactive UI, Asynchronous,
deployed-not-released, NFRs
P r o c e s s e s
Empowered teams, Test-driven Development, Pull
Requests, CI/CD, Infrastructure-as-Code, 12-Factor App
S k i l l s
Product, Technical, Security, Compliance, Legal,
Methodology
"Genetics Exhibit, San Jose Tech" by Thomas Hawk is licensed under CC BY-NC 2.0.

35. Leadership may not
know the details, but
do know buzzwords!
APPROACH

36. 36
PALACE OF WESTMINSTER
E S T I M A T E F O R R E N O V A T I N G
2 0 2 2 R e p o r t f r o m H o u s e s o f P a r l i a m e n t R e s to r a t i o n a n d R e n e w a l Pr o g r a m m e
£9.5-19.5 billion, 26-43 years
PA R T I A L D E C A N T
£7-13 billion, 19-28 years
F U L L D E C A N T
£11-22 billion, 46-76 years
C O M M O N S S T AY S
“File:Palace of Westminster, London - Feb 2007.jpg" by Diliff is licens”ed under CC BY-SA 2".5.

37. 37

38. DE-
MONOLITH
INVESTIGATE
DESIGN SOCIALIZE
NEGOTIATE
FROM HERE TO THERE
H O W D O W E G E T
S u c c e s s f u l d e - m o n o l i t h i n g r e q u i r e s a h o l i s t i c p l a n - o f - a t t a c k t h a t c l e a r l y s h o w s t h e p a t h to a
m o d e r n , s e r v i c e - b a s e d a p p l i c a t i o n . A d - h o c o r i n c r e m e n t a l g u a r a n te e s f a i l u r e .

39. INVESTIGATE
Even if you participated in the initial design and
implementation, you should expect to deep-dive
into current-state before contemplating future-
state: business requirements, financial models,
programming patterns, technology assumptions,
deployment models do change over time.
Understanding an application’s form and function
is required before designing a de-monolithing
roadmap. Your increased understanding of the
problem space results in confidence when
identifying strategies, risks, and alternatives.
P R O J E C T D E S C R I P T I O N
"L'entrée du centre Georges Pompidou" by dalbera is licensed under CC BY 2.0.

40. DESIGN
Multiple problem owners, multiple approaches,
multiple pros/cons. Each approach requires
feasibility analysis, stakeholders’ opinions
evaluated. You need a short-list of possible
approaches for stakeholders to review.
Choosing from technical and business concerns to
consider is daunting. Tech stack? Complexity?
Future cost savings? Implementation costs?
Product road map? NFRs? Any possible solution
must be best for business, not engineering.
P R O J E C T D E S C R I P T I O N
"29/52 choice paralysis" by maclauren70 is licensed under CC BY-NC-SA 2.0.

41. SOCIALIZE
Socializing the choices, both formally and
informally, allows you to refine communications as
feedback or opinions are offered. To control the
message requires a consistent, correct, informed
understanding by all involved.
You may overlap design and socialize to get
feedback on the more dramatic options: release a
balloon and see what darts are lobbed. Otherwise,
you risk being surprised - and even undermined -
in front of leadership.
P R O J E C T D E S C R I P T I O N
"Negotiated space" by kevin dooley is licensed under CC BY 2.0.

42. NEGOTIATE
You’ve completed the legwork, now time for
leadership to step up and determine your
company’s future. Be prepared for anything: tech
deep-dives, changed business priorities, additional
financial info, other org changes, It’s all good…
….or is it? Risk-adverse leadership often chooses
evolutionary over revolutionary….which is how your
app became monolithic! Negotiate to address the
risk concerns while still moving forward on the
initial premise (albeit more cautiously).
P R O J E C T D E S C R I P T I O N
"Reflections on the new Machine Age — technology, inequality and the economy" by jurvetson is licensed under CC BY 2.0.

43. CHOOSE PATH
What’s next? Everyone agrees on the problem - or
doesn’t. Leaders decided - or didn’t. The
organization committed - or didn't. Are red flags
appearing that indicates this isn’t going to go as
expected? Be honest with yourself!
It’s great if everything aligns with your design and
that success, while difficult, is achievable. Perhaps
you believe that some slight course-corrections
can be snuck in after small successes. Or, worse-
case, a definite conflagration with no alternatives.
P R O J E C T D E S C R I P T I O N
"You Choose Your Path" by `James Wheeler is licensed under CC BY-NC-SA 2.0.

44. That’s all, folks!
WRAPUP

45. ChatGPT Agrees!

46. GREEN
FIELD
PRODUCT
TECHNOLOGY SECURITY
FINANCIAL
REASONS TO NOT DE-MONOLITH
C A N W E M A K E A C O M P E L L I N G A R G U M E N T ?
Wi t h a t h o r o u g h a n a l y s i s o f t h e p r o b l e m , y o u m a y s h o w t h a t s t a r t i n g o v e r p r o v i d e s m o r e a n d
l o n g e r - te r m b e n e f i t s to y o u r o r g a n i z a t i o n o v e r a t te m p t i n g a d e - m o n o l i t h

47. “This isn’t going to end
the way you think.”
L u k e S k y w a l k e r , S t a r Wa r s : T h e L a s t J e d i

48. email: me@scottsosna.com
Linkedin: in/scott-sosna/
©2023 Scott C Sosna
THANKS!