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:

As with most things a good place to start is with principles. There are many good references to principles on the interweb and these are just the ones I have developed which I try and use to provide guidance and consistency when doing IT architecture.

This is in no way a complete or exhaustive list of principles and it does not include rationale or detail on each principle but is rather a starting point, and as the name suggests minimalistic high level guiding principles.

Lets start by discussing at a high level what principles are:

Principles are fundamental statements, which express a belief about the future and / or future direction. They articulate the organisation’s vision and are the cornerstone for managing change. Principles provide an agreed reference or policy to be used for evaluation of alternatives and decisions.

The principles are equal in a sense that they all have to be taken into account for any decision, but their importance may vary on the particular decision to be taken.

Now with that out of the way, to the minimalist architecture principles-

General Architecture Principles

•  Components should be loosely coupled.
•  Good solutions should be re-used, not invented.
•  There shall be a single source of truth.
•  Re-use before buy, buy before build.
•  All solutions will be architectured for change.
•  All solutions should be exposed to other solutions.
•  Only vendor supported solutions will be deployed.
•  Only enough information will be provided to make informed decisions.
•  Application will be designed for reuse.
•  Information is an asset that has value and should be managed accordingly.
•  Information is protected from unauthorized use and disclosure.
•  Systems should allow information exchange encapsulating both business rules and data.
•  Services should have clearly defined boundaries.
•  Architecture and systems should be kept as simple as possible.
•  Good enough architecture is always better than perfection.
•  Functionality and business logic should be applied as early as possible.
•  Principles are not universal truths

These are the generic principles I try and use in my work when making decisions, however if a decision can be reasonably made by someone with a more narrow scope of responsibility, defer the decision to that person or group.