widely-believed falsehoods
incorrect assumptions
lovingly-endorsed "alternative facts"
mistakes that are all too easy to repeat
"anti-patterns"
"Essentially everyone, ... makes the following assumptions.
"All turn out to be false in the long run and all cause big trouble and painful learning experiences."
... once you know about them, you can avoid them
... "Everyone makes these assumptions"
largely because they're easy to make
and they help us avoid hard truths
and painful realizations/pain points
"Essentially everyone, when they first build an enterprise application, makes the following assumptions. All turn out to be false in the long run and all cause big trouble and painful learning experiences."
New technology is always better than old technology
Enterprise systems are not "distributed systems"
Business logic can and should be centralized
Models can and should be centralized
The system is monolithic
The system is ever finished
Vendors can make problems go away
Enterprise architecture is the same everywhere
Developers need only worry about development problems
"'X' is the future"
"Anybody not using 'X' is going to regret it"
"'X' will change the way we do everything"
something interesting comes around
it feels exciting
we jump on the bandwagon
projects are started around it
after a few years, those projects quietly disappear
or sometimes not so quietly
not all of us
but enough of us to make the rest feel FOMO
and from our perspective, it's those projects that concern us
what is/was wrong with CORBA?
what is/was wrong with OSF/RPC?
what is/was wrong with OBOL?
but that doesn't make it better
the drawbacks are not yet found
(and yes there are always drawbacks)
Java runs most of the world's banks
C runs your computer's operating system
COBOL cashes your paycheck
What is the return-on-investment of doing so?
Keep in mind:
new code must be tested
new code must be bug-for-bug compatible
new code requires deep understanding of the old!
All of this in a new language/framework/platform?
typically enterprise systems have to integrate
even if it's done via batched CSV files
which then means enterprise systems ARE distributed (by definition)
enterprise systems are distributed systems
... and thus vulnerable to the Fallacies of Distributed Computing
"Essentially everyone, when they first build an distributed system, makes the following 10 assumptions. All turn out to be false in the long run and all cause big trouble and painful learning experiences."
The network is reliable
Latency is zero
Bandwidth is infinite
The network is secure
Topology doesn't change
There is one administrator
Transport cost is zero
The network is homogeneous
many businessses are exposing an API
this is an integration scenario
and you need to treat this as an "open distributed system"
it's often complex and beyond simple solutions
we like to centralize it for easy replacement/enhancement
and of course there's the DRY rule
examples:
first name, less than 40 characters
customers have invoices, invoices have an address, etc
where do we enforce this?
database? schema?
middleware layer?
front-end?
answer: it has to be all of them
too far front, we lose security
too far back, we lose responsiveness
not far enough front or back, we lose both
"Be strict in what you send.Be liberal in what you accept."
lots of people want to have a shared model
database model
entity model
XML schema model
... lots of variations
particularly common with DDD-based approaches
think of it as a type system
how big can a number get?
can dates be null?
what does an empty collection look like?
these semantics are crucial
what is a customer?
what is an invoice?
what does an order look like?
and do all the departments agree on this view?
"Schema are relative" --Noah Mendelssohn
all schema are validation tools, not definitions
similarly, models are relative
"Oh, sure, we can make that change; we just have to roll out new APIs..."
Even if you control both ends today...
... tomorrow brings corporate change
"What do you mean, I broke your mission-critical app? Who are you again?"
Remember that databases take on a life of their own, as well; you will not own your database instance (or its schema) after release
Microservices risk adding dependencies, not removing them
Why were microservices "invented"?
Don't mistake organizational design for distributed system design
Parts of your system might be a monolith
... and there's good reasons to do that!
That doesn't mean the whole system is
... even if it all runs on one node
make it explicit which parts are tightly-coupled
ensure those coupled parts evolve atomically
keep the network out of those atoms as much as possible
If the component doesn't straddle the network, it's much easier to control
Ask yourself, "How do we react if the schema and code need to evolve independently?"
Prefer contracts over not shared types
Be strict in what you send, flexible in what you accept (Postel's Maxim)
Can I send you a null here?
Can I send you choose to omit this section?
What happens if the case isn't correct?
The only time a system is "finished" is when the server is shut down, the source code is deleted and the programmers that worked on it are all Terminated--With Extreme Prejudice!
Otherwise, systems will be "reborn" in another project because "we need something that does just what XYZ does, only..."
Even if you've left the company, the code you wrote takes on a life of its own
HTTP/1.0
HTTP/1.1
...
...
...
HTTP/2.0
Create systems with "hook points" that allow future programmers to slip in variation without significant rip-and-tear across the codebase;
Keep designs simple and interface- or protocol-based
Have explicit "axes of variability"
Keep semantics simple
but....
Cloud
Databases
Blockchain
Programming languages (4GLs!)
AI
vendor lock-in
licensing decisions
feature decisions
CORBA is an open standard
SQL is an open standard
OpenDoc (was) an open standard
... standards don't always solve this problem
are you committing to the project?
what happens if the core committers leave or change direction?
not a whole lot better, unless you invest directly into it
solutions
"wide"
context-sensitive
solutions for an enterprise
"wide" to the scope of an org
relevant to a given context
you are not Google
you (very likely) will never become Google
don't solve Google's problems
let Google solve Google's problems
solve the problems of your enterprise
yes, patterns!
which have context, and consequences
and do not have prescriptive solutions
everything is context-relative
data/databases/cloud
network infrastructure
requirements/feature development
administration/operations
emphasis on breaking down silos
focus on value streams
bringing awareness on shipping to prod
how is the system adminstered?
how do we start/restart after an outage?
how do users get added (and permissions set)?
who handles onboarding (and offboarding)?
many dev teams carry pagers (PagerDuty)
but who owns a problem across the board?
who is tracking the bug from service to service?
who is staying in contact with the customer?
what if the bug is due to a disagreement in semantics?
it's not enough to just scope this to teams/services
EVERYBODY HAS MADE THESE MISTAKES
EVERYBODY HAS MADE THESE MISTAKES
Learn from the mistakes
EVERYBODY HAS MADE THESE MISTAKES
Hold design reviews against the fallacies-- Be aggressive in stamping them out
Who is this guy?
Architect, Engineering Manager/Leader, "force multiplier"
Principal -- Neward & Associates
http://www.newardassociates.com
Educative (http://educative.io) Author
Performance Management for Engineering Managers
Author
Professional F# 2.0 (w/Erickson, et al; Wrox, 2010)
Effective Enterprise Java (Addison-Wesley, 2004)
SSCLI Essentials (w/Stutz, et al; OReilly, 2003)
Server-Based Java Programming (Manning, 2000)