Warum PowerApps vielleicht doch wichtig werden könnten

Seit einigen Monaten wuselt das Wort PowerApps immer mal wieder durch die informierten Kanäle und vielsagende wichtige Blicke werden ausgetauscht, wenn im eingeweihten Kreis die Sprache auf diese neue Technologie kommt. Untypisch für das derzeitige Microsoft ist die aktuelle Betaphase recht restriktiv gehalten: Man darf sich anstellen und noch nicht einmal jeder MVP darf sofort rein und gucken. Vielleicht ist es aber tatsächlich interessanter als viele andere Dinge, die mit ordentlich Tamtam in den Ring geworfen wurden.

Grundsätzlich ist man ein wenig vorsichtiger und skeptischer geworden, was das große Bewerben von Features und Techniken in Verbindung mit SharePoint im Vorfeld eines Releases angeht. Beim SharePoint Server on premise war es in der Vergangenheit immer ein wenig der heilige Gral, der hinter der nächsten Technologie vermutet wurde, bis man durch Erfahrung oftmals herausgefunden hat, dass vieles entweder technisch halbgar ist oder für den eigenen Ansatz, wie SharePoint im Unternehmen „gedacht“ wird, schlicht und ergreifend nicht passt. Ob nun damals InfoPath, Access Services 2013 als Ablösung für InfoPath, SharePoint Designer als deklarativer Workflowbaukasten, heute das App-Modell als Allheilmittel der Erweiterung oder demnächst vielleicht die Minrole als Schnittmusterbogen der perfekten Enterprise Architecture – so richtig zündet selten etwas flächendeckend und einhellig.

PowerApps als Heilsbringer

Das aktuelle Narrativ für PowerApps klingt dabei ähnlich wie bei den zuvor genannten Themen:

  • Ein neues Projekt, ein neuer Ansatz für ein umfassendes Problem (hier Entwicklung von Individualsoftware rund um SharePoint (Online)  Office  Business Apps)
  • Einfaches Erstellen von Dingen ohne teure und rar werdende Experten zu benötigen
  • Vollständige Integration von LoB-Daten durch einen komplett API-basierten  SaaS-Ansatz
  • Moderne verteilte Architekturen statt serverseitige Risiken

Kurzum: PowerApps ändern die Art und Weise, wie die Werkzeugkiste Office Server um zusätzliche Anforderungen und Instrumente erweitert werden kann ohne all die komplizierten Dinge, die man bisher berücksichtigen musste. Das klingt arg nach Werbebroschüre zumal das Projekt Siena als die Keimzelle der PowerApps kaum jemanden bisher bekannt war und das SharePoint-Team zumindest für die Community recht eindrücklich die Hosen heruntergelassen hat was die fehlende Nachfolge für InfoPath angeht.

Alles wird anders

Wirklich funktionieren kann der Gedanke dabei wohl tatsächlich, denn anstatt diese Anwendungsfälle als SharePoint-spezifisches Problem zu sehen, wird es einfach enkoppelt: Nicht SharePoint ist der Mittelpunkt der Welt sondern der Anwendungsfall, dessen Daten und dann irgendwann die Plattform, die sich daran anschließt. Eine Verkehrung der Dinge, bei der sich der langjährige SharePoint-Entwickler erfahrungsgemäß schwer tut. Und so wandert die Entwicklung weg von Inlinecode in Formularen oder ähnlichen Spaßveranstaltungen zu wirklich getrennten Layern für Daten-, Logik- und Präsentationsschicht. Da mit Azure sowieso eine Plattform zur Verfügung steht, die für komplett modulare Architekturen gut geeignet ist, skalierbar ist und (zurecht) die erste Geige bei Microsoft spielt, verschiebt sich hierhin der zentrale Punkt der Datenabstrahierung, API-Verbindung und Businesslogik. Der übrigbleibende Rest wandert dann in ein Werkzeug, an dem jeder Hardcore-InfoPath-Designer wahrscheinlich vor Langeweile verzweifelt den Expertenmodus sucht.

Channel 9 hat diverse Videos zum Thema, bereits im Dezember konnte man dabei eine grobe Architektur sehen.

PowerApp Infrastructure
PowerApp Infrastructure

SharePoint Extrawürste? Nö.

SharePoint oder Office 365 taucht hierbei in der Grafik noch nicht einmal mehr explizit auf, die gesamte Technologie begreift sich als unabhängige Architektur, die lediglich bestimmte Services im Hintergrund benutzt um darauf die UI zu bauen. Hier ist auch der Unterschied und Fortschritt zum Ansatz von den zuvor genannten bekannten Bausteinen zu sehen: Statt Extrawürste wie das Deployment von Forms zu InfoPath-Zeiten oder Featureeinschränkungen wird jeder Bestandteil so verortet, dass er gekapselt entworfen und entwickelt wird. Entwickler kümmern sich um den Service in Azure, „Poweruser“ bauen sich die Oberfläche so, wie sie es wollen. Das Backend braucht keine wilden Verbiegungen mehr und wird in der Dienstbereitstellung nicht mehr behelligt. So schnurrt der SharePoint Server in Ruhe vor sich hin und liefert über Standards (z.B. REST Services) nur noch aus.

Ähnlich wie das App-Model erfordert das eine gewaltige Umstellung der eigenen Denke, was denn nun eine Applikation auf Basis von SharePoint ist und wie sich die einzelnen Bestandteile ggf. auf ganz andere Services verteilen. Aber auch an die Anwender stellt das Prinzip wieder ganz neue Herausforderungen in Bezug auf das Handling von „Apps“. Ob z.B. eine Windows 10 Universal App als Container bzw. Startpunkt für die eigentlichen PowerApps wirklich intuitiv zu verstehen sind, wage ich aktuell zu bezweifeln.

Zwischenfazit

Soweit nun die Theorie. Aktuell gibt es kaum ausführliche Demos, und wenn doch, sind die Anwendungsbeispiele auch nicht viel mehr als das, was man bisher mit dem Formdesigner oder InfoPath-Standardformularen machen konnte. Hier zeigt z.B. Scott Hanselmann die Bricks-Demo mit Service und Oberfläche. Aktuelle Rückmeldungen aus dem closed beta Programm sprechen noch von diversen Einschränkungen, die aber bei einer Version 1.0 erwartbar sind.

Bis zur Public Beta sind es nur noch „just a few days“. Ich bin jedenfalls mal gespannt.

Leave a comment

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.