In March of this year, I took my first ride on a Nozomi train on the Tōkaidō line of the Shinkansen, a high-speed railway that connects Tokyo to Osaka. While no stranger to riding on trains, I was really excited to get a ticket on the Shinkansen because it was the first high-speed railway deployed in the world (1964) and still manages to move like silk over hundreds of mile of track.

Wanting to learn more, I ended up doing some light research on the history of the Shinkansen. The story is pretty interesting! Despite the age of this story, I found parallels to thinking about the challenges in designing and delivering services using cloud and other technologies. It also brought up memories from when I wrote Building Better Infrastructure Automation from Microservices Testing Lessons earlier last year.
In this post, I’ll do my best to highlight the interesting bits of the Shinkansen story while also applying these ideas to the future of technology.
The Height of Madness
You’d think that a high-speed railway that connects two major cities together would be something to celebrate. However, the Shinkansen railway suffered a lot of negative criticism before it was even built. One individual even described the project as “the height of madness” – perhaps you’ve been in a similar situation when proposing something to your team, boss, or company?
With this project, Shinji Sogō, the president of Japan National Railways (JNR), asked the future chief engineer, Hideo Shima, to oversee the building of the first Shinkansen line in 1955. To be clear, this was the most ambitious rail project of the century. The vision was to move a high volume of passengers between Tokyo and Osaka, not to break any sort of land speed record.
Keep in mind that this is during the dawn of the jet propulsion era where most everyone thought that airplanes and automobiles were going to take over nearly all forms of transportation for passengers. Trains were considered old, clunky, and slow with many railways either remaining stagnant or being shut down entirely.
Shima-san wanted the Shinkansen to be entirely focused on high volumes of passengers gaining access to quick, reliable, and frequent trains. To this end, he made some fairly bold design choices:
- The railway would be dedicated to high-speed rail for passengers. No slower trains or freight trains would use the railway. (Rail transportation in the United States consists primarily of freight shipments)
- The tracks would be significantly farther apart to handle a wider stance and improve stability for the high-speed trains, which meant that no other trains could use the railway.
Much like with an IT project, you now have the basis of the design and understand some of the design considerations. In this case, you have two fairly significant constraints (from the perspective of those managing the remainder of JNR trains) or requirements (for the engineers looking to design the new train equipment).
Would you still continue with this project, or opt in for jet planes and hover trains? 🙂
Integration of Proven Technologies
The chief architect decided to take the best of proven technologies – in this case, rail systems – and then integrate it with a wide swath of improvements into a singular, seamless system. Here are just some of the engineering tasks that were tackled by him and his team:
- A dramatic reduction in air resistance from the nose cone and train car design, which also reduces noise at high speeds.
- The elimination of the locomotive in favor of having DC-powered traction motors placed at each axle. This greatly improved acceleration, distributed the weight, and created new failure domains in case of catastrophic breakdowns.
- The track segments were made longer and out of higher grade materials, which damped most of the rail vibration.
- All vehicles were required to go under the train, which eliminated rail crossings. Due to the high speed, a human operator would have no chance of reacting quickly enough at a traditional rail crossing.
- The deployment of automatic train controls, including seismic monitors that would force the emergency breaks in the event of an earthquake (common in Japan) and central control from the Tokyo station.
I like this approach. Considering the critical success factor is being able to “move a lot of passengers with speedy and frequent service”, it makes sense to start with what you know. Passenger safety was a non-trivial design element, and so the engineering team went to review the existing train models and see what could be improved.

Very few others were all that thrilled with the direction of this design, however. The project ran over budget – as most all projects do – and spiked into the 380 billion Yen range, which was about double the estimate. In the end, both Shinji Sogō and Hideo Shima resigned before the Shinkansen was even finished.
Sometimes a good idea is just a beyond what others can grok. It takes a tremendous amount of energy to put up a good fight and hold the line on your ideas, and after many years of being told your project is the “height of madness”, I’m sure you’d get frustrated, too.
The Shinkansen Opens
After nearly 10 years of work, the Shinkansen opened in the Fall of 1964. Passengers remarked that cars on the interstate looked “like they were standing still” in comparison. Inner city air routes were being threatened by a train, which had to cause a few facepalms at the time. At this point, pretty much everyone who thought this was an insane project had to eat a few slices of humble pie.
In three years of service, the Shinkansen had carried more than 100 million passengers. “An executive in Tokyo could get on the train in the morning, hold meetings in Osaka, and then be home in time for dinner.” And there’s the rub – it made life better for the customers, the passengers who just wanted to get from A to B in a reasonable amount of time with minimal frustration.

I also found reference to seeing a train called the “Yellow Doctor” and “Doctor Yellow” scouting along the railway to assess the state of the track (and overhead lines) using on-board equipment to monitor and track state. This goes to show that observability is important for all projects, and that diagnostics and metrics are important to gather for overall service health.
Thoughts
Sometimes, as much as we technologists love to complicate things and use the latest shiny tools in the tool belt, it’s still critical to focus on the purpose of the design and who is impacted.
- Align to customer needs and build something that drives a positive outcome.
- Simplify the solution by removing assumptions and risks. (such as technical debt)
- Deliver a seamless experience to those looking to consume a service.
And, if you ever have a need to get between any of the cities serviced by the Shinkansen lines, I definitely recommend taking the trip!