Preparing for Change in Your Design
Preface and Philosophy
In these last chapters I am going to turn back to explain more fully why the title of the book, and to think a little about why you picked up the book to read it. I will try to guess what it was you sought from these pages and, admittedly, be making a few obvious assumptions about those things. I am also going to try to offer some thoughts on “how to lay the foundations for a good CDN implementation” and all the work that entails, while writing from as generic a perspective as possible to meet the many different expectations of the readers this book may reach.
This commentary should be viewed purely as an insight into my way of doing things. It is certainly not a “how to” guide for best practice. There are many engineering consultants who can almost certainly offer a more disciplined approach, and indeed 25 years ago I spent studying systems engineering - in particular “decision support” systems - as I was developing computer telephony integration (CTI) for some early call centers I ashamedly built (and I have never quite lived down the guilt!). The analytical design process is fascinating in its own right and can provide a great resource in certain contexts.
In practice, however, I have come to my own conclusion that such disciplined models, if overly enforced, solve the problem that they were designed to solve, but not the particular problem that the client in front of you requires a solution for.
As I moved into the entirely new field of CDN and streaming media, one of the things that attracted me was the utter lack of convention. The sector is young enough that it is still very results focused.
I have no MBA or indeed many other qualifications in the sector. In many ways I am a tradesperson, not a professional with portable skills. I am accustomed to practice in an area where everything is new and has no formal process. So as far as streaming media infrastructure goes, I am no great believer in best practice. For me, it is imperative to pay attention to the problem I am trying to
Content Delivery Networks: Fundamentals, Design, and Evolution, First Edition. Dom Robinson. © 2017 by John Wiley & Sons, Inc. Published 2017 by John Wiley & Sons, Inc.
solve with the CDN design. If that problem is interoperability, then I design for that. But if that problem is cost, or performance, or unique features (etc.), then I design solutions for that problem.
Yes, of course, there exist myriad common problems - and sometimes these are so common that it makes sense to create a common product as a solution. However, once the product defines the problem space, many vendors have to work with their clients to engineer expensive problems to then sell expensive solutions.
At id3as we specialize in “tailored” solutions. We do not offer off-the-peg models, and for this reason we talk of approach and capability rather than methodology and feature-set.
When designing with a client, I believe that it is essential to not be afraid to ask basic questions. As my colleague Adrian Roe says, “In a workflow running from a to b to c to d, why don't we just engineer from a to d directly?” Thinking around the problem laterally can make dramatic differences - even if they render some of the existing workflow redundant. Simplicity is invariably easier to deliver and support.
With this approach you can simplify vast, seemingly complex infrastructures into much smaller components. Indeed CDNs are invariably “macros” of many moving parts that end up working in concert to perform a relatively limited set of overall functions for the wider system that they deliver to. The inputs are fairly well defined, and the outputs are invariably well defined, since that is usually why the CDN is considered to be a solution in the first place.
Internally the design should always remain simple. Visio diagrams that seem to architect the Star-Ship Enterprise in atomic detail may look impressive, and may look like you have over delivered, but in practice, you are more than likely to be including complexity, and complexity is bad, not clever.
So ask stupid questions, listen to the client really define the problem their company is trying to solve, and not just the specific problem the client has brought you in to solve. Solve the fundamental problem - critically - and don't disempower the client on the way! Ask questions that provide context, and understand the context, for in the context you will find the core business objectives for the CDN and the real constraints, or at least the perceived “real” constraints, and perhaps your design will not overwhelm the client but will show a simpler and arguably “better” path where the constraints as they were simply become irrelevant.
And one final comment is on taking a position: Always make sure the client takes “ownership.” As you do the design, once you make that critical leap yourself, do not present it as your “fait accompli” - instead help your client discover that along with you - so take your own cap in your hand and congratulate the client for the brilliant idea. In that capacity you will develop the longest relationship and have the best alignment for what is actually your design.