So you have the business requirements from a customer and have garnered the requirement information that will allow you yo formulate a high level design. What do you do now? How do you distill this information into something that will provide the nod required to proceed along the procurement path?
You have your list of outcomes, constraints and assumptions, and you know generally what ballpark figure you might be working with. As most engineers can attest to, your mind is racing off to solution mode with an end state solidifying within the grey matter. Hold on just a little bit before we go any further. It is important that the following is considered and referred back to during each stage of the process.
- Fit for purpose?
- Does this technology solving business requirements?
- Does this design allow simplicity where possible?
- Does this design allow delivery of smaller failure domains?
- Can I sight reference architecture to aid myself in business win?
Fit for purpose is a massive statement that can be broken down a few ways. Firstly, the ability to understand what the customer may not and outlay this to them in a way that is consumable. For example, a firewall A may deliver x,y,z, just meeting requirements, and be under budget though considerations may not be given to current industry threats against internet facing firewalls. Highlighting that firewall B can deliver x,y,z, a and has a feature set aligned to internet facing firewalls for a percentage more in price could be of interest to the customer. Personally, I do not see this as up-selling. This for me, is sharing your knowledge and expertise in the industry and providing the customer with the best information on hand at the time. Secondly, understanding that capability oversell is bad. Something that is grossly over specced yet meets the business requirements is not fit for purpose. I personally know of an instance where something like an SRX240 or ASA5515x would have sufficed yet the customer wound up with 5585-X SSP10. Go have a look at the feature list and price difference. Justifiable? Hardly.
Technology enablement that directly correlates to business requirements should become second nature. I draw again to compliance as a reference point. If it is outlined that isolation, inspection, and reporting are required then quickly one can draw a link to virtualisation, IDS/IPS technologies, and AAA functionality. How they are install and what features are enabled may be outlined upon further investigation with a customer or they could require you to aid them in this. If you are to aid them in seeking compliance then you can find many vendors publish how to reach standards such as PCI, HIPAA, or Sarbanes Oxley. Reaching an internal standard set by a customer will require a sound understanding and ensuring what you’re implementing puts ticks in their boxes.
A big core belief of mine and something I propose to many people is to design simple. Business constraints and assumptions will dictate the scale of simplicity in the network. Where possible design for simplicity when meeting business requirements. When you cannot and additional technologies and devices add layers of perceived complexity, one must design smaller failure domains. Ensure you leverage HA technologies where possible, implement deterministic scenarios of device and configuration failure. When you design small failure domains with HA technologies your architecture adopts a form of resiliency. It is very common to find environments comprised of the best technology on the market with multiple single points of failure in one large failure domain. Simple and Small failure domains will bring you into a new era of resiliency. For some customers this might be real resiliency for the first time.
No one is expected to remember every detail from every vendor though not being resourceful can only be forgiven few times. Vendors publish best use cases, reference architectures (we need more Juniper), and solution guides and designs for all products. Some actually work with a plethora of devices to deliver an architecture. Understanding how to consume these documents will allow you to deliver strong, tested, and proven device and technology combinations to achieve a desired business objective. These documents also aid in customer discussions to provide reassurance and vendor stamped clarity.
Knowing how to be resourceful, understanding technology use cases, and binding this all together is what the customer has engaged you for. Understanding the technology ‘triple-plays’ and subtle nuances of technology and vendor products is what helps you build the bridge to a successful project for a customer. Strong understanding of business requirements, vendor products, customer engagement methods, and network architectures all play their part in interpreting specifications and requirements.