I probably should start by pointing out that this, and in fact most of my posts are expressed in a Network and/or Security lens, as those are my domains of specialty, however they may and hopefully are still relevant to other IT domains.
When discussing principles and processes I try and not be constrained to a silo, as one of the issues I see in the IT industry is that practitioners are typically focused on only their silo and I strongly feel that whilst having strengths in specific domains is fine, one should always strive to break down silos and understand other perspectives.
Anyway, back to the point…
Typically when performing Network and Security Architecture you are working in an environment that has an existing network and/or security devices deployed.
Therefore you need to be able to quickly get a lay of the land and work with, and within, the existing tools and processes that are provided. This is not always easy as anyone that is responsible for designing and recommending the deployment of new technologies will know, one of the hardest discussions with the business, is explaining the reasons they should spend more money to replace something that, may for the most part, currently be working fine.
You know, if it ant broke, don’t fix it. For the most part I would agree, however from experience most businesses do not even know when something is broken, and by this I don’t just mean it does not perform it’s primary function correctly; for example a firewall may be adequately blocking everything other than HTTP (port 80). However if the code has vulnerabilities or if the fail-over mechanism is buggy, or the firewall introduces significant latency, or it cannot inspect and determine that the port 80 traffic which it is permitting is actually valid HTTP, then the technology from a business perspective may be broken and thus needs to be addressed.
Inversely if you start recommending that every piece of technology be replaced with the latest and greatest you are not likely to last long either.
Therefore a key objective, once you have obtained all your required inputs, business goals, strategy, compliance, etc is to try and get the best of the existing technology and augment it where needed to address the most significant pain points and gain the most benefit.
When I plan the Network and Security architectural process I will follow, which will hopefully be implemented by the business I typically use the following high level process:
One thought on “Thoughts on IT Architecture Process”