In the Beginning…
The world of technology has gone through multitudes of changes in the past 30 years. The turn of the millennium marked a key point in the way in which technology was perceived. Many peoples' perspectives were that Y2K would wreak havoc across a plethora of technologies and the fear of the Y2K bug became a real thing. Luckily very few things broke when the clocks across the world moved over into the year 2000; there was some perspective to be had. Most people just buckled up for the ride. The acceleration and progression in the technology market seemed endless, with giants like Google and Microsoft etching their names into the global circuit boards of the technology world. The race to invent more innovative technologies would and did accelerate.
Parallel to this amazing innovation, and sometimes despite it, a group of incredibly smart people had been learning to speak “the language of the digital world.” This ability to communicate with computers would enable them to build useful things that help automate how others do their jobs. These digital languages have created many amazing and useful tools which we still all use today. The people that built these solutions are developers.
Around 2010, Microsoft's drive towards the cloud and cloud computing with Microsoft Azure brought a layer of innovation never before seen by the market. Developers did not have to rely on their own physical boxes in server rooms but could utilize the Microsoft Azure cloud framework to provide resources, which allowed for even larger and more complicated software to be built and run. Azure brought an extraordinary number of tools and functionality to aid developers in their creations. Suddenly, the canvas for digital paintings became endless, and developers were only limited by their imagination and, of course, resources to pay for cloud computing.
Around 2012, one of the largest global systems integrators coined the term digital transformation, which was widely adopted by the technology market. Microsoft would share customer stories about how they had “digitally transformed” and changed their work. Keynotes from senior Microsoft technology leaders would shape the thoughts of vendors, partners, and customers alike, urging everyone to embrace change and drive towards digital progression. The days of punching holes in paper documents (for three-ring binders) were ending, and professional developers were being more and more sought after. The requirement for talented developers grew with the demand from wider organizations, and business users started leveraging the tools at hand to start solving their own challenges without the correct training and enablement.
The focus on the technology part of digital transformation would essentially be deemed successful based on the innovation and growth of tools such as Microsoft Office, Azure, and other business productivity solutions. However, without initial guardrails and governance in place, a plethora of shadow IT grew across organizations. Data was siloed and not centralized, monolithic applications were built with platforms that were meant for basic productivity solutions and essentially drove further pressure on the IT / technical departments within organizations, which made those personnel reactive and focused more on putting out fires and less on enabling the organization with useful technology.
For example, in low code and in particular, the Power Platform, there are scenarios where tools such as SharePoint lists have been used to store and manage highly complex relational data structures with huge amounts of data. This is because of the licensing structure and Power Apps canvas apps are deeply linked to SharePoint as a tool to drive the forms over data approach with intelligence. The structures would not scale and eventually require specialized IT/technical know-how. More developers needed!
Despite technical innovation, digital transformation in the mid-2000s was focused mainly on technology and not on enabling people. The developer gap got larger and larger because of this. The term digital transformation made sense at the time. However, as we have grown as a society and learned about data, security, AI, and of course, low code, organizations are realizing that they need to put more emphasis on people and technology. In this article, I'll explore the position of low code within a wider organization or community and the role of each person engaged and how they could contribute to building something useful.
This is the era of enablement and not transformation. Transformation has a defined end; Enablement is limitless.
Personal Perspective 01
I have been lucky to experience custom design and development firsthand. I released my first-ever custom timesheet management system live in 2003, right out of school, and I was convinced my path forward was to write code. And I did for a long time. In fact, I even ended up working at a company called Borland UNICO where we were responsible for building and implementing logistics management solutions. I loved writing code so much that I even printed it out, and I still have the hard copy printed on paper as well as the actual solution files on hard disks. I have done my best to follow the progression of the cloud and how we can leverage the services available to build amazing and helpful things.
Enter Low Code
Forrester coined the term “low code” around 2014. Vendors realized the increasing demand for developers based on this concept of digital transformation meant that skilling people up to write code would take far longer than just democratizing technical functionality into a more “friendly” layer that educated non-technical people could use to solve problems without the need for someone who could write code. The idea will never be to replace developers but rather to enable non-developer persons to build something useful as fast and accurately as possible. The simpler and relatable the platform, the easier it would be for people to adopt and build. Low code has its roots in what was previously known as rapid application development (RAD) platforms. The idea was to give a more visual experience to developers when making solutions.
Technology Waves and the Hype Cycle
It's probably true that some people still think that low code is in its infancy. However, the fact of the matter is that low code is used by millions and millions of people and is well past the hype-cycle phase and is in the early majority (Figure 1). In fact, Power Apps is the most widely used low-code app-making solution globally due to its deep integration with the wider Microsoft 365, Azure, and business applications platforms such as Dynamics 365. This branches out even further to the other digital building bricks in the Microsoft Power Platform such as Power Automate, Dataverse, and the other tools that many organizations' wider maker (which I'll define in detail later) and developer communities have adopted.
In fact, technology waves are shortening drastically. From the inception of the browser in 1996, to 2023 when we see a huge drive towards large language models (LLMs) embedded within products, there have been multiple technology waves. Low code is nearly in its tenth year and Power Platform is in its eighth year. This may seem like a short time, but, in the world of technology, that's not short at all. The waves of technology are only going to get shorter and shorter, and, before long, AI will be doing most of the “less thoughtful” tasks for us.
Digital Bricks
Think of low code as prebuilt digital building bricks (conceptually a bit like those colorful interlocking LEGO Classic bricks) that a vendor has positioned together to allow people to create tools that solve problems in their day-to-day working (and sometimes personal) lives. There are hundreds of low-code solutions out there and the list of them is growing rapidly. Many of us have used low-code platforms (possibly) without even knowing it. Building websites with tools like Wix or WordPress, automating processes with tools like Nintex, sending bulk emails with tools like Mailchimp and creating apps with tools such as Power Apps. The low-code landscape keeps growing and growing, and more companies and vendors are joining the bandwagon. All the platforms mentioned in Figure 2 have some element of visual design experience that is aimed at making makers' lives simpler.
Consider the following analogy to those colorful interlocking bricks. Whether a person is building a replica of the Saturn 5 rocket or a fairy princess castle, they will plan to use a certain set of interlocking bricks, which is part of the design. If they can't find a specifically shaped brick, then short of 3D printing it, they will need to improvise. They will not be able to call up the “colorful interlocking brick” company and have that specific design made for them. You would be surprised at how many people require these custom bricks.
Power Platform works like this too. Many times, makers can only get to a certain point in a solution build before they realize that they need some help or need to have a “custom digital brick” created for them. This comes in hundreds of variants from the creation of custom APIs, custom connectors, plugin code, JavaScript, complex relational data structures, custom components, and many more. The great part is that there are very talented people who do still write code and can build these reusable digital bricks that can be added to the solutions made by a Power Apps user. In fact, there are even community libraries that exist (Figure 3) where you can download some of these useful assets. As an example, you can download Power Apps Component Framework Controls here: https://pcf.gallery/.
A Real Live Example: Facilities Management
There are hundreds and thousands of scenarios that can be used to highlight the need for Power Platform as a rapid application development platform. In an unnamed organization, a requirement was captured (Figure 4) into the centralized ideation solution that described the need for a centralized asset and facilities management solution that would allow facilities managers within the organization the ability to track and manage the lifecycle of facilities such as meeting rooms and assets such as projectors, desks, and chairs.
The use case was logged by a citizen developer who had started an initial basic build process on the solution and had run into several technical walls that they could not get over, therefore some more help was required. SharePoint had been used as the data structure, with a flat canvas app on top to capture the data. Unfortunately, the citizen developer was unsure about managing hierarchical data in SharePoint and the flat data structure did not fit the use case very well. With permission and backing from the business stakeholder, the citizen developer escalated the project to the IT department for review and potential assistance.
It's Bigger Than Just an App
Since its inception around 2015 (it was not part of Power Platform at this point and was known as Project Siena), there has been a lot of focus on Power Apps and in particular, canvas apps. Yes, canvas apps, which look as if it brought Excel and PowerPoint together to form a love child. This is because of the immediate and tangible output that can be gained from connecting a front end to a data structure. Makers love Power Apps canvas apps because of the PowerPoint-esq ability to edit the user interface and make them look amazing. Canvas apps received most of the attention in the early days of Power Platform, and often as the platform grew and other digital bricks were added, people were still talking about making apps. Terms like “filling the app gap” and “there's an app for that” were being used all the time.
Historically, the term app was associated with development. Developers would make apps and then people would use them as needed. If you wanted an app, you asked someone who could code. The entry of low code turned someone who understood how to use Microsoft Office products into a citizen developer - a person who is part of the business community and who can use the pre-built digital bricks in Power Platform to create something useful.
We forget that the Power Platform is not just about canvas apps and cloud flows. The Power Platform is also NOT aimed at citizen developers only. Most of the tools in the platform also have technical integrations into the wider Microsoft 365, Azure, and Dynamics 365 stack, allowing makers of all types and with varying experience levels to build useful things. This platform is for everyone and is essentially “the platform of the people.” The mindset of “the app” needs to ultimately fall away and the concept of a business solution should be embraced because it's never “just an app.” There are so many other facets to this, such as data, connectors, apps, automation, AI and so much more. Sometimes, the best user interface is no user interface and, therefore, an app will not be the correct solution. Wider thought patterns with critical thinking and an inventive approach often require more than one person's input. Essentially, we need makers of all types to work together and do what they are best at while learning from the more experienced makers/developers in the team.
Personal Perspective 02
When building solutions that solve business problems, I realized that there was a specific part of my job as a developer at the time that became irritating to me: form design, view design, and UX/UI. I'm still not great at it, and I wish it could be magically done for me. I like making complex data models, building automation, and generating reports with analytics. Adding fields is not my favorite thing. If I could do my thing and have someone else do what I consider the least focused part of the build, I'd be happy. The great part about low code is that the technology is broad and can be shared with loads of different people of varying experiences. Developers don't need to build the simple stuff any longer; that can be done by a maker with less experience. More experienced makers can just make the digital bricks available to the wider team as needed and can focus on the more difficult and technical parts of the process solution.
Getting Started on the Use Case, Who Does What?
Power Platform is the people's platform, and a range of solutions can be built with the tools in the platform. Not everything requires someone who deeply and completely understands technology and code. When looking at the types of things people make with the Power Platform, there is a huge range from simple modular solutions to hugely complicated monolithic solutions (Figure 5). All are connected to varying data structures and achieve different outcomes. Some of these solutions are single point-and-shoot single node apps and flows, and some are a collection of thousands of digital building bricks.
The best way to explain this is by building on the real-life scenario that involved a team of makers. Each person had a role to play in a project and each person was reliant on other people in the team to consult and build their part. We let individuals focus on what each person/archetype did and how they worked together.
Let's think about when Microsoft Office first came out. There is an advert online about Excel and how to use some of the mathematical functions to work out quarterly spending amounts. It's a crazy simple thing to do. The ad shows a few people in an elevator and the lead person doing this math before the meeting. For the time, it was revolutionary. Accountants thought they would never again have jobs and companies used to pay people to make them Excel documents. The fact is that we still need accountants BUT fewer people get paid to do things with Excel. People have the skills to do this themselves and, in fact, spreadsheet skills are a requirement to join many organizations nowadays.
How long before this happens with low code?
It's good to understand how someone will be using the tools in the platform to create solutions. What we call this type of person is completely dependent on your organization's culture and approach. Some organizations love the name “citizen developer,” and some do not. Often the term “maker” comes with a qualifier like entry level, experienced, etc. Again, this is dependent on the organization's culture. The varying archetypes may focus on different parts of the build, all dependent on the way in which the teams are structured.
Citizen Developers
Gartner defines a citizen developer as a person who is part of the wider organization who uses technology to an extent to solve business problems. They don't normally work directly with technology but may be at the beginning of their journey to learning more about how technology will help them in their everyday careers.
There has been some contention around the terminology since developers are proud people, like the Asgardians, and who do not want to be directly associated with citizen development. This is why the concept of a maker is used as a broad-brush term for people who may not be part of the IT or development team but are building useful things. Sometimes the term “beginner maker” is used to signify how these makers start their Power Platform journey. Your citizen developers normally make up the larger portion of the maker base in an organization.
Often the citizen developer is the person closest to the problem and may be able to best describe it to you.
The Rise of the Business Technologist
According to Gartner, “41% of employees are business technologists, creating technology or analytics capabilities for internal or external business use and reporting outside of IT departments.” You can find the full article here: https://tinyurl.com/yxzm4vbp.
This is a fundamental shift in the way we perceive digital transformation. Digital transformation was “done to us,” so to speak. This feels more like “done by us” where we are in the era of enablement, and we are learning to use technology to solve business problems ourselves. Business technologists are more advanced citizen developers who can use the skills they have developed to solve problems within a governed ecosystem. Essentially, the business technologist is a technology enthusiast who believes that technology can be used in a day-to-day environment and to improve their lifestyle - sometimes beyond the office. Business technologists make great Power Platform champions and help drive change and adoption.
Business technologists may also be referred to as “intermediate makers” and will make up the second largest contingent of your maker base. When a business technologist is part of a project, they are often happy to own the solution and guide the process as they best know the desired outcome. They may have several citizen developers working with or near them.
Understanding the Requirement
Getting started was the tough part because, in this organisation, each use case required a review from the project intake team and then a specific technology could be associated with it. The citizen developer mentioned that they had used SharePoint and Power Apps canvas apps. Therefore, a start had been made. A decision was taken to review the solution and understand more about the requirement.
Instead of assigning a professional developer, one of the Power Platform champions (business technologists) within that specific business unit could approach the challenge and run a requirement-gathering process with the citizen developer and some of the business stakeholders' wider facilities management team. There are generally several frameworks that can be used to undertake an exercise like this. However, parts of the Microsoft Catalyst workshop content were leveraged to capture challenges, opportunities, and goals (Figure 6).
Drilling into the requirements, the business technologist was able to track and manage the opportunities and goals into clusters which would identify key areas and personas that needed to be focused on during the solution build (Figure 7). Again, because the business technologist is relatively close to the problem and is talking to the right people, they can track the requirements from the people who are closest to the problem.
Without giving away too many company secrets, there were several other steps that ran between this point and a solution design. Two important steps that drove the selection of the technology were:
- User role mapping: tracking how the requirements are mapped against user roles.
- Item prioritization: understanding what is most important and what essentially needs to be delivered first to ensure the solution will scale.
Ultimately, understanding the core business requirements and getting into some of the details, the business technologist in collaboration with the citizen developer and the wider team was able to capture exactly what was needed. The business technologist started sticking the relevant digital bricks together for a solution design diagram, which would normally be reviewed by the professional developer. However, the greatest question in the history of making ANYTHING with Power Platform arose…
Where do we put the data?
Personal Perspective 03
After several years working in technology and working with the Power Platform since its inception, I had a realization that even though I have mastered several of the core digital building bricks in the platform, there are hundreds of scenarios where I am not the person closest to the problem. I need to be educated and taught to understand the problem in my organization. These types of scenarios mean that citizen developers and business technologists are ideal to work with, and they may be able to take on some of the tasks that I may not have time to do. I don't need to add all the fields, build views, make forms, and add app screens. I can build the right intelligence and logic into the relevant layers of the solution.
Personally, I will never ask a professional developer to build an app or a flow unless they have the desire to do so. I would rather have them build the more complicated parts and let the citizen developer and business technologist build out the low-code parts.
Expanding the Team: The Professional Developers
As the programme of work expanded there was a need to ensure that the professional developer team was involved in the project for multiple reasons. Allow me to introduce the professional developers to this project scenario.
Professional Developers
Professional developers are the people with more advanced technical knowledge who have mastered technical digital building bricks in the platform and can often write code. Professional developers are sometimes known as “advanced makers” or “super makers” and often will constitute the smallest contingent of people building things with the Power Platform. In most build scenarios, the professional developers will be involved depending on the complexity of the solution. The majority of beginner and intermediate maker-generated solutions will not need a professional developer to assist (Figure 8).
For example, a solution that requires canvas apps on top of basic SharePoint lists can be built and supported by business technologists. A solution that requires a more complex data structure with varying automation and application complexity will likely require assistance from a professional developer, even if it is to ensure best practices are being followed.
Professional developers are great at either owning the solution or working with the business technologist to own the solution.
Expanding the Team
Data will impact your solution significantly for several reasons. If the incorrect data storage facility is selected, the solution may not be performant, it will not scale, or it may not fit the budget. There are many factors and variables that need to be taken into consideration in this scenario. The citizen developer and the business technologist had thoughts on where data should be stored; however, the decision required more factual advice based on the requirements and information about the data that needed to be stored. There were several requirements that spoke of hierarchical data structures, security, audibility, and high-data volumes.
Enter the professional developer to review the requirements and to understand the underlying data specifications. Based on the information generated by the team and the guidance of the business technologist, the professional developer was able to determine that the correct data storage facility in this scenario would be Dataverse. The use case was critical to managing the assets and facilities. There were risks around the data being incorrect and not audited. Dataverse offers a robust data storage facility with built-in security, auditing, and robust relational qualities with referential integrity. This solution would also cost more money for each user because SharePoint and Excel were not scalable enough to meet the needs specified.
Due to the model being in Dataverse, the professional developer could build out the relational data model and schema (Figure 9) and hand it over to the business technologist, who then could extend this with the correct fields, forms, and views without interrupting the relational nature of the model. At this point, the professional developer has spent a relatively short amount of time reviewing and building out the more difficult parts of the solution.
On review of the data model and based on the use of tools such as Dataverse, the team created a simple, functional design diagram that was then reviewed and approved by the professional developer. Figure 10 shows the breakdown of the various applications required for this solution. You can see that a portal is required for external repair people to see any repair jobs with locations. An inspections app is required for internal people to manage and track their internal inspections and a mid-office facilities and asset management application is required for the mid-office users to centrally manage all data and the full lifecycle of the asset. If Dataverse were not used in this scenario, then Power Pages and model-driven apps would not be an option as both require Dataverse as a data storage facility.
The Build Progression
The solution build progressed in an agile manner, with the citizen developer (45%) and business technologist (45%) working on most of the build and the professional developer (10%) dipping in and out of the process to review, help, and fix technical bugs. This worked perfectly because there were many other projects being run in parallel across the business, and the professional developer only had the capacity to spend a small amount of time on each of the citizen developer / business technologist-driven solutions without putting any larger professional developer projects at risk.
There were some key parts to the solution that each person focused on and brought together to refine and grow the full build. The solution design diagram referenced in Figure 10 does the solution a disservice due to:
- There were several automations that were generated to support the approvals process.
- The custom connector was multifaceted with many actions that enabled asset status updates, devaluation criteria, and multiple other functions that would drive the asset through to complete its lifecycle process.
- A custom calendar control for the model-driven app was created so managers could clearly see the repairs and inspections across the asset landscape over time.
Each area received attention in varying weightings from each role and these were broken down as follows:
- Professional developer: core data model, Power Pages site, custom connector to asset management API, model-driven app calendar custom control
- Business technologist: fields, forms, views, process flows, automation enhancement
- Citizen developer: base canvas app, base automation, form field and view field creation
Ultimately, the three different personas could focus on what they felt they were good at and contributed the best they could while working together to complete the solution. Granted, this does take much control and collaboration, especially as solutions grow and get larger.
Personal Perspective 04
Having worked in many teams and roles, I have learned that it's important to make rules upfront about who does what and what is expected of people. Often citizen developers feel impostor syndrome as if they have nothing to offer, so it's important to ensure that communication is open, and tasks are clearly allocated. I have made this project sound much simpler than it was and, truthfully, it's not all wine and cake. Sometimes professional developers take over because, “It's just easier if I do it my way.” Sometimes business technologists push the boundaries of their own skills but forget to ask for help, and sometimes citizen developers bail out because it's just too much. The idea is to enable one another to do this, which takes leadership and inspiration. I have fallen victim to doing all these things myself.
Often citizen developers feel impostor syndrome as if they have nothing to offer, so it's important to ensure that communication is open, and tasks are clearly allocated.
Wider Use of the Platform
When looking at the outputs of the solution, it was apparent that many of the assets that were created could be packaged and reused across the organization. The custom connector proved useful because many other business units could snap into that asset data without interfering with the asset and facilities lifecycle management solution.
The custom calendar control, which was built for model-driven apps, was packaged and can be reused across the organization for any other solution that requires a calendar. This is a very common requirement.
The facilities data model was exported and can be used as a baseline for any other facilities management solution, which may not need repairs and inspections, but the hierarchy as a base.
The Rise of the Era of Enablement
Ultimately, developers add to the stack of digital building bricks in the platform and provide makers with more options to create useful things. For each professional developer, there may be 100 citizen developers. This is the power of reuse and wider enablement through a platform for everyone. All low code is somebody else's code that you use to make things much faster.
The intention is not to replace anyone but to enable people to create things that enrich their daily lives. This is as much about working together to create beautiful, useful things as it is about technology. Let's not forget where we started and how fast this is moving.
The era of enablement has officially begun and the rise up of the business technologist shows us that people are willing to experiment and attempt to solve problems themselves. With the aid of professional and experienced developers who want to help and be part of a community, this era will change the way we perceive problem solving and solution creation.
Soon, Copilot will be doing more than just creating apps with three screens and one table. The power of AI will be right there beside us helping us to create things. The barrier to entry is far lower than it has ever been because vendors have realized that this is not just about transforming digitally but about enabling people to take the robot out of the human and stop doing mundane technical tasks that don't add fulfilment to their existences. So, the next time you find yourself making something, and, whatever experience level you have, reach out and see who else you can get involved to participate.
Final Personal Perspective
As a person who has worked with technology for two decades, I have been lucky enough to be a part of many trends…. The introduction of the browser, the start of the digital transformation era, the rise of low code and now the age of AI with products being born in AI. The waves between trends are getting visibly shorter and technology is advancing at a rapid rate. No matter what role I have found myself in, whether it be professional developer, business technologist or citizen developer, I have found myself both needing and providing enablement across many different projects. The Power Platform is just so large and there are so many tools available. I don't think it's possible for someone to know everything. Recently I read that Satya Nadella has the approach of being a “Learn it all” rather than “Know it all.” Enablement is absolutely key to learning!
