Two Kinds of Design
A Question of Method or Mindset?
In this series I was asked by ECI to talk about telco transformation. For me, telco transformation has to do with how an organization goes about designing or implementing change in its communications infrastructure. This is the 3rd blog in the series, following ‘The Best Decisions’ and ‘Is Networking a Commodity?’ This time, I’d like to discuss the process of how networks are designed and what could make this process better.
Information technology design often follows a common sort of process. First you gather the business requirements. While you do your best to gather all the requirements, you know you will miss some, so you assume the project in hand will change over time. As such, you build some “slop” into the schedule and scaling numbers to account for possible changes, based on prior experience. Once the requirements are (somewhat) in hand, you then invite vendors and resellers (or consultants) in to find a set of products that can meet the requirements as outlined. Then you set up an equipment list, and then work through the configurations needed to make the entire thing work. After all of this, you think about how to automate the workflow of deploying equipment and features. Once the system is in the initial deployment phase, you think about how to secure and measure the system, starting with a set of “initial guesses,” and then, over time, in reaction to specific events of various kinds.
Much of this process is codified in the modern mantra of “lean/agile” build something small, deploy it, and then modify it in place until you “get it right.” Or at least that is what it is called. In reality, the process most often used in IT systems development today, including networks and applications, is a rough combination of a random walk through various attempts to “get it right,” half-hearted attempts to gather requirements (because we won’t ever get it right anyway), and what passes for lean/agile as a way to facilitate apparent motion on a never-ending treadmill. Maybe all of this is part of the reason for the productivity paradox—that throwing money at IT systems does not seem to increase productivity—and the reduction of IT systems to cost centers, when in any rational universe they would be strategic assets.
Perhaps the problem is in the method? This is not a likely answer; there been many methodologies introduced in the IT world, either to reduce costs or to increase performance. Most of them seem to falter and fade away, only to be replaced by another in several years.
Rather than a method, maybe it is time to talk about a change in mindset. To begin, perhaps it is better to start with problems, rather than requirements. It is better to think of requirements as distilled problems, rather than raw ones; once you are at the point of building requirements, the direction of the solution is already formed. To make IT valuable, you want to start solving problems, rather than fulfilling requirements.
Once the problem is in hand, it is easy to jump directly to the solution, especially in the form of a product or a system. This is where the lean/agile method tends to be driven, and it is also a mistake. Rather than moving from problem to requirement to solution, it is better to intentionally consider the services required to solve the problem, and how to build those services.
In the world of physical construction, the next step is to consider the materials to be used in the building. A building must have good “bones,” be built with a solid foundation, and strong walls to carry load. Further, the surfaces must be able to support the traffic and work placed on them. The equivalent in information technology is the quality of the algorithms and protocols. Choosing a protocol or algorithm that solves the problem might seem like an odd place to start, but it is no different than deciding whether the structure of a building is to be made out of wood or steel.
The second point to consider might be the quality of the construction—how well are the parts put together? How straight the walls, how flat the ceilings, how well are the joints tied together, etc.? In much the same way, when looking at a protocol, you might think about the quality of the implementation. This is clearly important in the realm of software, but the quality of construction is often related to another, deeper kind of quality that is often completely ignored. These things directly relate to the quality of the construction, as some protocols and algorithms are easier to code, modify, and repair than others. They also directly relate to the simplicity of the design and its deployment.
So the one kind of design is to jump from requirements to equipment, then to configuration, then to automation and security. Down this path lies information technology as a cost center, something to be tolerated for the greater good of the business. The other kind of design is to start with problems, and then to the materials (in the form of algorithms and the protocols), then to the quality of the construction, and finally—only after these have been considered—to the equipment and software to be purchased, installed, and configured.
A change in mindset, towards taking the materials used in building IT systems seriously, and thinking in terms of offering services, rather than fulfilling requirements could go a long way in bringing together the business requirements with systems development in whatever methodology any particular system requires.