Five Design Principles for the Network Architect - The Sixth Principle!

(#7 of 7)

Throughout this series, I have tried to set out a set of simple design principles I believe all network architects should adhere to in order to ensure the success of their projects.  These have covered properties of the network and their operation which, given the appropriate level of attention, can make the difference between a successful and useful foundation for a customer's IT and one that fails to provide the right kind of underpinning for the services and systems that the customer needs to be successful.

• An available network ensures that clients can access the applications and services they need to when they need to;
• a scalable network can grow or shrink to meet demands placed on it by the customer;
• a secure network ensures that a customer can support their customers with integrity and privacy;
• a supportable network infrastructure is one which is measurable and transparent, and has the right tooling around it to ease operations;
• a simple network is in the eye of the beholder - it can be represented at different levels of abstraction appropriate to the consumer of the service.

All networking vendors have a set of standard, often validated and templated, design patterns for different network elements which tick some or all of the boxes above, and help guide the network architect towards building a network to support the customer needs.  There are white papers and design guides on every vendor website which explain exactly how a particular piece of equipment (or combination of pieces) should be deployed in order to solve a particular customer problem.  So in theory, a network architect's job should be simple, right?  Assemble the Lego blocks provided by the vendors into a network to solve all the customer's problems!

Well ...

Here's the thing.  A truly successful network design blends all of the above features in a measurable and well-understood way.  But no network is an island, right?  Every network operates within the context of a larger organisational structure, be that a private conglomeration of networks, or a public one like the Internet.  Usually, there is an old network that needs to be migrated away from, or there is a second network that needs to be integrated with, and these not insignificant issues have an effect on network design.

Specifically, they introduce a need for Pragmatism, or Compromise.  We would love to be able to implement the "perfect" new software-defined fairy tale castle - but each castle needs its pathways and bridges so that it can be supplied from nearby towns which might not be quite so perfect.  It might be built on slightly shaky ground and so its foundations might need shoring up in some way.  And it might be replacing a series of huts in the nearby swamp where services live right now and need to be maintained during the building and migration phases.  And the tenants of that swamp might not necessarily be perfectly behaved tenants when they move to the castle.

So, as network designers we need to be extremely considerate of what has gone before and what needs to co-habit with our new shiny networks, and we need to be mindful that in order for them to coexist, compromises - both technical and operational - are likely to be needed to be made.  Pragmatism becomes a very desirable characteristic of a network architect, often a result of years of experience of implementing, integrating and migrating services and users between networks, and always stemming from being sympathetic to user requirement and perception.

As always, interested to hear your thoughts on this!

Previous> Simplicity

Next> Index