Intro to M365 Maturity Model
Installing a software application doesn't instantly confer all of the benefits of increased efficiency and process streamlining as outlined in the marketing material. The larger and more complex the system, the more that is required from an organization implementing it to realize the benefits and return on investment. The Microsoft 365 platform is a vast ecosystem encompassing multiple products, and fully utilizing its features goes way beyond just knowing how to operate the software. The Microsoft 365 Maturity Model is a framework used to assess an organization's business processes and cultural readiness to embrace the 365 platform. This course outlines that framework and how it is applied to gauge an organization's level of preparedness to achieve maximal benefit from the Microsoft 365 range of applications and services.
- Learn what the Microsoft 365 Maturity Model is
- Learn how the Microsoft 365 Maturity Model works
- Learn how the Microsoft 365 Maturity Model is applied
This course is intended for students who want to know about the Microsoft 365 Maturity Model and its use. Students who plan to take the MS-600 exam: Building Applications and Solutions with Microsoft 365 Core Services need to know about the 365 Maturity Model and its relevance to an organization's business processes and culture.
Students must be acquainted with the Microsoft 365 suite of products and services. You don't need to know about every aspect of the 365 platform in-depth, but you should know the intended use of each product and service.
Customization and development is the other competency I want to drill into, paying attention to no-Code and low-Code options. Power Apps can be used by non-professional or citizen developers to create low-code solutions at a local or department level. These apps can be treated as prototypes. If the app gains traction across the organization, a pro developer can transform it into an enterprise app, implementing proper security and coding standards.
As M365 platforms evolve, no-code configuration has become more extensive and sophisticated, but at Level 100, the various systems run as is, out of the box, with little to no configuration. Both low and pro code solutions don't use source control, and there is little to no documentation. At this initial level, low code solutions tend to be built without understanding how Power Platform or Azure Logic apps are properly integrated. Low code solutions are often adapted code sourced from the internet, resulting in poor design and performance. Pro code developers try to apply non-M365 solutions and end up re-inventing the wheel. Except the wheel is oval and inefficient as they haven't correctly leveraged the various APIs or are using M365 systems just as a data source.
At level 200, all code types start to use some kind of source code control, even if it is manual, like copying different versions to OneDrive. There is some configuration, but it's pretty hit and miss due to little product knowledge. Configuration is primarily driven by attempts to re-created existing or pre-M365 systems. Low-code citizen developers gain experience, and there is a realization that using dedicated development and test environments is far less disruptive to business operations. Depending on citizen developers' skills, projects may be outsourced to external developers to get the job done quickly with fewer bugs. Pro-code M365 development is treated as a second-class citizen and squeezed in around what is viewed as real software projects. Pro developers begin to understand the M365 development paradigm, but not all embrace best practices.
Level 200 is characterized by wasting time and money as citizen and pro developers get their bearings. This is particularly true for pro developers, who tend to look down on low-code development and don't understand what it can achieve. The net result is low quality and inconsistent solutions.
At level 300, the no and low code development processes are formalized with requirement gathering, specifications, and a solution outcome description. Functional and user documentation is created. There is greater source control use and development, user acceptance, and production environments are enforced. There is a realization that, in some instances, it is better and easier to change business processes rather than conduct extensive customization. This is an important point, especially when going from manual systems to ones that offer high levels of automation. Potential pro-code projects are critically evaluated to see if the same outcome can be more efficiently achieved with a no or low code approach. Pro-code solutions are mostly deployed manually, although there is some use of CI/CD pipelines.
At level 400, no-code documentation is complete enough to be used as the basis for templates and scripts to automate SharePoint site creation. Solution designs consider the organization as a whole, adopting a consistent user interface, including company branding. No-code developers have extensive product knowledge but also know the limits of their expertise. IT support staff are trained in platform configuration to reduce dependence on "product experts." There is a trickle-down of pro-code development practices to low-code development, in a good way, and custom pro-code components are incorporated into low-code solutions. Both low and pro code solution adoption is monitored with Application Insights. These metrics are used to evaluate the solution uptake and success objectively. Instead of building complete solutions, pro-code developers concentrate on component development to augment low-code solutions, enabling modular solutions with more code reuse.
Level 500 No-code developers store scripts and templates in repositories. No-code solutions are encouraged to drive down costs and spread the development load. No-code developers can build sophisticated solutions by incorporating pre-built Power Platform Apps, Azure Logic Apps, and Dataverse for Teams components. The flip side of this strategy to enhanced no-code development is low, and pro code developers are actively encouraged to build modular components to increase code reuse. Pro-code developers build custom connectors and endpoints, and low-code citizen developers are upskilled and encouraged to use pro-code components.
Hallam is a software architect with over 20 years experience across a wide range of industries. He began his software career as a Delphi/Interbase disciple but changed his allegiance to Microsoft with its deep and broad ecosystem. While Hallam has designed and crafted custom software utilizing web, mobile and desktop technologies, good quality reliable data is the key to a successful solution. The challenge of quickly turning data into useful information for digestion by humans and machines has led Hallam to specialize in database design and process automation. Showing customers how leverage new technology to change and improve their business processes is one of the key drivers keeping Hallam coming back to the keyboard.