Solution Architecture Principles
Solution Architecture Principles
When starting on a new strategic project a team must establish their own principles and manifesto. Common statements to follow. Here is what I start with, then ask my team of developers and stakeholders to bring their input.
Architecture principles are intended to guide the governance of the architecture process encompassing the development, maintenance, and use of enterprise architecture. Whilst they are not intended to restrict the organization and can be flexed in line with strategy, they should be considered relatively inert. Changes to the principles should be considered in depth and involve all major stakeholders. In addition, the Principles should be easy to understand, robust, complete, consistent, and stable.
Security Principles
Least Privilege. A person or process is given only the minimum access rights (privileges) necessary for that person or process to complete an assigned operation. Limits the damage in case of exploited vulnerability. Rationale: A person or process should establish the proper granularity of privileges and permissions to apply this principle.
Keep It Simple, Stupid. Simple is better because the likelihood of a more significant number of vulnerabilities increases with the complexity of the software architectural design and code. Rationale: Ease of use. Maximize the upgradability and maintainability of the solution.
Leverage Existing Components. Ensure that the attack surface is not increased and no new vulnerabilities are introduced by promoting the reuse of existing software components, code, and functionality. Rationale: Reuse Microsoft Identity Platform, Microsoft 365 security components, and best practices to guarantee the best possible security to our knowledge.
Assume Breach. Verify end-to-end encryption and analytics to get visibility, drive threat detection, and improve defenses. Rationale: Minimize blast radius and segment access.
Data Principles
Focus on business goals. Data and management information supporting project decision-making is standardized and aligned with the Business Strategy. Rationale: Maximum return on investment requires information management-based decision-making to adhere to the business goals and strategic priorities.
Data has a common vocabulary. Data is defined and used consistently throughout the enterprise, with data element definitions available to all users. Rationale: Enable consistent interpretation for effective dialog and communications.
Data has an owner. Accountable business data owners (data stewards) are identified for all required data elements. Rationale: Be responsible for data ownership, quality, usage definition, and timing.
Data privacy. Personal data will be procured, stored, managed, analyzed, and disposed of in ways that meet ethical business principles and regulatory compliance. Rationale: Be ethically responsible, and manage risk associated with misrepresentation or misuse. Be regulatory and data privacy laws compliant.
Data is accessible. Data is easily accessible to users via pre-defined, self-service views supporting business roles, functions, and selected processes. Rationale: Ease of Use.
Data Security. Data is protected from unauthorized use and disclosure. In addition to the traditional aspects of national security classification, this includes, but is not limited to, the protection of pre-decisional, sensitive, source selection-sensitive, and proprietary information. Rationale: Be able to restrict the availability of classified, proprietary, and sensitive data when needed.
Applications and Integration Principles
Ease-of-Use. Applications are easy to use. The underlying technology is transparent to users so they can concentrate on their tasks. Rationale: Maximize Productivity. Ease of use is a positive incentive for the benefit of using the applications.
Minimize Customizing. Reduce customizing to an absolute minimum with clear design guidelines—configuration over customization. Rationale: Maximize the upgradability and maintainability of the solution. Optimize go-to-market readiness.
Eliminate Waste. Justify every single custom configured process step or field. Rationale: Remove rarely used process parts and areas. Reduce the noise for the user. Reduce legacy costs.
Minimize Interface Impact. Build different technical components to cater to different existing interface types for a minimum impact replacement. Rationale: Mitigate project risk caused by delays of other interface parties. Reuse existing data structures and integration methods.
Third-Party Application Principles
Adhere to Microsoft 365 3rd Party Apps Security Principles. Microsoft 365 has a clearly defined process for connecting 3rd party applications. We must adhere to the process to ensure the system is secure. Rationale: Follow Microsoft 365 security best practices to maximize security.
Configuration over Customization. Microsoft 365 as a service offers an excellent range of features. If the feature is available and can be configured, do it. On the other hand, custom features are hard to maintain and introduce technical depth. Rationale: Maximize the upgradability and maintainability of the solution. Optimize go-to-market readiness.
Leverage Existing 3rd App Integrations. Microsoft 365 has a broad ecosystem of apps, connectors, and services that can be reused. Rationale: Maximize the upgradability and maintainability of the solution. Optimize go-to-market readiness.
No-Code over Bespoke Development. No-Code Solutions development is quicker, easy to upgrade and maintain, and introduces less technical depth than bespoke development. Rationale: The intention is to maximize the upgradability and maintainability of the solution. Optimize go-to-market readiness.
Business Principles
User experience over technology and tools. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Rationale: The intention is to provide the best possible user experience.
Customer collaboration over contract negotiation. A face-to-face conversation is the most efficient and effective method of conveying information to and within a development team. Rationale: Quicker decision-making.
Responding to change over following a plan. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Rationale: Maximize business outcomes.
Ensure Business Continuity. Businesses should keep operating without interruptions. Rationale: No tool or system should slow down the business process.
Responsive Change Management. Changes to the information environment are implemented promptly. Rationale: The information environment must be responsive to the user's needs.
I borrowed many of these.
Software principles have been around for a while. However, most of the above principles are taken from different sources. Therefore, I felt responsible for sharing with you so you can get more information:
Least Privilege - Principle of least privilege - Wikipedia
Keep it Simple, Stupid - KISS principle – Wikipedia
Leverage Existing Components - DevGuide/01-Principles of Security Engineering.md at master · OWASP/DevGuide · GitHub
Microsoft 365 Zero Trust - Zero Trust identity and device access configurations - Microsoft 365 for enterprise - Office 365 | Microsoft Learn