Neal Ford
Take business requirements plus a lot of other -ilities to solve a problem.
You need to revaluate abilities (-ililties).
Architects must be able to say "No" gracefully.
Architecture is about tradeoffs.
Architect need to be the honest indicator of 'feasibility'.
You can over stretch your architecture leading to disaster.
Three principles of bridge design:
- value calculations based on simple analysis
- carefully consider construction process
- test the structure always with full-scale load tests
Mail needed to be rerouted.
They decided they wanted automatic scanning and routing.
Then Dave said. Couldn't you just solve a lot simpler with colored envelopes?
A simple solution and he got recognition with partial pay for a long contract.
Sending out service reminder to car owners.
Wrote state of the art in the 80's. He he ran into a decade of analysis paralysis.
So he eventually couldn't find replacement parts for the computer system.
They eventually went out of business because they couldn't just reimplement what they already had because they wanted to create the perfect solution.
The plane was designed for particular situations.
"We need a mach 2.5 aircraft" impractical at the time.
The actual need was it could get out of trouble.
So they made a plane that could accelerate quickly and be manuverable instead of fast because the fast plane would have fallen apart.
"NULL" the billion dollar a year mistake.
Algol 60 was progenitor of Java where null was introduced.
He could have put a switch in place as an optional problem. BUT Fortran had an issue with it and he wanted to be close enough to Fortran. Fortran to Algol converter.
"Legacy is why we can't have nice things."
The deadly side of reuse.
When Java was created they thought that sending serialized Java objects was the wave of the future so that every object. This kept Java from being able to implement things such as lambda for a very long time.
A rocket that would take things to space.
Swerved off of course because of a bizarre set of numbers that came through. They had reused a module from a slower rocket. There was a number rollover.
A max constant was set and they didn't revisit the problem. The system was only used on the ground but they kept it online just in case. They were debugging in production.
They spent a lot of money on advertising (puppet mascot) but not on their infrastructure (servers).
Was the Amazon.com of grocery shopping.
They failed because they were trying to do whole foods quality at safeway prices. Too low of margins.
They built too much infrastructure (huge warehouses).
They were too broadly distributed so they couldn't reuse other assets.
Over-engineering.
https://dougseven.com/2014/04/17/knightmare-a-devops-cautionary-tale/
PowerPeg was in place but under a feature toggle that got forgotten.
Reused PowerPeg toggle but left the PowerPeg on a SMARS deployment.
The problem is PowerPeg is used to buy and SMARS was used to sell so they were doing terrible things.
Put $245mil in debt.
Do you even devops bros?
Clean up your technical debt, don't leave in dead code under feature toggles or in commented out code.
"Every business is pretty much the same, isn't it?" - IBM
They built an ultimately flexible system and said they could build anything with it.
Nope, businesses are all radically different.
SOA tried to do the same thing with canonical representation.
Is HL7, FHIR doing the same thing??? It depends on how ambitious they are.
"The more reusable something is the less usable it is."
"Microservice is a label, not a description." - Fowler
"SanFrancisco Component Framework" with a forward from Fowler
They were using a crazy amount of reflection in this framework.
MS Access gets you 80% what you want easy but then the next 10% is nearly impossible and expensive and then the final 10% IS impossible.
ERP systems are much the same.
Can you live without the last random 10% of functionality that you may someday want?
Infinte time, budget but the project still failed.
"Dreaming in Code" - Rosenberg
Chandlier was "Lotus Agenda" but distributed.
"We've consistently overinvested in infrastructure and design, fruites of which won't be realized in the next development cycle or even two -- that is, not in the next six or twelve months"
Keep building more infrastructure without delivering something.
"Metawork is more interesting than work."
Everyone would rather build a framework then use a framework to build something useful.
"We're going to swapping Anglular out for ReactJS."
"Did the business ask you to do that."
"No, but it will be really cool and it will scale better."
Hmmmm, sound familiar?
http://www.sagradafamilia.org/en/
He did experimental architecture.
An archetype for Netflix and Amazon.
Amazon makes all their money on AWS.
LMAX was also experimentally.
- tradeoffs - a limited perspective can leave you not thinking about all of the tradeoffs. To a good architect everything is a tradeoff.
- ...
- canoniciality
- reuse - creating a lot of work by trying to maximize reuse
- metawork - is always more fun than adding value, avoid falling into this trap