This title is a variation on the phrase “It’s The Economy, Stupid!” coined during Bill Clinton’s election campaign for President of the United States. His strategy emphasized the looming economic recession ignored by his opponent, and with success: he won the presidency.
This analogy is applicable to organizations who do not grasp why their Power Platform investments are not paying off (fast enough). They are laser-focused on their ambitions, but in the process not addressing the hurdles laying right in front of them. Their ambitions cause them wanting to sprint before walking, ignoring some key factors along the way.
Not Every Business Challenge Should Be Tackled with A Hammer
The reason why Power Platform investments do not pay off is quite simple: organizations – especially those that do not outgrow the early stage of Low Code Adoption – are trying to address every Business Challenge with a limited set of platform capabilities.
Without thoroughly considering the combination of the Power Platform’s capabilities with the capabilities offered by the surrounding ecosystem, and a lack of understanding the condition of the Low Code Operating Environment, this is the perfect script for non-success.
I want to emphasize that this observation is understandable for new Power Platform organizations. Therefore, this article is not meant for them but rather targeted towards those organizations who have been trying – often for many years – to reach a higher maturity level, but without any success.
Often these types of organizations consider every Business Challenge a nail that can or should be solved with a hammer. And you can guess the name of this hammer: Power Apps – and more specifically Canvas Apps. Besides that, there is a reason why we say that technology alone cannot solve business problems. And this becomes very clear for organizations that are situated in this position.
Unfortunately, this is the situation I have encountered repeatedly at many organizations. It mostly goes something like this:
Someone from a department XYZ discovers the Power Platform (through some Sales or Marketing presentation, or self-discovery) often laying the emphasis on Power Apps Canvas Apps. This interesting find is shown to Management, who becomes very excited.
Then with the blessing of Management gladly Jack and Jane from department XYZ start to build and deliver a multitude of less impressive applications intended for enterprise use (!). At some point the consumers of these Solutions start to notice the lack of performance, half-baked features, scalability issues, etcetera.
That is the moment when the IT department – who often still has a traditional developer mindset – comes in to save the day. Due to that traditional developer mindset, and their hesitancy towards the concept of Low Code No Code (LCNC) they are often also misinformed, and therefore escalating rather than solving the problem.
The outcome of this adventure is predictable: without any well-founded arguments Management decides that the Platform is not meant for enterprise scenarios, and that it cannot produce meaningful Solutions. In other words, the platform is not able or not suitable to produce Solutions that meet business expectations.
Is this recognizable? What went wrong here? Well, several things went wrong in the described approach.
Mistake 1: Lack of Platform understanding by Management and IT Leadership
Management should not agree to build Solutions at scale (Enterprise Solutions) without themselves having a conceptual understanding of the Platform’s full capabilities. Otherwise, they tend to make uninformed decisions. That is why it is highly recommended, or rather required, Management agrees to attend an introductory workshop which globally highlights the platform’s Architecture and full capabilities before they start (or continue) making (technical and organizational) decisions. I have been in several situations where uninformed decisions regarding the Power Platform resulted in significant financial and reputational damage, towards both the organization and the IT Service Provider. And quite often these harmful decisions stifled organizational innovation. It is sad to see how these organizations have squandered good opportunities and wasted valuable time and money, due to their ignorance and stubbornness.
But that is only one part of the problem. The other part of the problem is recognizing that if your organization has a conservative IT department, the latter will not be happy to see the introduction of LCNC platforms in the organization. Conservative IT departments consider LCNC platforms a threat to their sphere of influence. Why? Because LCNC Platforms enable something that was deemed impossible not so long ago: they allow non-IT personas to build and deliver Solutions of which some of these can have a lasting and organization-wide impact. So, you are the King of the Hill and suddenly someone comes along and takes the throne. Wouldn’t you feel threatened?
In this case it is up to a well-informed Management – see here why Management needs to have a good understanding of the platform’s full capabilities – to carry the change required to convince their IT department that in fact this offers new opportunities. It creates a situation where IT can spend their valuable time addressing critical Business Challenges and therefore creating added value, leaving the less critical ones up to Business Users to solve. The IT Department needs to be convinced that in fact Jack and Jane are Citizen Developers, utilizing Citizen-Driven Development techniques and approaches. Jack and Jane’s development endeavors should be focused on improving their Personal -and Team productivity. Anything beyond that is IT-Driven Development. You cannot expect remarkable results by building (critical) Enterprise Solutions based on SharePoint Lists and Canvas Apps, for example.
Below I depicted the Solution Complexity Scale, inspired by one of Carsten Groth’s many remarkable visualizations.
Then again, a conservative and mostly uninformed IT Department will be quite fast in pointing out that the Power Platform cannot be seamlessly integrated with a complex SQL setup – to name an example, and therefore the platform is not fit for Enterprise scenarios. They can make such a statement because they are thinking of that famous Canvas App hammer. This is the moment that Management needs to point out that in fact Citizen-Driven Development uses a limited set of capabilities (read: they only use the hammer). But when we talk about IT-Driven Development we are talking about a toolkit full of alternative hammers: Model-Driven Apps, Dataverse, Azure, Pro Code and Native Language support, Secure Business Websites, Third Party integrations, Microsoft 365, Dynamics 365, and many more.
And it is that toolkit of alternative hammers which I like to call the Power Platform Ecosystem. The table below lists the components that are part of this ecosystem.
| Components of the Power Platform Ecosystem | |
| Microsoft Power Platform | Full capabilities of the Microsoft Power Platform |
| Microsoft 365 | Microsoft Productivity Suite |
| Microsoft Dynamics 365 | Microsoft Business Applications Suite |
| Microsoft Azure | Microsoft Cloud Computing Platform |
| Microsoft AppSource | App Store for Microsoft Power Platform extensions and Add-Ons |
| Complementary Third-Party Solutions | Integration with complementary Third-Party Solutions |
Nick Fratello has beautifully visualized this ecosystem in 2018 and updated in 2021, calling it the Business Applications Solution Ecosystem.
In the end Business Users are domain experts, making them perfectly capable to recognize Business problems, and how to deal with them. In other words, they determine the Business Requirements, the ‘WHAT’. But Business Users (and to a certain degree uninformed IT personas) are not the ones that should build Enterprise Solutions or lead Low Code initiatives. In this case it is better to delegate the Techno-Functional realization, the ‘HOW’, and the Low Code leadership to those that are better informed and therefore better equipped to handle these tasks.
Than there is that extra dimension that Enterprise Solutions introduce: Enterprise Solution Architecture. Enterprise Solutions require an Architectural approach. The Architect and his team of IT -and Pro Developers, with input from Business Stakeholders – an approach called Fusion Development – have the necessary insights, breadth, and depth to determine which components of the Power Platform Ecosystem should be utilized as part of the Enterprise Solution.
Mistake 2: Lack of understanding the Low Code Operating Environment
Management should not dive immediately into Solutioning if it is not (yet) clear how these Solutions contribute to the Business. Having a clear Product Vision, and determining how this vision aligns to Business Strategy, Business Goals and Business Objectives, is a necessary exercise that should not be underestimated. Too often I have encountered situations in which blood, sweat and tears have been invested in producing Enterprise Solutions. But once these were released a considerably large number of features were not used. And sometimes these Solutions were abandoned in their entirety (!).
Having a Product vison is just one piece of the puzzle. You need to ensure that the conditions are created to translate that vision into a tangible Product or Service. Because sometimes you can have a Product Vision, but it cannot be realized because of an absent foundation, which I will explain next.
I was lucky enough to have participated in projects with varying size and complexity. Although they each had their unique challenges, they had one thing in common: absence of a Low Code Strategy. The Low Code Strategy is determined by answering three questions:
- Why Low Code in your organization?
- Cost Reduction, Innovation, Business Process Optimization, Self-Service, etcetera…
- Who is your target audience?
- Internal or External, Enterprise or (independent) Department(s)/Team(s), etcetera…
- How will you support your audience?
- Formal or Informal, Centre of Excellence or Centre of Enablement, etcetera…
By answering these three questions you can start thinking about the Vision and Mission of Low Code within your organization, Management -and Governance Structure, the Change Management approach, the Support Model, and the alignment of your Low Code Strategy to the Business Strategy, its objectives, and goals. Of course, I will not list all the details, as this is out of scope for this article. But this should give you an idea of the first point of attention.
Once your Low Code Strategy is in place, you need to get your platform under control; the second point of attention. Trying to build (Enterprise) Solutions on a platform spinning out of control, is a very bad idea. Before you know it, database capacity is depleted, it is not clear which environments to (not) use, security is a mess, overlapping Solutions are created, etcetera. It is the Low Code Strategy that determines how the Platform Governance – some like to call this Technical Management – will be arranged. Which feature to enable/disable, Security Groups to be utilized, Policies to be rolled out, Naming conventions, etcetera.
With the Platform Governance streamlined, the third attention point is to start thinking about enabling the type of development that occurs or will occur in your organization. This is what I like to call Low Code Governance. Low Code Governance enables all developers (Citizen Developers and IT Developers) in the organization to develop Solutions according to best practices and organizational guidelines. In other words, Low Code governance makes sure that developers are trained, educated, supported, empowered, and handed the necessary tools, to perform developer activities in a compliant manner. It is also the Low Code Governance that determines which type of Development is suitable to address the manifested Business Challenge.
A last point of attention is the development itself. In this case I am talking about Citizen-Driven Development, IT-Driven Development and Fusion Development. All three types of Development have their own approach. When your reach this point it means that you will have the foundation in place to ensure successful development of Solutions. In the case of Enterprise Solutions, you will look at the Solution Architecture and the encompassing approach itself. Topics such as Requirements Analyses, Data and Reporting Strategy, UI/UX Strategy, Logic and Integration Strategy, Security Strategy, etcetera, receive the necessary attention.
These four attention points are part of what I like to call the Low Code Ecosystem. The table below summarizes the layers of this ecosystem.
| Tiers within the Low Code Ecosystem | ||
| Strategic | Business Strategy Business Objectives Business Goals Corporate Governance | Strategy, goals, and objectives determined by the Business |
| Low Code Strategy | Determines the direction of Low Code in the organization | |
| Tactical | Platform Governance | Get your platform under control |
| Low Code Governance | Empower Low Code Development in your organization | |
| Operational | IT-Driven Development | Low Code Development activities by IT persona |
| Citizen-Driven Development | Low Code Development activities by Business persona | |
| Fusion Development | Low Code Development activities by a multi-disciplinary team of IT and Business personas, working together to deliver Low Code Solutions | |
My Ideas Visualized
Through the years I have been able to develop my own ideas, sometimes inspired by others. Many of these ideas include visualizations. So, you may wonder why I never include these in my articles. Well, the reason is simple: I am still figuring out how I can share these freely within the community, without being sued for IP infringement, as I developed many of them as part of client projects. Thus, I will need some time to figure this out. But in the meantime, I hope this article will help you one way or the other. Until next time!
Comments are closed