understand the role of System Architecture on overall complexity
EM.413 Bruce Cameron System Architecture meeting
brief discussion about Entropy again as it relates to code
Does software need separate architecture?
other engineering disciplines need to build architectures separately, but this doesn’t happen in code
I think that’s partially because code, in principle, contains the architecture. It’s the essence of designing the system
this doesn’t mean it’s actually easy to extract that, and that’s what Dan Sturtevant is working on
ways to organize an org
functional
business units
or both
Benefits of commonality
similar vs identical
80% sharing is much less useful than identical
even 99% sharing still requires two items in inventory
benefits of similarity is often over estimated, but benefits of commonality generally is under estimated (especially for identical)
Principles of System Architecture
Language is the interface of the mind
Talking about executives
CEO, CTO
Is the CTO role transferrable?
Sample of CTOs from LinkedIn
Average age: 48
48% MS or PhD
56% medium to small firms
Is CTO a glorified individual contributor or an owner of the engineering pipeline?
Models of CTO types
The Anchor
head of product development
The Coordinator
The Evangelist
a public persona
The Visionary
anticipates future change
more like a technical CEO?
The Strategist
Michael Cusumano on industry platforms
Basic Types
Transaction Platforms
App Store
Innovation Platforms
Intel CPU
AWS
Hybrid
lots are moving towards hybrid of the two
How much kindling does your platform need to get the fire started?
Trust Center for MIT Entrepreneurship calls this the Beachhead Market
System Architecture as a model of future reality
EM.412 System Architecture Ed Crawley meeting
Talking about regulators / regulations
Federal agencies
Triangle of Innovation
Insight
Technology
Customer Needs
Industry platforms
Differentiating between suppliers and partners in a two sided market
Partners
earn proportionally to your revenue
has access to your customers
no contractual obligation
has network effects
Suppliers
earn directly from you
detached from your customers
contractually bound
no network effects
Network effects
actions by others create value for you
eg
my mom joining a network means I can call her for free
how much does an additional user increase the value of other users
how much does an additional user increase the demand for the other market side
Feel the marble
opening up your environment, others need to believe
rules will be evenly enforced
you won’t compete against them
Industry platforms are high risk
Only 17% succeed (sample of 250 firms)
average lifetime 5 years
reasons
mispricing on one side
failure to develop trust
prematurely dismissing competition
entering too late
https://hbr.org/2019/05/a-study-of-more-than-250-platforms-reveals-why-most-fail
Open architecture
Distributed contributions
Stated open not always open in practice
Are DSMs just categories?
every connection is an arrow
category theory
MIT/SDM/Thesis Ideas
Dan Sturtevant
SDM Thesis Ideas
System Architecture
EM.413 System Architecture
Dan Sturtevant on software architecture
focused on software
Only 7% of projects are successful
on schedule, budget, good functionality, not abandoned
code has structure, but it’s not three dimensional
this makes it harder to understand the structural problems in code
Three dimensions are natural, two dimensions are efficient.
code is like taking knowledge and encapsulating it into functionality
emergent properties
usually bad
usually result in emergencies
define and enforce design rules
there’s often a difference between how the engineers think the code is structured and how it actually is
engineers disagree and code scanning shows a different result
Modular Design
Entropy happens to codebases to make them undesigned, less modular
Design Rules: The Power of Modularity by Carliss Baldwin and Kim Clark
if you have a technical system that’s highly modular is like creating an evolutionary system
similar to organs
DSM and network view can be isomorphic
DSM allows you to compress a lot of information a network view would be too complicated to view
can see API, shared code, hierarchy, complexity
dependencies across modules both above and below the diagonal shows bad hierarchy
see Joel Moses for work on network representations MIT
Question
Do you find that codebases that lean harder on Functional Programming concepts (like immutability, reduced side effects) produce more modular?
Systems want to be more tightly integrated if there are parts performing multiple functions
Hardware systems it’s more common to tightly integrate for operational efficiency
I suspect interfaces have more energy loss in hardware systems than in software systems
It’s not enough to say the baby is ugly, eventually you need to tell them how to get the baby a nose job.
modules could be mapped to files / functions
like type safety for architecture
->
Make your architecture type safe
restrict use of modules to the API
Apparently distributed organizations build more modular systems…
his company does this analysis on code
Silverthread
https://www.silverthreadinc.com/white-papers
can consider this for thesis, Dan Sturtevant would consider advising
Takeaways
architecture is meant to promote understandability and evolvability
architecture health is holistic, code health is reductive
both valuable
Dan Sturtevant wrote an article on Modular Design is required for Agile development
Platforms
Spans multiple products
industry platform
sharing across firms
two sided market
product platform
sharing within the firm
often done for cost savings
though there does seem to benefits to scale: more worthy of investment the more internal scale
sounds like this includes internal frameworks in software
modularity, standardization, component reuse are possible synonyms, so sounds like Bruce agrees with this
BMW example
increased shared parts to save money to spend on building more models
presenting to the customer as a family of products doesn’t necessarily mean shared platform
passive vs active sharing
passive
someone reuses some existing work
this seems like kind of have network effects
active
looking around the firm to figure out who needs the shared component and what are everyone’s requirements
a thought
seems like lots of successful enterprise software comes from initially serving internal needs like this then beginning to sell them externally
classmate mentions that Google Cloud was like this
badge engineering
putting a logo on a product is enough to differentiate it, and change pricing
1983 GM cars in fortune magazine
commonality premium
extra cost to design a common component
this is the classic problem in code share
EM.413 meeting Bruce Cameron System Architecture
Tradespaces
Tradespaces are really just a list of feasible concepts
Sensitivity vs connectivity
tests for architectural decisions
architectural decision vs design decision
architectural decisions are more sensitive and more connected
not a categorical difference between architectural and design decisions
architectural decisions are a subset of design decisions
Talk by Morgan Dwyer
System Architecture vs System Engineering
Plenty of overlap in this course
Conversation with materials
EM.412 meeting System Architecture Bruce Cameron
Corporate Strategy
Idea 1
Where to play
How to win
this is often missing
not the same as how your product is differentiated
Idea 2
What we are not going to do…
the big picture: situational conditions
for these outcomes, we are going to do x and why
for other outcomes, we are not doing this and why
constraints
Idea 3
business the firm is in
define business scope
products
markets
geography
develops core competencies
assesses opportunities and threats in the environment and strengths and weaknesses
Do you derive competitive advantage primarily from your architecture?
Yes
Apple, Sonos, Dyson
No
Ford, Walmart, SAP
But this is just technical architecture, not the architecture of the business
Competitive advantage
what you do while you do other things
Michael Porter’s 5 forces
answers how attractive an industry is, not corporate strategy
GE Case
https://www.wsj.com/articles/ge-powered-the-american-centurythen-it-burned-out-11544796010
Henry Mintzberg
best person I’ve read who talks about strategy
Five definitions of strategy
Strategy as plan
Strategy as pattern
Strategy as position
Strategy as ploy
Strategy as perspective
LATER things to be sure you grasp
P&L
COGS
EBITDA
Gross Margin
Relationship of cash flow to balance sheet
EM.413 System Architecture Bruce Cameron meeting
Summary of Bill Simmons presentation
Three rules of scalability
Use partition-able, parallelize-able methods
Do compounding work
Reduce intra-process communication to an absolute minimum
kind of like Mythical man month
Amdahl’s Law
Look for opportunities for “sloppiness”
keep things slow where they can be slow
Use abstractions to increase achievable product complexity
Architecture as borrowed term from architecture
Ballerina vs gymnast
aesthetics can be part of the the function
Guidance for spring project
the narrative for our project
is automation useful, or the real problem?
if it is, where can we actually contribute?
implies things about potential over cost and over design
don’t take it as granted that modular is always better
Imagine the world as it could be
can imagine a big world
sell the product
Principles
Essential Complexity vs Apparent Complexity
like Technical Simplicity vs Interfacial Simplicity?
