Pillars of a great architecture
The cloud has changed how business applications for organizations are designed and implemented. As a result, solution architectures can now be pulled together from one or more SaaS services that are working together to form a complete solution. In solving customer's business problems, solution architects should be comfortable using the following services to build their overall solution:
Dynamics 365
Microsoft 365
AppSource
Extending with Microsoft Power Platform
Microsoft Azure (used to fill in the remaining gaps)
Microsoft Copilot
Design a great business application solution
While one single blueprint doesn't exist for illustrating what a great business application solution architecture looks like, certain concepts apply, regardless of the unique customer challenges that you're solving. While the following sections don't provide a complete list, focusing on these concepts helps you build better overall solutions.
Security
Data is one of the most valuable assets of an organization, and ensuring proper use and access to this data is essential. In the security pillar, you're focused on securing access to your architecture through authentication and protecting your application and data from network vulnerabilities. This process includes ensuring that you're working with the appropriate teams to enable features like Azure Conditional Access and Data Loss Prevention policies. Additionally, you confirm appropriate use of your solution of secrets, certificates, and other techniques to ensure that access to data and services don't fall into the wrong hands.
You must think about security throughout the entire life cycle of your application, from design and implementation to deployment and operations.
Customers entrust their data to your organization; you must ensure that only the right users have access. Beyond perimeter control through authentication, you must implement a security model that enforces access to the data that users are allowed to use. You must ensure that the security constructs that are established don't place undue burden on your architects and prevent staff from doing their job, thus making the system unmaintainable.
Empowering end users
Fundamental to any solution architecture that is Microsoft Power Platform centric should be the consideration of how to empower the full organization to innovate and build the extensions that they need to be productive. Instead of thinking about how you can lock a solution architecture down to prevent creative users from building their own tools, think about how you can encourage the practice and establish guardrails as part of your architecture to prevent the tools from causing problems. This approach can often include providing user-focused connectors or reusable Power Apps components that people could use to quickly build their own tools to help them in their daily productivity. Templates, starter apps, and even helping to establish a center of excellence by using the Microsoft-provided starter kit can go a long way in helping to promote user empowerment.
Trust and privacy
Compliance requirements can vary greatly from industry to industry and across geographic locations. Exceptional solution architectures ensure that their solutions meet their requirements. Microsoft provides tools and capabilities to help customers implement solutions that are compliant, but solution architects must take steps to ensure that the architectures they establish implement the necessary aspects. This verification includes making sure that organizations can handle privacy regulation requests. Microsoft publishes a trust center that solution architects should be familiar with. The trust center helps solution architects locate the certifications and capabilities for each of the Microsoft products that they use.
Maintainability of the overall solution
Solution architects should focus on solving challenges by using the customization capabilities of the platform and applications over custom code that is more difficult and more expensive to maintain. Microsoft Power Platform is updated regularly, and architects should confirm that only supported customizations are used to ensure that updates don't break their solutions. Additionally, the solution architect should ensure that the architecture and technical implementations are documented and commented on so that future maintenance is easier to complete. Solution architects should strive to minimize technical debt that would require future cleanup.
Availability and recoverability
An architect's worst fear is having the solution fail with no way to recover it. A successful cloud environment is designed in a way that anticipates failure at all levels. Part of anticipating these failures is designing a system that can recover from the failure within the time that is required by your stakeholders and customers. Solution architects should be familiar with each of the applications that are included in their solutions and their recovery capabilities. Integrations across system boundaries should receive extra attention to ensure that one component doesn't cause the entire solution to unnecessarily fail. Solution architects should recommend monitoring solutions and provide proactive tools to allow measuring and reacting to problems.
Performance and scalability
For an architecture to perform well and be scalable, it should properly match resource capacity to demand. Traditionally, cloud architectures do so by scaling applications dynamically based on activity in the application. The solution architect must help the operation team identify the capacity that is required of the components that make up the solution architecture. The architect is responsible for including components that can meet user requirements for response time for the critical parts of the system.
Efficiency and operations
You want to design your cloud environment so that it's cost-effective to operate and develop against. Inefficiency and waste in cloud spending should be identified to ensure that you're spending money where you can make the greatest use of it. You need to have a good monitoring architecture in place so that you can detect failures and problems before they happen or, at a minimum, before your customers notice. This process can be challenging for the solution architect when the raw data might exist in one or more individual services. To have some visibility into how your application is using its available resources, you need to have a robust monitoring framework.
Shared responsibility
Moving to the cloud introduces a model of shared responsibility. In this model, your cloud provider manages certain aspects of your application, leaving you with the remaining responsibility. In an on-premises environment, you're responsible for everything. This shared responsibility plays a role in your architectural decisions because they can have implications on cost, operational capabilities, security, and the technical capabilities of your application. By shifting these responsibilities to your provider, you can focus on bringing value to your business and move away from activities that aren't a core business function.
Design choices
In an ideal architecture, you would build the most secure, high performance, highly available, and efficient environment possible. However, as with everything, there are trade-offs. Building an environment with the highest level of all these pillars involves cost. That cost might be in actual money, time to deliver, or operational agility. Every organization has different priorities that affect the design choices that are made in each pillar. As you design your architecture, you need to determine what trade-offs are acceptable and which aren't.
When building a business application solution architecture, you must keep many considerations in mind. You want your architecture to be secure, scalable, available, and recoverable. To attain that goal, you need to make decisions based on cost, organizational priorities, and risk.