5 key Architectural Principles that should drive Architectural Target Models and Deployment.
| Architecture Principle 1
|
|
| Name
|
Simplicity: An Architecture must be simple (not simplistic); coherent, logical and understandable |
| 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 |
| Implication | Simplicity entails a reduction of complexity, multi-platforms, complex inter-dependencies, complicated integrations and overly elaborate target models.
|
| Architecture Principle 2
|
|
| Name
|
End User neutral. An Architecture must not impact the End User in a negative way, or require the End User to face disruption. |
| 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 impacted in a negative way, does not have a negative experience from an IT deployment, and does not face disruption from an IT project. Architects need to keep this principle in mind when building Target Operating Models. |
| Rationale
|
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 3
|
|
| Name
|
Satisfy Stakeholder demands and concerns. |
| Statement
|
An architect and the target model should be able to answer the most important question: ‘Does the architecture satisfy stakeholder concerns?’. 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. |
| 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 |
| 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.
|
| Architecture Principle 4
|
|
| Name
|
SMART – Specific Measureable Actionable Relevant Time-bound |
| Statement
|
Architecture deliverables and workpackages must conform to SMART. When creating deliverables, or work artifacts, which make up an architecture, we need to move from the generic to the SMART. All migrations, deployments and workpackages within both, must follow SMART and be shared with the Stakeholders. |
| Rationale
|
The following are business and IT reasons why SMART is necessary:
-Part of the Stakeholder Matrix and buy-in -Increases the chances of timely and relevant delivery -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 5
|
|
| 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:
-Part of the Stakeholder Matrix and buy-in -A key business driver to move to the Cloud should be enhanced security (vs what exists today for most firms) -Is a key constraint when building or deploying applications -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.
|
very nice information about architectural-principles thanks for sharing..
I Want Details for DevOps Online Training, if you have share your blog