Part 12 of my series on Architecture Tradecraft, and the last one. Last time, we worked through the architecture review that works, and why a review should be decision support instead of a gate. This time: one company’s architecture decisions over twenty-five years, and how they compounded into something none of them could have produced alone. Follow along for more on how senior architects actually make decisions.

On May 24, 1998, a group of senior Amazon engineers circulated a memo called the Distributed Computing Manifesto. It opened with a diagnosis: Amazon’s two-tier architecture was bound to its databases, applications reached into those databases directly, and that wouldn’t scale to the goal of ten times the current order volume. It proposed a fix, listed the fix’s drawbacks, and said plainly that it wasn’t choosing any technology yet (Vogels, The Distributed Computing Manifesto).

Werner Vogels published the full text in 2022. Read it now and it looks like an architecture decision record written more than a decade before anyone used that name.

Every article in this series took one architecture decision and worked through it on its own. Amazon is the best public example I know of what happens when those decisions are made well, in sequence, by the same organization. The memo took clients off the shared database. That made services possible. Services needed owners, so teams formed around them. Owned services needed stable interfaces. Stable interfaces made shared infrastructure possible. Shared infrastructure became AWS. And twenty years later, Amazon’s own retail teams moved their databases onto it.

Each link in that chain is an ordinary decision. Made in order, each one making the next cheaper, they added up to a company and a cloud.

Decision One: Write It Down Before You Build It

The Manifesto is worth reading for its structure as much as its content. It states the problem in the first paragraph. It proposes two concepts: a service-based model, and processing that moves work between nodes like a workflow. Then it spends real space on what those concepts will cost.

It warns that moving to services will require “a much more disciplined approach to software engineering,” because much of Amazon’s database access at the time was ad hoc, run by a pile of Perl scripts. It admits that a message-based workflow makes some things harder than a central database did: changing the credit card on an order that’s already moving through the system, or simply knowing where an order is. It concludes that these issues make getting the initial design right much more important than it was in the monolith.

That’s Part 1’s argument in a 1998 document. Context, decision, consequences, and the real tradeoffs, written before a line of the new system existed.

The habit stuck. By 2018, Jeff Bezos was telling shareholders that Amazon doesn’t do PowerPoint at all. Meetings start with a six-page narrative memo that everyone reads in silence, in what he called a kind of “study hall” (Amazon 2017 Letter to Shareholders). A written argument can be critiqued. A slide deck mostly can’t.

Decision Two: Split the Monolith Because of a Measured Problem

Amazon moved to services years before the term caught on, and for a specific reason: one architecture had hit one limit.

Amazon started with a monolithic web application called Obidos and a growing set of shared databases. Vogels describes those databases as the bottleneck for how fast the company wanted to move (Vogels, 2022). In a 2006 interview with Jim Gray, he said the big change of the previous five years had been the move from a two-tier monolith to a fully distributed, decentralized services platform (InfoQ summary of ACM Queue interview).

Five years. Phased. Driven by a ten-times growth target written into the founding document.

That’s the test from Part 2 on when not to use microservices: the split has to solve a problem you actually have. Amazon could name its problem in one sentence, and it had the order volume to prove it.

Decision Three: Choose the Coordination Model Per Process

The part of the Manifesto I find most impressive gets the least attention. It argues through the question at the center of Part 3 on event-driven versus workflow-driven architecture, and it refuses to pick one answer for everything.

Should each processing node decide where work goes next (autonomous), or should a coordinator direct it (directed)? The memo walks through credit card charging as an example. Charging gets invoked from many contexts, so it fits the directed model: a service that returns its result to whoever called it. But some steps never change, like multi-book shipments always moving from picklist to rebin, and those fit the autonomous model.

For changes to orders already in flight, it proposes publish-and-subscribe, with every change recorded in a tracking table. An event-driven design with an audit trail, sketched in 1998 for one specific problem.

Decision Four: Shape the Teams Around the Services

Services that nobody owns decay. Amazon’s answer was organizational.

Teams are small, typically five to ten people, the “two-pizza team” (AWS Enterprise Strategy). And the team that builds a service runs it. Vogels put it as “You build it, you run it” in that same 2006 interview, and said giving developers operational responsibility had greatly improved the quality of the services. AWS’s own DevOps guidance still describes small, autonomous, single-threaded teams that own their whole value stream, with central functions such as security acting as enablers instead of gatekeepers (AWS Well-Architected DevOps Guidance).

Part 4 on Conway’s Law argued that your org chart becomes your architecture whether you plan it or not. Amazon’s service boundaries and team boundaries line up, and the ownership model holds them together. A team that gets paged at 3 a.m. for its own service has a strong reason to keep the boundary clean.

Decision Five: Give Each Service Its Own Data

The Manifesto says direct client access to the database has to be phased out, and without that, none of the benefits of the new architecture are possible. It proposes “data domains”: customer data in one domain, vendor data in another, catalog in a third, each behind a service interface, each replicable closer to where it’s used. Its example is replicating customer data to the U.K. and Germany so customer service there wouldn’t depend on one central copy.

That’s Part 7’s question answered in favor of ownership. It also meant each service could pick storage that fit its job. The 2007 Dynamo paper explains that the shopping cart service had to accept writes even while disks failed and networks partitioned, and that many services (best-seller lists, carts, session state, sales rank) only needed lookup by key. A relational database would have limited their scale and availability (DeCandia et al., Dynamo). So Amazon built a key-value store that traded some consistency for availability, and only the services that wanted that trade used it.

The same principle paid off again in 2019. Amazon’s consumer business finished moving 75 petabytes out of nearly 7,500 Oracle databases, across more than 100 teams. Each team picked the AWS database that fit its workload: DynamoDB for low-latency lookups, Aurora and RDS for transactional work, Redshift for analytics. Amazon reports database costs down more than 60%, latency down 40%, and administrative overhead down 70% (Jeff Barr, AWS News Blog). A migration like that is only possible when every team owns its data and can move it without coordinating with everyone else.

Decision Six: Treat the Interface as the Product

The Manifesto calls interface design “something we have never done before”: designing the boundary between a client and a service so the client never sees or depends on the data model underneath. That’s Part 8’s point about API design being architecture, stated as a skill the company needed to learn.

Andy Jassy describes the next step. Around 2000, Amazon tried to offer its e-commerce engine to other retailers, and found its own systems too tangled to expose. It untangled them into documented APIs, and from then on expected every internal team to build services that way and consume each other’s services the same way (TechCrunch, How AWS came to be).

Vogels added a footnote in 2006: AWS customers didn’t care about REST versus SOAP. They wanted the easiest toolkit to build with.

Decision Seven: Build What You Can’t Buy, Then Sell It

Here the chain produced something new. Jassy found that projects expected to take three months were spending three months just building their own database, compute, and storage pieces. Every team was solving the same infrastructure problem, separately. Amazon set out to build shared infrastructure services, and at a 2003 executive retreat realized it had become very good at running them. EC2 launched in August 2006 (TechCrunch).

Part 5 on build versus buy versus compose argued that you build what’s core and what the market can’t supply. Vogels says Amazon built because, at its scale, there was no commercial software to buy. Route 53 shows the same reasoning in a single decision. Defending DNS against DDoS attacks with the standard scrubbing appliances would have cost tens of millions of dollars and added months, so the team invented shuffle sharding instead. With 2,048 virtual name servers and four per domain, there are about 730 billion possible combinations, and no two customer domains share more than two servers (Amazon Builders’ Library, Workload isolation using shuffle-sharding).

Decision Eight: Make Most Decisions Reversible on Purpose

In his 2015 letter, Bezos split decisions into two types. Type 1 decisions are one-way doors: consequential and nearly irreversible, deserving slow, careful deliberation. Most decisions are Type 2, two-way doors you can walk back through, and they should be made quickly by small groups. His warning: large organizations tend to apply the heavyweight process to everything, and the result is slowness and risk aversion (Amazon 2015 Letter to Shareholders). The next year he added that most decisions should be made with around 70% of the information you wish you had, as long as you’re good at noticing and correcting bad ones (Amazon 2016 Letter).

What makes this work at Amazon is the engineering that turns a deploy into a two-way door. More than a decade ago, Amazon measured an average of 16 days from code check-in to production, almost 14 of them spent waiting. It built an internal pipeline system, and the pilot team cut that time by 90%. Today changes go to one cell first, a small set of customers, and roll back automatically if errors rise. A pipeline might wait for 3,000 positive data points before moving on, then bake for a fixed time before the next cell (Amazon Builders’ Library, Going faster with continuous delivery). A cell is a complete, independent copy of a workload. With ten cells, a failure in one leaves 90% of requests untouched (AWS Well-Architected, cell-based architecture).

That’s the machinery behind Part 6 on evolutionary architecture. It also explains how the architecture review in Part 11 can stay light. When most changes are cheap to undo, review can save its attention for the one-way doors.

Decision Nine: Reverse Your Own Pattern When the Numbers Say So

Prime Video’s 2023 write-up is the best evidence that Amazon treats its own patterns as two-way doors too. Its team built a stream-quality monitoring tool as a distributed serverless system, with orchestration in AWS Step Functions and detectors in Lambda. They called that a good choice for building quickly. Then it hit a hard scaling limit at around 5% of the expected load, and the per-transition costs and storage calls made it too expensive at scale.

So they moved all the components into a single process on ECS. Same components, much of the same code, data passed in memory instead of through storage. Infrastructure cost dropped by over 90%, and the service now handles thousands of streams. Their conclusion: whether to use microservices or a monolith has to be decided case by case (Prime Video Tech, archived).

The company that sells serverless published a case where serverless was the wrong fit. That’s Part 9 on architectural fitness in practice.

Decision Ten: Put Regulation Behind a Boundary

Part 10 argued that regulation works best as a hard boundary drawn into the design from the first diagram. In August 2011, AWS announced GovCloud, a separate region for U.S. government workloads under rules like ITAR (Amazon press release). It’s administered only by vetted U.S. citizens, and its authentication is completely isolated from Amazon.com (AWS GovCloud documentation).

Rather than adding compliance flags to every region, AWS drew a new boundary and put the regulated work inside it. The shared responsibility model does the same thing for customers: AWS owns security of the cloud, the customer owns security in it (AWS Shared Responsibility Model).

When It Broke: S3, February 2017

None of this made Amazon immune to failure. On February 28, 2017, an S3 engineer following an established playbook mistyped an input to a command meant to remove a few servers. It removed far more, including capacity for the subsystem that tracks the location of every object in the region. Restarting it took hours, and services that depended on S3 went down with it. Even the AWS status dashboard couldn’t update, because it depended on S3 too.

The post-mortem is the instructive part. It’s public and specific, and every remedy in it is a change to a tool or a system. Nobody is told to be more careful. The tool now removes capacity more slowly and refuses to take any subsystem below its minimum. Other operational tools were audited for the same gap. Planned work to split the index subsystem into smaller cells was moved up to start immediately. The dashboard was changed to run across multiple regions (AWS, Summary of the Amazon S3 Service Disruption).

A typo became a written analysis, and the analysis became a guardrail in a tool.

How the Chain Compounds

Lay the decisions out in order and you can see each one making the next one cheaper.

YearDecisionWhat it made possible nextSeries part1998Write the Manifesto: take clients off the shared databaseA phased move to services with a stated goal1, 21998Pick directed or autonomous workflow per processEvent-driven designs where they fit, coordinators where they didn’t3~2000Untangle systems into documented APIs, required for every teamServices others can build on, internal or external82000sSmall teams that build and run their own servicesClear ownership of every service and its data42000sEach service owns its data and picks its storeDynamo (2007), and later the Oracle exit (2019)72003–2006Build shared infrastructure, then sell itEC2 (2006) and the AWS business52011Put regulated workloads in a separate regionGovernment and ITAR customers without changing every region102015Name one-way and two-way doorsFast decisions where undo is cheap6, 112017Turn the S3 outage into tool guardrails and cellsSmaller blast radius for the next mistake6, 92023Prime Video moves a service back to a monolithEvidence that the patterns themselves stay reversible2, 9

What Transfers

You can’t copy Amazon’s scale, and you shouldn’t try. The habits underneath travel fine.

1. Write the decision with its drawbacks. The Manifesto’s admission that in-flight orders would get harder to change is what makes it useful twenty-five years later.
2. Tie every split to a measured problem. Ten times the order volume was the reason. Write yours down.
3. Give data to the service that owns it. Every later freedom, from Dynamo to the Oracle exit, depended on that.
4. Build the undo before you need it. A two-way door takes engineering: a canary, a cell, an automatic rollback.
5. Turn failures into mechanisms. When a person makes a mistake, change the tool so the next person can’t make the same one.
6. Let internal platforms earn adoption. Amazon’s pipeline team had a goal they called “seductive adoption”: make the product so good that teams demand it.

A Fit Check Before You Borrow From Amazon

1. What’s the measured problem this practice solved for Amazon, and do you have it?
2. Which earlier decision does it depend on? (Two-pizza teams depend on service ownership. Fast deploys depend on cells and rollback.)
3. Who owns it after you adopt it, including at 3 a.m.?
4. How would you undo it if it doesn’t fit?
5. Where will you write down why you chose it?

The Trap: Copying the Motto Without the Mechanism

Every article in this series names a trap. This one is the most tempting of the twelve, because Amazon’s practices come with catchy names.

Calling teams “two-pizza teams” without giving them the pager for their own service is a reorg. Ownership starts with the pager. Calling a change “a two-way door” without the canary, the cell, and the automatic rollback is a hope. Requiring six-page memos without reading them in silence and arguing about them is homework.

The tell: someone says “it’s a two-way door,” and nobody in the room can describe how the rollback works.

What Does All This Cost?

Autonomous teams duplicate work. Amazon’s own account of its pipelines admits that single-threaded teams were solving deployment problems independently, and best practices spread by mailing list and luck. The fix was to build best-practice checks into the release tools themselves, configurable per organization (Builders’ Library). That’s a platform team you have to fund.

Writing costs time. A six-page memo for every significant decision is a real tax, and it only pays off if people read and argue with it.

Most of the evidence here comes from Amazon and AWS, which sell the services involved. The Oracle numbers and the Prime Video savings are self-reported. The direction is consistent across twenty-five years of documents, but the exact figures deserve some skepticism.

Where That Leaves the Series

Twelve articles, one decision each. Amazon shows what they look like when they stack: a memo that admits its own costs, services with owners, data with owners, interfaces treated as products, undo built in, and failures turned into tools. None of those choices is exotic. Making them consistently, in order, for twenty-five years is the tradecraft.

Key Takeaways:

• Amazon’s 1998 Distributed Computing Manifesto stated a problem, a goal, a proposal, and its drawbacks before any technology was chosen.
• Each later decision depended on an earlier one: services needed owners, owners needed their own data, owned data made Dynamo and the Oracle exit possible.
• Two-way doors take engineering: cells, canaries, bake time, and automatic rollback make most changes cheap to undo.
• Amazon reverses its own patterns when the numbers change, as Prime Video’s move back to a monolith shows.
• Failures become mechanisms: the 2017 S3 post-mortem ended in tool guardrails and cell work.
• The habits transfer to organizations of any size. Amazon’s scale is optional.

Action Items:

1. Write your next significant architecture decision as a short narrative with its drawbacks listed, and read it in silence at the start of the review.
2. For each planned service split, write the measured problem it solves in one sentence.
3. Find every place where two services share a database, and name the owner each table should have.
4. Pick one service and make its deploys reversible: a canary stage, an automatic rollback alarm, and a bake time.
5. For your last incident, turn one “be more careful” action item into a change in a tool.
6. Before adopting a famous company’s practice, run the five-question fit check above.

Tools and Resources

Primary Documents:

• The Distributed Computing Manifesto (Amazon, 1998; published by Werner Vogels, 2022): the memo that started the move to services
• Amazon 2015 Letter to Shareholders (SEC): Type 1 and Type 2 decisions
• Amazon 2017 Letter to Shareholders (SEC): six-page narratives

Architecture:

• Dynamo: Amazon’s Highly Available Key-value Store (2007): per-service storage tradeoffs
• Cell-based architecture (AWS Well-Architected): limiting blast radius
• Workload isolation using shuffle-sharding (Amazon Builders’ Library): the Route 53 design

Delivery and Operations:

• Going faster with continuous delivery (Amazon Builders’ Library): pipelines, cells, and rollback
• Summary of the Amazon S3 Service Disruption (AWS, 2017): a model post-mortem
• Scaling up the Prime Video monitoring service (Prime Video Tech, archived): reversing a serverless design

What’s Next

That’s the last article in the series. If you want more on engineering decisions, the Engineering Economics and Design for Security series are both still active.

Series Navigation

Previous Article: The Architecture Review That Works: Decision Support, Not a Gate

Daniel Stauffer is a software architect and engineering leader specializing in large-scale systems, platform engineering, and technical strategy. He writes about the decisions that shape how systems, and the organizations that build them, actually work.

Which architecture decision in your organization made the next five easier, and did anyone write down why it was made?

#SoftwareArchitecture #SystemDesign #EngineeringLeadership #AWS #SoftwareEngineering

The 1998 Memo Behind AWS: How Amazon’s Architecture Decisions Compound was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

In June 1918 a 28-year-old high school math teacher quit her job in Amarillo, Texas, and enlisted in the Navy as a chief yeoman. Her name was Agnes Meyer. Three years later, an inventor ran an ad in a marine magazine calling his cipher machine unbreakable. She broke it. Just the sample message he’d printed, but still.

She is the first of eight U.S. veterans, spread across a century, who left a mark on computing. A codebreaker, the man who gave us the mouse, a dentist who built the first full-body CT scanner, a Marine who founded GoDaddy, a tank officer behind the padlock in your browser, and three more. What struck me, lining them up, was how little they have in common once you look closely. So let me just introduce you to them, oldest first.

YNC Agnes Meyer Driscoll, USN: Naval Cryptanalysis Pioneer

Meyer’s active duty with the Naval Reserve ran from June 1918 to July 1919. She came in at Chief Yeoman (F), the “F” marking her as a woman and the rank the highest one a woman could hold in the Navy at the time. Her codebreaking didn’t stop when the uniform came off. In 1921 Edward Hebern put out that unbreakable-machine ad; she cracked the sample, and he hired her on the strength of it. Around then she married a Washington lawyer named Michael Driscoll, which is the surname the history books use.

For the next 20-odd years she trained the men who would go on to run Navy codebreaking, Lawrence Safford and Joseph Rochefort among them. That’s the same Rochefort whose team read the traffic that set up the ambush at Midway. She tended to be the first one through a new system. The Japanese Red Book, the Blue Book, and the Orange fleet maneuvers cipher all fell to her. The Blue Book was the hardest: a code and a cipher layered on top of it, both to be unpicked at once. She also broke the Hebern rotor machine, one of the first rotor cipher systems anyone had tried to sell as unbreakable.

Rear Admiral Edwin Layton, who worked with her, said plainly that she understood machines and how to use them. In 1937 the Senate voted her and Lieutenant Commander William Gresham a $15,000 prize for a cipher machine they helped build. She was a principal cryptanalyst through December 1950, then moved to the Armed Forces Security Agency, the NSA’s parent, until 1959. More than 30 years at the edge of American codebreaking, most of it on systems she was the first to open.

Let me be honest about why she leads this list. She broke ciphers; she didn’t build a computer. But the NSA’s own historians have written about how cryptology seeded early American computing, and wartime codebreakers kept reaching for more powerful machines to line up and compare message texts. She sits at the headwaters. The current runs from her desk to the machine room, and that path is on the record, even if she never ran the machines herself.

RT2 Douglas Engelbart, USN: Inventor of the Mouse

Engelbart was partway through an electrical engineering degree at Oregon State when he joined the Navy in 1944. He served as a Radio Technician Second Class, working on radar in the Philippines, where he spent his days reading and moving symbols around a glowing screen. That was his first taste of the thing he’d spend his life on: a person and a display, working together.

Then the war ended. He had time to kill. While he waited for a ship home that summer, he ducked into a Red Cross library up on stilts and pulled the July 1945 Atlantic off a shelf. Inside was Vannevar Bush’s “As We May Think,” an essay imagining a machine that could extend how a person thinks. (Some accounts say 1946. I’ll go with the ones that put it right at the surrender.)

The seed sat for six years. Then, in 1951, newly engaged and taking stock, he saw the whole thing at once: himself at a big screen, pushing symbols around, other people wired into the same machine. Nobody wanted it. Not yet. You used a computer by feeding it punched cards and waiting, and a screen you could talk to wasn’t on anyone’s wish list. He got to the Stanford Research Institute in 1957. An ARPA grant in 1963, topped up by NASA and the Air Force, finally bought him a lab, the Augmentation Research Center. The mouse showed up in 1964: a wooden block, two metal wheels, one button, built by his colleague Bill English.

Then came December 9, 1968. He had a 90-minute slot and a 2,000-seat hall at the ACM/IEEE Fall Joint Computer Conference in San Francisco. In 90 minutes he put the whole future on one screen: live text editing, the mouse, hypertext links, windows, version control, and two people editing the same document over video. The actual computer hummed 30 miles south at SRI, patched in over a microwave link his 17-person team had strung together. People now call it “the mother of all demos.” He later said he was nervous as hell. The lights came up to a standing, cheering room. Decades later the field paid its debts: the ACM Turing Award in 1997, and the National Medal of Technology in 2000.

Seventeen years sat between the 1951 vision and the 1968 demo. If you’re building something your own colleagues can’t see the point of yet, that gap is the part of his story worth taping to your monitor. Here’s the catch, though: Engelbart never caught the money. The Macintosh carried his mouse and his graphical screen into the world in 1984, sixteen years after he showed them off. I think about that every time someone calls a first-mover unbeatable.

1st Lt. Robert Ledley, USA (Dental Corps): Whole-Body CT Scanner

Robert Ledley came out of Columbia with a physics master’s and out of NYU with a dental degree. The Army drafted him in 1950, and a colonel laid out the deal: volunteer and pin on an officer’s bars, or get drafted anyway. He pinned on first lieutenant’s bars and served in the Army Dental Corps through the Korean War. The posting turned on an odd coincidence: the Army, as he put it, wanted “a dentist who was a physicist. And that was me.” After his discharge he landed at the National Bureau of Standards, where his wife was programming SEAC, one of the first stored-program computers in the country. She’s the one who introduced him to the machine. A dentist, a physicist, and now a programmer.

The part I love lands in the early 1970s. He had 40 or 50 people on payroll at Georgetown when a call came through: his NIH grants were approved but wouldn’t be paid, because Nixon had just cut medical research funding. About then a neurosurgeon, Dr. Luessenhop, waved a glossy brochure for EMI’s head scanner at him and said he wanted to buy one. As Ledley remembered it, EMI had the brochure but not yet the machine.

So he read a physics paper, figured he could build a whole-body scanner for half the cost, and admitted afterward that he hadn’t known the cost. No mechanical engineer would take the job, so he drew every part himself. A machine shop on Wisconsin Avenue cut the steel. A Cadillac dealer’s body shop painted it so the doctors would take it seriously. The ACTA scanner went into regular clinical use at Georgetown at the tail end of February 1974. It worked. A dentist with a lathe and a Cadillac paint job had built it.

His first save came sideways. A pediatric neurosurgeon scanned a four-year-old who’d come off a bike and found a bleed. He never told Ledley until afterward. Ledley had been standing by that machine eight hours a day and still missed it. The patent is №3,922,552. He built the scanners through his own company, roughly $300,000 each with $100,000 up front, after a banker told him the bank only lent to people who put up houses. Take it as one man telling his own story.

Where it gets complicated is credit. CT has more than one parent, and EMI’s head scanner got there first. But the whole-body machine was his, and so was a remarkable stack of work around it. A 1959 Science paper, “Reasoning Foundations of Medical Diagnosis,” argued that computers could help doctors diagnose, and helped launch medical informatics. He built FIDAC, a machine that digitized medical photographs so a computer could read Pap smears and chromosomes. He founded the journal Pattern Recognition and edited it into his eighties. He went into the National Inventors Hall of Fame in 1990 and took the National Medal of Technology in 1997.

LCpl Bob Parsons, USMC: Founder of GoDaddy

Bob Parsons signed up for the Marines in 1968 and carried a rifle as an 0311. On March 1, 1969, he was an 18-year-old moving through a rice paddy in Quang Nam province with Delta Company, 1st Battalion, 26th Marines. He came home wounded, with a Purple Heart, a Combat Action Ribbon, and the Vietnamese Cross of Gallantry.

The G.I. Bill put him through the University of Baltimore, where he graduated magna cum laude and became a CPA. A book from the Stanford bookstore taught him to program microcomputers. He wrote his own accounting and tax software, dropped $40,000 into a basement company called Parsons Technology, and sold it to Intuit for $64 million in 1994. Two years earlier that company had debuted at №11 on the Inc. 5000. In 1997 he started GoDaddy, which grew into the largest domain registrar on earth; he sold a 71% stake in 2011 for $2.3 billion. GoDaddy made the Inc. 5000 too, at №8, and so, later, did his golf company. Three businesses, three times on that list.

Parsons gives the Marine Corps the credit for everything he’s done since. I’ll take him at his word. Worth separating out, though: the code came from a book he bought himself, so the Corps gets credit for the man, not the skill. His mark on computing is a business one. He sold software to regular PC owners back when that barely counted as a market, and he turned the domain name into something anyone could buy.

2Lt Neal Creighton, USA: Founder of GeoTrust

Before dawn on February 27, 1991, a 25-year-old armor platoon leader named Neal Creighton rolled toward Jalibah Airfield in southern Iraq. He commanded a tank platoon in Alpha Company, 1st Battalion, 64th Armored Regiment, 24th Infantry Division, in one of the fiercest fights of Desert Storm. His Bronze Star citation, with the “V” for valor, records the day in the Army’s own words. He was a West Point graduate and a Ranger, following his father, a major general, into the Army.

He served five years, then went to Northwestern for a law degree and an MBA, and turned to the internet’s security problem.

In 2001 he co-founded GeoTrust, a certificate authority, the kind of company that vouches for who’s on the other end of an encrypted connection. Creighton is co-inventor of the domain-validated certificate, patented in 2006, a way to automate that vouching so a website could get a trusted certificate in minutes instead of days. That method now accounts for the large majority of SSL certificates on the internet. By 2006 GeoTrust was the world’s second-largest certificate authority, and VeriSign bought it that year for $125 million.

Here’s the part worth sitting with. Every time your browser shows a padlock, something is quietly deciding whether to trust the site on the other end. The machinery behind a big share of those decisions traces back to a patent co-invented by a tank officer who fought at Jalibah. He kept building after GeoTrust, too, through more security companies, the way the others on this list did.

CSM Phyllis Newhouse, USA: Cybersecurity Company Founder

Phyllis Newhouse swore her enlistment oath on Veterans Day in 1977. She retired 22 years later as a command sergeant major. She grew up one of 11 kids. The thing that pulled her in, she’s said, was the sight of women in Air Force flight suits. They looked like superheroes to her.

Twenty-two years in the Army followed, in cybersecurity and intelligence, with three tours at the Pentagon. She was frequently the only Black woman in the room when the big calls got made. By her own account she stood up the Army’s Cyber Espionage Task Force. Offered a senior-level posting at the end, she turned it down and retired to build something of her own.

In 2002 she launched Xtreme Solutions, a cybersecurity and IT services firm. It grew to 6,500 people across 42 states, 40% of them veterans, serving clients that include the departments of Defense and State. Then she turned investor and dealmaker. In 2021 she took Athena Technology Acquisition Corp. onto the NYSE in a $250 million IPO, the first Black woman to lead an NYSE-listed SPAC, and she launched a second one after it. Alongside that she co-founded ShoulderUp with the actress Viola Davis, a fund and nonprofit aimed at getting capital to women founders.

Capt Roxanne Petraeus, USA: Compliance Training Founder

Roxanne Petraeus read economics at Harvard on an ROTC scholarship and went to Oxford as a Rhodes Scholar. As an Army engineer officer she deployed to Afghanistan during the 2010 surge, served in combat, and later ran training missions for foreign militaries in Cambodia and Mongolia under Special Operations. She left in 2016 as a captain.

Her company came straight out of something she noticed in uniform. The Army could teach her to jump out of a plane in three weeks through drilling and simulation, and yet the ethics training was, in her words, “mostly a joke.” A unit rehearses whatever it actually respects, and she thought corporate compliance had the same disease.

In 2019 she and Anne Solmssen started Ethena, a compliance platform that drip-feeds short lessons through Slack, email, and phone alerts, timed to whatever an employee is doing that week. She calls it the “arbitrary Tuesday problem”: a don’t-take-bribes lecture on some random Tuesday slides right off, but the same point lands the day before you fly out to meet officials. The approach caught on. Ethena closed a $30 million Series B in June 2022, raising from the likes of the former Stripe executive Lachy Groom, and put its training in front of staff at Netflix, Zendesk, and Carta.

This is a product-and-business contribution, not a deep technical one, and I’d rather say that than dress it up. What I like is the lineage: an operational read on how people actually learn, turned into a piece of software.

2Lt Blake Hall, USA: Founder of ID.me

Blake Hall began his service in 2004 as a second lieutenant in the infantry and went through Ranger school. He led a battalion reconnaissance platoon out of Mosul, Iraq, on more than 450 combat patrols without losing a soldier. He came home with two Bronze Stars, one for heroism stopping an al-Qaeda assault on a combat support hospital, the other for hunting high-value targets. Then he went to Harvard for an MBA.

The founding story is almost too small for the scale it reached. Hall watched another veteran hand a store clerk his full DD-214, the whole discharge record, just to claim a military discount. One form. It gave away far more than the discount asked for. He figured people ought to be able to prove who they are without surrendering everything, and in 2010 he started what became ID.me.

Today ID.me says it has verified more than 100 million people and that over 80 government agencies use it. Scale like that draws fire, and it did. Early in 2022 the IRS moved to make taxpayers submit a video selfie through ID.me to open an online account. The privacy backlash was loud, and on February 7, 2022, the IRS said it would step back from third-party facial recognition; ID.me then let agencies drop the selfie step.

Both halves belong in the story. The original idea is a good one: prove yourself once, instead of handing over everything, every time. And a company sitting on the identities of 100 million people ought to expect hard questions about biometrics. Those questions were fair.

So What Do the Eight Share?

Less than I’d guessed. Service turns up in their work in at least three different shapes, and for one of them I couldn’t find any claim at all.

With Driscoll, Engelbart, and Ledley, it was training and exposure. The radar screen, the odd physics-and-dentistry pairing, those were the exact things the service put to use. With Hall and Petraeus, the service handed them the problem: a buddy surrendering a discharge form at a cash register, a unit that drilled for combat but not for conduct. With Parsons, Newhouse, and Creighton, it’s what they say it handed them, which is discipline and a place to learn how to lead people. Creighton commanded a tank platoon in combat and then built a company in a field with no connection to armor; the thread is the person, not the skill.

Those are the threads I can actually document. The sample is mine, pulled from sources I could check, so it tells you nothing about veterans as a population. A great many people built computing without ever serving. Be skeptical of anyone who spins a list like this into a theory.

What I take from it is smaller and more useful. When you hire a veteran, or end up working next to one, the line “U.S. Army” on the résumé won’t tell you which of these three stories you’re looking at. It might be training, it might be the problem that lit them up, it might be the way they learned to run a room. So ask.

If you served, thank you. And if there’s a name that should be on this list, put it in the responses. I read them, and I’m short on Korea and Vietnam.

Key Takeaways:

• The military runs on some of the sharpest, most inventive people this country produces. The mouse, the CT scanner, GoDaddy, and ID.me all trace back to someone who wore the uniform first.
• That talent does not retire when the service does. These eight did their biggest work after they took the uniform off, and they are not rare.
• Veterans bring things the civilian résumé undersells: they operate under pressure, they lead, and they ship. Hire them, fund them, back their companies.
• The skills transfer in more than one way. Sometimes it is technical training, sometimes the problem they saw up close, sometimes learning to run a team when the stakes were real.
• Supporting veterans is not charity. It is recognizing a pipeline of builders the tech industry already leans on, usually without knowing it.
• This Veterans Day, the useful move is not just thanks. It is a job, an investment, an introduction, or a reply with a name that belongs on this list.

References

Agnes Meyer Driscoll

• “Agnes Meyer Driscoll” (Agnes Scott College, Biographies of Women Mathematicians)
• “Cryptology’s Role in the Early Development of Computer Capabilities in the United States” (NSA)
• “NSA Before Supercomputers” (NSA Cryptologic Almanac)

Douglas Engelbart

• “The Mother of All Demos” (Smithsonian, Lemelson Center)
• Howard Rheingold, Tools for Thought, ch. 9
• “Douglas Engelbart” (Britannica)

Robert Ledley

• “The Story Behind the Development of the First Whole-body Computerized Tomography Scanner as Told by Robert S. Ledley” (PMC)
• “Evolution of Military Medical Technology” (Military Health System)

Bob Parsons

• Bob Parsons official biography
• “PTSD Helped Make Vietnam Vet Bob Parsons A Billionaire” (Forbes)

Neal Creighton

• “Neal Creighton” (Wikipedia): GeoTrust, the domain-validated certificate patent, and his Gulf War service
• Bronze Star with “V” citation, 2nd Lt. Neal Creighton, 27 February 1991 (Military Times Hall of Valor)
• “Battle for Jalibah Airfield” (Wikipedia)

Phyllis Newhouse

• “MIGHTY 25: Meet Phyllis Newhouse” (We Are The Mighty)
• “She Was the Only Black Woman in the Room” (Inc.)
• “This military vet has the secret formula to becoming a great leader” (MSNBC Know Your Value)
• “Meet Phyllis Newhouse” (Shoppe Black)

Roxanne Petraeus

• Grow Strong Leaders Podcast bio (Apple Podcasts)
• “Why saying you have a speak-up culture might actually be dangerous” (Ethena, by Roxanne Petraeus)
• “Compliance training platform Ethena raises $30 million Series B” (Fortune)

Blake Hall

• “From grunt to Harvard student to tech entrepreneur” (Military Times)
• “About ID.me”
• “IRS backs away from facial recognition” (Journal of Accountancy)
• “ID.me says users can delete selfies following IRS backlash” (CBS News)

More From the Architect’s Workshop

If this was useful, consider joining Medium. It’s what lets me keep writing these.

I also write multi-part series on the decisions that outlive any one feature:

• Coding for Green
• Design for Resiliency
• Communication for Engineers
• Agentic AI
• Quantum Computing for Architects
• AI Policy
• Gen-AI Assisted Coding
• Platform Engineering
• Design for Security
• Architecture Tradecraft
• Engineering Economics
• Design for Adversity
• Rust for Systems Architects

Daniel Stauffer is a software architect and engineering leader specializing in large-scale systems, platform engineering, and technical strategy. He is also a U.S. Navy submarine veteran who served during Operation Enduring Freedom. He writes about the decisions that shape how systems, and the organizations that build them, actually work.

#ComputingHistory #VeteransDay #Technology #SoftwareEngineering #TechLeadership

Veterans Who Shaped Tech: Eight Lives Across a Century was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.