Unfortunately, when I talk enthusiastically about PowerApps and Flow, developers sometimes react cynically. “It’s just the latest iteration of MS-Access and it’s only leading to more sprawl in island automation.” An understandable reaction, given history, but is that reaction still justified? My answer to this is: maybe, but only if the IT organization allows it.
History repeats itself
Microsoft has a long history of software aimed at the user who wants to go a little further than the average colleague. Much of this software has just quietly withered away, but there is one application that you might call too successful in a way: Microsoft Access, the name alone conjures up images of misery and chaos in many professional developers.
IT professionals traditionally like to keep the application landscape under their own management. This keeps things manageable and affordable. They often opt for standard applications, which cover most of the information needs. In practice, however, it appears that many things can be done better, faster and easier than is possible with standard software.
Often these are the specific problems of a person, department or company. There is always someone who, more than often in his spare time, puts together a solution with the resources that he or she has available at that moment.
The first reaction of the IT organization when discovering this phenomenon is usually a form of repression: the creator of the solution is forbidden to work on it any longer (experienced it himself) and Access is removed from all computers. Not that the latter measure yields anything, because fortunately there is always Excel. Repression is (in itself) a logical response, but I think a wrong one. I’ve blogged about this before (see Embrace Your Power Users).
The latest incarnation of Access?
The latest offshoot of tooling aimed at the citizen developer is the Microsoft Power Platform, consisting of Power BI, PowerApps and Microsoft Flow. This is a further evolution in power and ease of use in the hands of power users. It is therefore not surprising that this quickly evokes memories of Access for many IT professionals. However, the situation is different now. When developing the Power Platform, the problems that can arise from unrestrained development outside the supervision of the IT organization were considered. Various mechanisms have also been built in to prevent the same errors.
How PowerApps differs from Access
Integration into the Office 365 ecosystem allows the IT organization to maintain control over the application landscape. What resources are available to the IT organization?
Monitoring
A simple but effective tool is the continuous monitoring of the activities that your employees undertake. In the Office 365 administration module, overviews are available of all created Power Apps and flows, with details about the owner of the app.
These overviews can be downloaded for further reporting and analysis.
A second (more advanced) way is to create a so-called administrative flow. There are special connectors with which the Power Platform itself can be manipulated. For example, it is possible to build a flow that monitors when a new app or flow is being built and reports on it and, if necessary, writes this information in a database, or sends the administrator a notification. There is even a standard template available in Flow, with which you can put together a flow in a few clicks. You can also create such a monitoring with PowerShell.
Data Loss Prevention
Monitoring activity is one thing, but it doesn’t prevent another problem often associated with unbridled app development: the risk of corporate information being exposed.
With Flow, it’s child’s play to build extremely powerful workflows. But therein also lies the great danger that sensitive information falls into the wrong hands. It is possible to build a flow with a few mouse clicks that throws your entire customer base from SalesForce on Twitter. Fortunately, Microsoft has come up with something for that.
With Data Loss Prevention you divide all your connectors into two groups: Business Data Only and No Business Data Allowed. You are free in how you organize it, but there is one rule: it is not allowed to create flows that use connectors from both groups.
In the example above, it has been made impossible to execute the previously outlined scenario of tweeting your customer base. The SalesForce connector is in the Business data only group and the Twitter connector is (unfortunately out of the picture) in the No business data allowed group. Once someone creates a flow that uses both connectors, the flow will be disabled.
DataVerse
Finally, there is the DataVerse. This topic deserves a separate blog, but I’ll mention it here, because it’s also a way to make app development manageable.
DataVerse is a central storage of business information that is easy to secure and manage. With connectors, this data can be made available to, among others, Flow, Power BI and Power Apps.
DataVerse can be filled in a controlled manner (by IT professionals!) from your own business applications. The citizen developer can draw from that and be sure that the data is correct.
Collaboration
The above mechanisms ensure that at some point in the process there is always an interface between the IT professional and the citizen developer. It is up to the organization to do something further with this. One extreme is the repression approach: ban everything, stop initiatives immediately. Another option is a much more constructive attitude, in which you are open to initiatives from the workplace. That requires effort from the IT organization, but if done right, it can bring a lot of good to your organization.
Answer to the question
So will Power Platform be the new Access? As an organization, you have that entirely in your own hands! With a little effort from the IT organization, this is not necessary at all. If you let everything run its course, you run the risk of ending up with an unmanageable application landscape again, but that is entirely your own fault.
