"Which tools should I use?"
"Web framework? Testing framework? SQL or NoSQL?"
"Which cloud? How much?"
"Microservices! Nanoservices! Serverless! Monolith!"
"Scripting or functional languages?"
"What's the best DevOps strategy to take?"
"Which patterns?"
"How do I build an architecture that will stand up over time?"
These are questions that hide the One Thing Everybody in This Room Really Wants
In a triangle ABC, where D is a point that lies inside the triangle...
Prove that AD + DB < AC + CB
A well, open at the top, has a diameter of 3 meters. We throw two straight sticks, four and five meters long, into the well. They land in the well, crossing each other. Determine the height at which they cross each other.
A farmer has a rectangular ranch with a perimeter of 110 meters and an area of 700 square meters.
What are the dimensions of the ranch?
A mathematician is challenged by a passer-by to guess the ages of his three sons.
"The product of their ages is 36."
"The sum of their ages is the number of books on that table over there."
"The oldest has blue eyes."
The first three problems came from a junior high (12-14 years') or elementary (10-12 years') school mathematics textbook.
The fourth requires math no more sophisticated than what you learned by third grade, and a bit of deductive reasoning.
Can't solve it? Feeling a bit embarrassed?
You are not alone.
"We have given the ABCD triangle problem to many people, including undergraduate and graduate students, and even full professors in mathematics, engineering, or computer science.
"Fewer than 5% of them solved it within an hour...
"... many of them required several hours...
"... and we witnessed some failures as well."
"the well problem takes less than a minute to solve...
"If you solve it within an hour (!), you'll belong to the elite one percent of the people we tested who managed to get the right answer within that time.
"What's more, everyone we tested had at least an undergraduate degree either in mathematics, engineering or computer science."
(Source: How to Solve It, 2nd Ed)
"We're taught to decompose problems and treat the smaller simpler problems individually. This is wonderful when it works. But complex real-world problems don't often decompose easily or meaningfully.
"What might even be worse, we are spoon fed the solutions to problems, chapter by chapter, never once being forced to think about whether or not the problems we are facing should be solved with the technique just described in our textbook.
"Of course they must! Why else would this problem be in this chapter?!"
"This is the case not just with texts for elementary mathematics but also with most textbooks for university courses.
"The problem and its solution in these books are never far apart."
(Source: How to Solve It, 2nd Ed, p 3-4)
"Real-world problems are difficult to solve, and they are difficult for several reasons:
"The number of possible solutions in the search space is so large as to forbid an exhaustive search for the best answer.
"The problem is so complicated that just to facilitate any answer at all, we have to use such simplified models of the problem that any result is essentially useless.
"The evaluation function that describes the quality of any proposed solution is noisy or varies with time, thereby requiring not just a single solution but an entire series.
"The possible solutions are so heavily constrained that constructing even one feasible answer is difficult, let alone searching for an optimum solution.
"The person solving the problem is inadequately prepared or imagines some psychological barrier that prevents them from discovering a solution."
"áarki tèkchər", noun
building design: the art and science of designing and constructing buildings
building style: a style or fashion of building, especially one that is typical of a period of history or of a particular place
structure of computer system: the design, structure, and behavior of a computer system, microprocessor, or system program, including the characteristics of individual components and how they interact
"--ities": Integrity, Simplicity, Reliability, Extensibility, Maintainability, Modularity, Recoverability, Composability, Parsimony, Scalability, Security, Performability, Longevity
where "right" => "right for this project or system"
in other words, enable "correctness by default"
developers using our architecture "fall naturally into the pit of success"
"The core of strategy work is always the same: discovering the critical factors in a situation and designing a way of coordinating and focusing actions to deal with those factors. ... A good strategy honestly acknowledges the challenges being faced and provides an approach to overcoming them. ... bad strategy covers up its failure to guide by embracing the language of broad goals, ambition, vision, and values."
vision
what is our desired end state?
mission
what gets us there?
execution
how do we get there?
vision
what is our desired end state?
mission
what gets us there?
execution
how do we get there?
technology choices
structure choices
runtime choices
a set of principles that the developers will follow (most of the time)
should be extensive, but not comprehensive (cover the "80" in 80/20)
nothing is set in stone (heuristics, not algorithms)
prescriptive, not descriptive (focus on what to do, not what it looks like)
provide signposts, not guard rails
decision-making tools
heuristics to govern behavior
expression of intent and direction
limited to a handful in number
keeping them few in number forces you to focus on what matters most
tailored specifically to the problem at hand
and to the people who will need them
apply to well-defined activity or decisions
so as to avoid being too broad, general or abstract
provide clear guidance but allow for deviation
leaves room to exercise creativity and handle unanticipated situations
Representational State Transfer (REST)
an architectural style
evolved by Roy Fielding
https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf
https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
Architecture of the World Wide Web
architectural breakdown of the Web
Ian Jacobs, Norman Walsh
https://www.w3.org/TR/webarch/
Rules
URIs are used to identify resources
Agents communicate using standard protocols
Agents do not incur obligations by retrieving a representation
Delivery is in the form of a sequence of one or more messages, which taken together constitute a payload of representation data and metadata
Rules
Identification, interaction, and representation are orthogonal concepts
The information in the Web (and the techs used to represent it) change over time
Agents that recover from error by making a choice without the user's consent are not acting on the user's behalf
Be strict in what you send, liberal in what you accept
... in the classical sense: a way of thinking
designed mostly to help structure approaches/thinking
use, adjust and modify as suits your purposes
Implementation
Adaptation/Evolution
Concurrent/Parallel (SISD, SIMD, MISD, MIMD)
Imperative
procedural
classes/objects
Declarative
Functional
Constrained Logic Processing
Meta-object/Meta-programmatic
Transactional
Neural networks
Fuzzy Logic
Rules engines
Machine learning/genetic algorithms
essentially model-training versions of the above
SISD, SIMD, MISD, MIMD
Divide and Conquer
Recursive Data
Pipeline/Pipes-and-Filters
Event-based Coordination
Master/Slave, Fork/Join
Shared Data
Shared Queue
style
Graphical
Console
None
implementation
Markup (HTML, XAML, Acrobat)
Code
perspectives
User, Administrative, Reported, ...
mobile clients
virtual reality / augmented reality
chatbots/conversational clients
composite clients
Aggregates multiple applications into one
Based around a single style
Transport
Over what medium does the communication travel?
Examples: TCP, UDP, ICMP, HTTP, named pipes, filesystem, queues, ...
Exchange
How do we interact?
Examples: request/response, solicit-notify, async, fire-and-forget, ...
Format
In what format does the data travel?
Examples: XML, code, text, JSON, raw binary, serialized objects, ...
"REST"/HTTP-based RPC
HTTP transport, request/response exchange, JSON format
WebSockets
HTTP transport (negotiable), flexible exchange, flexible format
gRPC
TCP transport, request/response exchange, Protobuf format
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
How do components know about each other?
a-priori knowledge
discovery
registration
How do components restart in failure?
How do components resist stressors?
Durable vs. Transient State
state held across processing steps vs...
state held during processing
Context-based vs. Process-based state
where is the transient state held?
Relational vs. Object vs. Hierarchical vs Event vs ...
what is the "shape" of the data?
NoSQL databases add a lot more shapes...
document, graph, key-value, ...
Location
where is the durable state held?
transient state needs to be accessed very quickly
durable state must survive failures
transforming data across shapes has costs
configuration is state
Fundamental considerations
Generalized concerns
things common to all systems
Specific concerns
things specific to your system
Generalized
authentication
in-source? out-source? mechanics? adding/removing users?
authorization
role-driven? data-driven? granularity?
data "in-flight" vs "at rest"
where are encryption keys stored? who has access? who rotates? when? how?
Specific
what does your system do?
what does your system store?
what does your system access?
what is your system connected to?
what does your system run on top of?
Deployment: putting the system into play
Monitoring: keeping an eye on the system
Administration: making necessary changes to the system
everything necessary to run the app needs to be captured
capture means stored in a place w/easy recreation semantics
dependencies should be explicit and versioned
automate as much as possible (but no more)
how does the system start? stop? pause? resume?
who adds users to the system? removes them? how?
how/when does configuration need to change?
how/when does processing need to evolve/change?
how do we know if/when the system:
falls over
stops processing
is slow
needs to scale out
clouds/servers can provide some hooks
how do we add domain-specific ones
who watches the watchmen?
who will do this work?
who makes the decisions?
how will it be maintained?
what skills will they require?
how will you test any of this?
you WERE planning to test it, right?
"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
... a direction/vision for the software
... a set of answers to questions developers ask on a daily basis
... a set of "simple rules" for developers to follow
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)