In my last post I discussed the first part of the Architects job namely to create a Vision for the future state of the infrastructure based on business needs and requirements.
In this blog I want to go into the second piece of work the architect has to create being the Strategy.
The Architect as Strategist
In essence the strategy (or roadmap) chronicles how the organisation can move from the current situation (AS-IS) to the state described in the vision (SOLL).
When creating this strategy there are a number of areas the architect must cover and I’ll be going over these parts in turn starting out with our favourite: technology.
Before you get too exited, in this context the term technology refers to generalized product groups such as: switches, routers, load balancers and Next Generation Firewalls.
In the vision we described (at a very high level) the main functions required to build the vision (during the vision stage we already had to consider some general technology areas to verify if the required functions are actually technically feasible).
Functions on their own however do not prescribe technology but instead are used to determine if a technology has the right set of “features” to achieve our goals.
So let’s look at a couple of examples of functions and how they can help in determining technology:
Let’s assume we have the function “a means of exchanging reachability information” (yes that does sound an awful lot like plain old routing). At this level the function is “disconnected” from specific technology or implementations so we know we need routing where just don’t yet know which protocol we need.
If a function is too high level we can further flesh it out by describing (as functions) specific parts that need to be addressed (for instance “a means of limiting the failure in one area from directly affecting other areas of the infra” (think flooding and summarization)).
We can also apply architecture principles to help in determining technology.
Principles can help the architect in settings some “ground rules” that should always be applied, common examples include “protocols should be vendor agnostic” or ” buy before build”
Hang on a minute I’ve never heard a business owner ask about reachability information? True we have taking the business requirement “being able to access our services from our offices (or at home)” and broking it down into manageable functions.
The above requirement for instance besides routing also implies we have a function that provides “off premise controlled access to services” (remote access) and “connectivity to remote offices” (WAN).
As you might have guessed translating business requirements into functions can be a bit of a challenge and in some cases we need to add in functions we feel to be required (such as DNS or NTP).
Let’s look at another example: “a means of controlling access to services”, if you are thinking RBAC slow down this is about how consumer access a service, access within a service is another function.
Now if I ask a network admin about access control 9 out 10 times they’ll respond with ACL’s or firewall policies, if I ask a server admin they might reply with LDAP or AD so already I have multiple technologies working at different levels of the stack each with their own strengths and drawbacks.
In my previous blog on visions I mentioned for instance the Next Generation Firewall which actually can combine the trusted ACL with AD information making for a more flexible (less static) means of controlling access to services.
So by taking all the functions we can start talking to various teams within the organisation and together start mapping them against existing technology (or decide for which bits we need a bake-off or POC).
However we need to be mindful about at which layer of the stack we need what technology (or maybe we need to apply technology at multiple layers such as we see in defence in depth strategies).
One very important component that goes with this part of the strategy is what I tend to call the “cost of complexity” which refers to the operational cost (and possible technical debt incurred) by creating something overly complex (KISS anyone?).
I can highly recommend reading some of Russ White’s blogs on matters of complexity (and his books) to get a more sound understanding of this subject (it has real world implications though and so we should be very mindful when making choices for technology).
We are always looking for the lowest operational cost, lowest complexity, lowest technical debt and so on, however in the end we will need to make tradeoffs.
RFC1925 rule 7 (Good, fast, cheap: choose two) is a prime example of the types of tradeoffs we must make.
As a final though here is a quote from Russ White on tradeoffs:
if you don’t see the tradeoff, then you’re not looking hard enough
Breaking down the ivory tower.
So how do you feel about complexity and some of the tradeoffs made in your network, would you make some choices differently or even have some ideas about going in a different direction?
Let your architect know and have a good discussion looking at things as complexity, technical debt and requirements.
The next blog will continue with the strategy but look at some of the other fundamental parts we need to address.
Please feel free to leave a comment if you feel I’ve missed something vital or if you feel there is a better way of creating a strategy.