9 key Architectural Principles that should drive Architectural Target Models and Deployment.

Architecture Principle 1: Align IS to the Business Strategy and purpose

Name

Alignment which is Domain based.

Statement

IT or IS exists to support a business purpose. Systems must conform to business processes and strategies and allow the business to achieve its objectives.

Rationale

The business strategy and related processes needs to be mapped back to IT assets. This principle relates to the 2nd principle of simplicity. Alignment:

-Business processes and strategy (ies) are documented

-These strategies are translated into technical architectures, solutions and flows (UML, Conceptual, Logical, Detailed)

-IS directly support business KPIs and business views IS as a partner

-IS not viewed as a silo, a cost-centre or a basement operation where strange guys eat pizza and drink soda who could use hair-cuts and new clothes

-IS will use POCs and other techniques to map the business logic back to stakeholder demands and objectives

Implication

Agile teams are best suited to mapping domain logic and business flows into technical architectures. Firms could even task IS or IT with revenue targets, or at least, culturally embed business into IT. Strategy setting uses IT as a key enabler and partner.

Architecture Principle 2: Simplicity

Name

Simple Design.

Statement

The simpler and more elegant a target architecture is; the easier it will be to explain, affirm and receive stakeholder blessing. The meaning of ‘simple’ is not simplistic. It refers to the concept that architectures are more easily developed, deployed and supported, if they are understandable and coherent.

Rationale

The following are business and IT reasons why a simple, yet coherent Architecture is necessary:

-Faster deployment times

-Reduced overall cost

-Easier to explain to Stakeholders

-Easier to modify and extend in the future

-Easier to operationally support and document

Implication

Simplicity entails a reduction of complexity, multi-platforms, complex inter-dependencies, complicated integrations and overly elaborate target models.

Architecture Principle 3: Limit End User Impact

Name

End User neutral.

Statement

A deployed Architecture needs to consider first and foremost, the actor called ‘End User’. A key principle on IT projects is that the End User is not impact in a negative way, or prevented from doing their work. This also means that any ‘personal’ artefacts including files, spreadsheets or email is not disrupted or lost. Architects need to keep this principle in mind when building Target Operating Models.

Rationale

An Architecture must not impact the End User in a negative way, or require the End User to face disruption.

The following are business and IT reasons why End Users should not face disruption, or negative impact:

-If disrupted the End Users will declare the project a failure

-Will be more difficult to get the project funded or paid for

-Increases overall costs to fix what went wrong

-Will lose Stakeholder support

-Business, clients and regulatory agencies and responsibilities could be severely impacted

Implication

A core concept in Architecture is to please the End User. Business scenario modelling, requirements elicitation, understanding End User viewpoints and concerns is mandatory on any IT project. They must also be involved in requirements-design and testing; and sign off on a development deployment, before it goes into production.

Architecture Principle 4: Stakeholder Satisfaction

Name

Satisfy Stakeholder demands and concerns. Related to Principle 3 but more expansive.

Statement

An architect and the target model should be able to answer the most important question: ‘Does the architecture satisfy stakeholder concerns and differing viewpoints of what the system should deliver?’. This does not mean that all stakeholders opinions or ideas are reflected in the architecture’s target model. Rather, it means that the core concerns, which inform viewpoints and views into the system are satisfied by the architecture and are agreed upon by the Stakeholder community including End-users.

Rationale

The following are business and IT reasons why Architectures must satisfy stakeholders:

-Helps with buy-in and compliance

-Reduces the risk that the architecture and IT project will fail

-Leads to an easier path to modify and extend in the future

-Generates business value which can be measured (ROI)

Implication

Stakeholder satisfaction is a core component of building IT architectures. If the stakeholders are unhappy it is unlikely that the system will be used or trusted. This means the HLD should have a stakeholder matrix including their viewpoints, objectives, issues.

Architecture Principle 5: SMART projects

Name

SMART – Specific Measurable Actionable Relevant Time-bound

Statement

Architecture deliverables and work packages must conform to SMART. When creating deliverables, or work artefacts, which make up an architecture, we need to move from the generic to the SMART.

Rationale

The following are business and IT reasons why SMART is necessary:

-Domain driven development is key to success which SMART satisfies

-Do not make the project vague, multi-domain, or too complex, break it down into defined streams of work, which a smaller team (<9 people) can reasonably manage and implement

-Domain is the business logic that needs to be built

-Domain knowledge lies with key Stakeholders, SMEs and their buy-in

-SMART needs to be based on the Domain and its logic which the client SMEs will know (or it needs to be discovered)

-Leads to a granular and detailed architecture design

-Generates business value by focusing on tangible delivery

Implication

SMART is essential when deploying an architecture or sub-components within the Architecture. Being specific, clear, relevant and time-bound is necessary to meet deadlines and add value.

Architecture Principle 6: Security

Name

Security. The system must be secure at all levels of the OSI stack.

Statement

Security is at the core of IT and Cloud design. Security models must be built into the Architecture and satisfy Stakeholder and Role demands. The Security model for a Cloud deployment should reflect best practices and be tested both internally and externally for proper compliance.

Rationale

The following are business and IT reasons why Security must be built into a Cloud architecture from the beginning:

-Encrypt everywhere

-Zero Trust, Zero Tolerance

-PAM (privileged access management to key resources, environments

-Outside in and inside out security – example, perimeter, WAF, DDOS, DMZ, network, IDS, port access, white/black listing of IPs, monitoring, alerting

-Security model is built into the first design and is agreed with the CISO

-Part of compliance and regulatory responsibility (includes GDPR for eg)

Implication

Security within the entire OSI stack means that the Architecting team will need to model security concerns from the beginning which will lead to certain architectural choices or options, being rejected. A key implication is that SMEs from the various OSI levels will need to be involved in order to determine what level of security, and which granular security products or services, should be implemented.

Architecture Principle 7: Redundancy, HA

Name

HA-Redundancy.

Statement

There is no single point of failure. Systems have automated fail-over to a second set of virtual servers and resources. All images, data, are backed-up to another platform which is not the target platform (eg all data, images, from AWS backed up to Azure). Data and Image snapshots are taken daily and backed-up. Failover entails a seamless and automated use of a secondary VM, server or application node, when the primary fails.

Rationale

The following are business and IT reasons why HA-Redundancy must be built into a Cloud architecture from the beginning:

-Access, Application data usage must be 99.9999 available

-HA entails data DB replication between 2 DCs or 2 AZ’s in the cloud

-Automated snapshots are mandatory and images, code must be kept in a 3^rd DC for cold backup and restore (DR)

-HA impacts security and the security model must be built assuming HA

Implication

HA and Redundancy is a mandatory principle. This means 2 distinct data centres with backup in a 3^rd. This must be properly budgeted and tested. Testing HA is difficult, but it can be done via scripts and automated during periods of downtime.

Architecture Principle 8: Non-Functional Requirements
Name	NFR related to Principle 6 HA-Redundancy.
Statement	NFRs include performance, capacity, extensibility, open architecture, scalability, security, redundancy, backup, system management, usability, business and compliance constraints, standardisation (tools, platforms, stack).
Rationale	Every system has the above NFRs expected or to satisfy. These NFRs should inform, design, testing and approval processes.
Implication	Satisfying NFRs assume the use of Agile where for example, End Users are involved in testing to confirm the NFRs are met. They must be discovered, known, written down and agreed upon by the organisation as key principles of deployment or migration. This means having a comprehensive checklist for every NFR area listed above. Every app deployment needs to satisfy this list and be confirmed by the ARB before deploying into production.

Architecture Principle 9: Ownership
Name	Ownership of processes, technologies, outcomes
Statement	This principle relates to control. If the SI’s team including the EA, ‘own’ the artefacts, processes, access, and related technologies they should be responsible for the outcome.
Rationale	If there are 3^rd parties, unwilling or oppositional stakeholders, or a reliance on external parties, the risks to a successful outcome are vastly multiplied and need to be reflected in the RAID and assessed rationally.
Implication	Within IS-Business alignment, various stakeholder, external and internal party concerns can drastically impact time, budget, client happiness and project success. The key principle is this: the more ‘we’ control, the greater the chance of success. ‘Total’ control is rarely possible, but an EA should try to ensure that clear ownership of processes, technologies, and workloads are established and independent, as much as is possible, from uncontrollable 3^rd parties.

==END