IT infrastructure principles

This is some thoughts about good general principles on IT infrastructure. The principles are my personal thoughts, but are in content and structure inspired by TOGAF Architecture Principles
(pubs.opengroup.org/architecture/togaf9-doc/arch/chap23.html) from TOGAF 9.1.

Principle: Comply or Explain

Statement; Each solution or architectural element should comply with these principles. If it is not possible the deviation must be documented with motivations.

Rationale; This principle enforce these principles, and make sure they are continuously evaluated.

Implications; All architectural elements are documented thoroughly in a really useful way, that really can be used in future development and governance of the system.

Principle: Business Support

Statement; Each architectural element must support business. Not only the current business but also the future business.

Rationale; The architecture is sponsored by business and then should support business.

Implications; The architecture, the processes or the technology must have business as primary subject.
Data available and systems running (continuity). Easy and direct access to information.

Principle: Compliance

Statement; Each component, element and the combined solution must comply with both law (national and international), regulations and audit (internal and external).

Rationale; This is to protect the organisation, senior management and board from legal, economical or reputational consequences.

Implications; Business, audit, management, development and operation must coorporate to ensure compliance in all details. This will usually involve several different areas like organisation, procedures and technology. Each person must have ownership.

Principle: Secure by Design

(collection point of security principles?)
Attack Surface Reduction
Threat Modelling
"Microsoft Security Development Lifecycle" (https://www.microsoft.com/en-us/sdl/)

The Microsoft presentation „Basics of Secure Design Development Test“ has many interesting points. E.g. a rather well formulated description of a asymmetric problem:
We must be 100 % correct, 100 % of the time, on a schedule, with limited resources, only knowing what we know today.
- And the product has to be reliable, supportable, compatible, manageable, affordable, accessible, usable, global, doable, deployable...
They can spend as long as they like to find one bug, with the benefit of future research.

Cost for attacker to build attack is very low
Cost to your users is very high
Cost of reacting is higher than cost of defending

Principle: Protect data

Statement; Protect both data at rest and data in transport.

Rationale; Data are vital to the organisation and it's business, and protection of data must have very high priority.

Implications; classify data, classify risk, encryption

Principle: Reduce Complexity

Statement; Assign and enable only requires components to the system. Enable only on the required feature level.

Rationale; Complexity overhead generates extra administration and governance, and makes operations and problem analysis more complex.
Acquiring or assigning unused resources adds unnecessary cost.

Implications; Allocate only required resources to each service, e.g. processor, storage or memory. Install and enable only required services, e.g. Full Text features or Integration Services only when direct required. This is also an economic issue like on license.
This principle is often described in other similar but partial principles like "Least Service" or "Least Resource":

• Least Service; install only services that are actually needed on each component, e.g. only RDBMS on a database server and management tools on other computers. There might also be an economic issue, e.g. on license.
• Least Resource; Allocate only required resources to each service, e.g. processor, storage or memory. This is also an economic issue like on license.

Principle: Least Privilege

Statement; Security principle to minimize risk to data exposure.

Rationale; Protect the data and reduce risk.

Implications; Do not use default security groups. Only grant minimum access and rights. Fine grained security model on all roles.

Principle: Segregation of duties

Statement; Security, Audit

Rationale;

Implications; Role Based Access Control (RBAC) on the system - not the resource.

Principle: Defense in Depth

Statement; Security, Compliance

Rationale;

Implications; segmentation, precise defined layers, each component is hardened.

Principle: Automation

Statement; automate as much as possible. That is about every thing but the decision itself.

Rationale; with automation the infrastructure and architectual components above like platform or application will be handled both with stability and quick response. If there is a enterprise principle on agility the automation is a requirement.

Implications; standards, Root Cause Analysis (RCA) and real fix.
Consider to stride for a production environment without human admins. Later this can be evolved to other environments.

Principle: Scalability

Statement; architect for scale. That is on all aspects such as capacity, response time, geographic and integration.

Rationale;

Implications;

Principle: Easy Exit

Statement; choose the solution that is the most easy to leave.

Rationale; when a solution is tight coupled to a single technology or product then it will be very difficult and costly to migrate the system to another solution.

Implications; you might look more at open formats if you rate this principle high in a given challenge.