10 key Architectural Principles that should drive Architectural Target Models and Deployment.
Architecture Principle 1: Use Agile methods to Align IS to the Business Strategy and purpose
Name
Alignment which is Domain based using Agile methods which are simply this: hands-on, iterative work, with a business owner involved, to find the best solution.
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. Use Agile and iteration (no blame, no shame) to find the best solution.
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 based on Agile learning: -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 Agile 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.
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 3rd 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 3rd. This must be properly budgeted and tested. Testing HA is difficult, but it can be done via scripts and automated during periods of downtime.
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 3rd 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 3rd parties.
Architecture Principle 10: Environmental Standardisation using Automation including Infrastructure as Code
Name
Templates and Automation to ensure commonality within environments
Statement
This principle relates to best practices and environmental management. Environments should be similar across accounts, regions or nodes. An example would be Infrastructure as Code. Using YAML or JSON templates we can create standard and automated deployments and stacks across nodes, regions or Data centres.
Rationale
Firms should embed standards and principles within templates which are then used to deploy environments across different deployments ensuring that common approaches and principles are implemented.
Implication
Templates in JSON or YAML are built to deploy Stacks across environments. Instances are thereby controlled, conforming to company standards. Administrators must manage, update, edit and control the Templates and Stack-sets.