When it comes to design, inspiration can be found in the most unlikely places. Take designing complex IT systems. You can learn a lot about how to make your company’s technology work by examining city street plans. Don’t believe me? Let’s take a look.
While I love my city, Seattle, dearly, I find its physical layout incredibly frustrating. At times, there appears to be no logic to the way the city is organized. We have multiple grid patterns, oriented at different angles and intersecting in a crazy mesh of streets and avenues. Streets will suddenly veer into a new direction, change names, or stop entirely only to resume a mile down the road.
How did this happen? The answer to that question reveals a lot about how complex systems evolve and how your initial mistakes can cascade over time to create a tangled web. Chances are, you may recognize some of the factors that make your own company’s IT such a patchwork quilt. I break these into three big lessons.
The story of modern Seattle begins at the turn of the twentieth century, as the city went from being an isolated hub for the lumber trade to a larger, more populous community. It became clear that the town needed to grow, but there was no consensus on what that growth should look like.
Two of the community’s leaders, Doc Maynard and Arthur Denny, each had their own vision for expansion. Rather than uniting forces or hashing out a compromise, they each launched their own, disconnected projects. Those grids that seem to intersect at crazy angles? They are the direct result of these incompatible expansion strategies.
These leaders had divergent perspectives on how they wanted the city to work. Unsurprisingly, this created a chaotic, broken-grid city layout. The implications of this are still being felt today, more than a century later.
Think about your own company’s technology. Much of your infrastructure and design probably has similar history, with multiple people planning along very different lines. Cloud has only further complicated things as the iron grasp of IT over infrastructure has loosened and lines of business and developers have had the ability to blaze their own trail one credit card swipe at a time.
The consequences of disjointed planning are immense, far-reaching, and enduring. This fragmentation makes it much more difficult to onboard new technologies, slowing down progress and innovation. It also leads to greater cost and inefficiency in managing infrastructure, as well as introducing substantial systemic security risk.
While I love my city, Seattle, dearly, I find its physical layout incredibly frustrating. At times, there appears to be no logic to the way the city is organized. We have multiple grid patterns, oriented at different angles and intersecting in a crazy mesh of streets and avenues. Streets will suddenly veer into a new direction, change names, or stop entirely only to resume a mile down the road.
Lesson 1: Lack of cohesive planning
The story of modern Seattle begins at the turn of the twentieth century, as the city went from being an isolated hub for the lumber trade to a larger, more populous community. It became clear that the town needed to grow, but there was no consensus on what that growth should look like.
Two of the community’s leaders, Doc Maynard and Arthur Denny, each had their own vision for expansion. Rather than uniting forces or hashing out a compromise, they each launched their own, disconnected projects. Those grids that seem to intersect at crazy angles? They are the direct result of these incompatible expansion strategies.
These leaders had divergent perspectives on how they wanted the city to work. Unsurprisingly, this created a chaotic, broken-grid city layout. The implications of this are still being felt today, more than a century later.
Think about your own company’s technology. Much of your infrastructure and design probably has similar history, with multiple people planning along very different lines. Cloud has only further complicated things as the iron grasp of IT over infrastructure has loosened and lines of business and developers have had the ability to blaze their own trail one credit card swipe at a time.
The consequences of disjointed planning are immense, far-reaching, and enduring. This fragmentation makes it much more difficult to onboard new technologies, slowing down progress and innovation. It also leads to greater cost and inefficiency in managing infrastructure, as well as introducing substantial systemic security risk.
Lesson 2: Failure to anticipate future requirements
One of the hardest design challenges is to look beyond the needs of the moment and anticipate the future. People are simply not very good at predicting the big, disruptive waves that will shape their world. This creates challenges in systems that are forced to adapt to requirements and technologies for which they were never designed.
This was certainly the case in Seattle’s development. Much of the city’s downtown structure was defined at a period when the very first automobiles were just starting to come into being. Another core modern technology, electricity, was also just beginning to see widespread use. Had these early builders more foresight, they would have anticipated that cars would become ubiquitous and that every home and business would need to be electrified. They would have built the infrastructure to support these technologies.
The history of Seattle is rich in unintended consequences caused by misreading future needs. By the turn of the twentieth century, the city had an enviable public transit system with over 50 miles of cable car track. When budget challenges hit in the 1930s, the streetcars were sold for scrap and the track ripped out. This set back public transit in the city severely. It would be several decades before Seattle would see as extensive a rail system return.
Consider your own company. Has it ever made decisions based on short-term needs that created long-term challenges? There are a lot of organizations out there that are still reckoning with heavyweight, expensive, and inefficient CRM and ERP systems. These systems made sense at the time but now look costly and obsolete, yet are seen as too expensive and difficult to abandon. Instead of bringing in cutting-edge new technologies, some companies will keep relying on legacy applications to save money. Others might move to the cloud due to the low upfront cost, only to be surprised by the long-term expense and complications.
Lesson 3: Building systems of insufficient scale
It isn’t just that Seattle’s early leaders failed to anticipate the technologies and changes that would define their city’s future. They also had no concept of the sheer scale that their city would someday achieve. This is far from surprising – it would have been remarkably prescient if they had known – but that gap in their design has huge implications.
In 1880, the city was home to around 4,000 people. Just ten years later, the 1890 census counted over 42,000 residents. That explosive growth would continue, with the city passing 80,000 by 1900 and 235,000 by 1910. Today, Seattle alone, separate from the larger metropolitan area around it, has over 720,000 people. Those people are still drawing on the same physical space and depending on many of the same elements of underlying infrastructure (e.g. roads, bridges, etc.).
When you take a system designed for one level of capacity and force it to handle vastly greater numbers, you often see serious performance issues. This is true whether we are talking about Seattle’s antiquated plumbing system or your own company’s technology infrastructure. Your systems may not have been designed for the number of users or customers that you now face. This creates serious challenges in availability and speed.
One clear place where we see scale problems in enterprise IT is around data. The rapid growth in the volume, variety, and complexity of data has strained almost every company’s technology infrastructure and systems. Few companies anticipated this data load, or the number of processes and workloads that they would need to digitize and manage in the era of digital transformation. As ever more of the business goes digital, existing infrastructure and systems will be stressed to their limit.
Conclusion: Making the best of imperfect systems
System planning never works the way we might wish it did. We almost never get to start over with a clean slate; we inherit the decisions of those who have come before us. Seattle’s city leaders and planners would probably love to have energy-efficient, modern smart grids, and a more rational road system, but they must do their best with what they have. They can’t simply shut down the city and start over.
You likely have your own version of this challenge when it comes to your business. For success, you need to meet your technology, processes, and people where they are today. Start by reviewing your current applications and deciding what to retire, migrate, and re-platform. Look at your existing people and their skillsets and ensure you have the right competencies in place ahead of advancing your cloud ambitions. When it comes to processes avoid taking on sweeping re-platforming initiatives, like containerization, all at once. Instead, take a sustainable and gradual approach that minimizes disruption and risk to the business. By making smart choices, you can evolve your technology infrastructure without hurting your business and your stakeholders today.
Posts
