Brick by Brick

    Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
    -- Mel Conway, from a paper submitted to (and rejected by) the Harvard Business Review in 1967 (thanks to Chris Donley of CableLabs for sharing this insight)

When Conway wrote this, he was referring to the development of software modules. What I take it to mean is that if you have code being written by different developers, the communication between them will be reflected in the interface between the software components being developed. If you do not have a good communication path between the individuals, then the code itself will be affected.

This adage can explain much about cellphone and computer operating systems. If you have ever developed OS or other code as part of a team, you have likely experienced it firsthand.

As we now look toward the future of cable, this adage becomes increasingly important as we move away from integrated monolithic architectures. No longer shall we be required to add entire chassis when we need to add a single service group or more compute power. We will have the option of creating a system that consists of discrete components, both hardware and software, which will themselves be used as building blocks to define an ecosystem for future network architectures.

In my last column, I pondered how we would need to keep things simple to enable these advanced technologies. What we have learned the hard way, repeatedly, is that as the pace of technology increases, there is a tendency towards building a more complex system to enable the increased velocity we require to bring these same new technologies to market. The dilemma we face is that complexity can create an unstable ecosystem when you are driving innovation at light speed (or, more correctly, at the speed of cable). As the great philosopher and social commentator Yogi Berra once said, "It's like deja-vu all over again." (See Viewing Things in a New Way.)

What our network brethren have realized is that it is the very act of disassembling functions that enables simplicity in designing complex systems. While this may seem an oxymoron, I think of it this way. I sit here every day at work looking out my window, watching a 14-story building being built on our corporate campus. Watching this day after day, I see the concrete being poured, the rebar being installed, the steel being put in place to frame the walls and windows. Yet if I walk around a corner and just see a building I am not familiar with, it appears to be magically created as it stands like a monolith reaching to the sky. Once you see how it is built by laying a foundation, you come to realize that while the building is still magical, it is built upon layers where each one is dependent on the ones that came before it.

This is similar to how the latest concepts, such as software-defined networking (SDN) and network functions virtualization (NFV), can be used to create a new way of constructing the devices that build the networks and services we use to provide products to our customers. Not only does it apply to the backbone and metro networks, but we can also apply the same technologies to our access and customer premise networks.

In my next blog, I will start drawing the images of how we can use these new paradigms to redefine our network infrastructure and make it simpler to develop future technologies. Until then...

— Jeff Finkelstein, Executive Director of Strategic Architecture, Cox Communications

albreznick 11/26/2013 | 4:25:17 PM
tell us more Thanks for spelling all this out, Jeff. So now we're hungry for more. Once you break down all the network functions, how do you rebuild all the layers? Do you start from scratch or follow a similar patern as before? And how do you keep it all simple?