Applicaties zijn vaak monolitisch. Ze bieden een bepaalde set aan functionaliteiten in een behoorlijk rigide vorm. Meestal draaien ze op een relationele database. Vaak zijn er maar een paar applicaties in gebruik, geleverd door een aantal leveranciers. De applicatie is gemakkelijk te upgraden. De leverancier zorgt ervoor dat dat goed gaat.
Apps zijn vaak microservices. Ze bieden één functie. En zijn daar heel goed in. Elke app heeft zijn eigen opslagstructuur. Vaak zijn er vele apps in gebruik die van verschillende leveranciers komen. De apps zijn afzonderlijk gemakkelijk te upgraden. De leverancier zorgt ervoor dat dat goed gaat.
Apps bieden natuurlijk een aantal grote voordelen, zoals: Best of breed keuze voor functies in plaats van applicaties is mogelijk; Specifieke, taakgerichte functies voor jouw rol; Gemakkelijk en snel in gebruik te nemen en uit te rollen.
Iedereen die met apps werkt zal echter ook de volgende problemen (h)erkennen: De relatie tussen apps is vaak moeilijk te leggen; Afzonderlijke app upgrades kunnen de totaalbeleving verstoren; Het is moeilijk om data integriteit te borgen.
Niet iedereen kan met een legodoos iets moois en betrouwbaars maken!
Fundamentele keuze
Er zal eigenlijk een fundamentele keuze moeten worden gemaakt: óf je gaat voor (of terug naar) de monolitische applicatie, óf je gaat mee in de wereld van apps. In het eerste geval wordt de business- en informatiearchitectuur door de leverancier bepaald en geborgd, in het tweede geval ben je daar zelf verantwoordelijk voor. Als je it-organisatie daar vertrouwd mee is of je hebt er goede hulp bij, dan is de weg van apps op zich prima te behappen. Als je organisatie redelijk onvolwassen is, is het veiliger om voor de monoliet te gaan. En natuurlijk zijn deze monolieten ook in de vorm van SaaS af te nemen.
Tot slot, hybride scenario’s zijn vanzelfsprekend een veel voorkomende vorm tegenwoordig; hierbij wordt een mix van (SaaS) applicaties en apps ingezet. De apps worden dan gebruikt voor de kortere time-to-market van nieuwe functionaliteiten en het maken van onderscheidende bedrijfsprocessen. Neemt niet weg dat business-, informatie- en óók servicearchitectuur dan nog steeds zeer belangrijke onderwerpen zijn, want voor je het weet verzand je in een niet te beheren en upgraden it-landschap en zit je nog steeds muurvast.
Reacties
Je schetst het wel weer erg plat, met het tempo waarop de wereld verandert is het ook lastig om 1 pad te kiezen: Applicaties of Apps. Daarnaast vind ik ook dat je een scheiding tekent die er feitelijk nauwelijks is.
Zie jij het verschil of een Word document op een App is gemaakt op IOS, op een werkstation? Of in de browser?
Daarnaast: Als je veel in de cloud beweegt zul je ook een IAM beleid hebben gebaseerd bijvoorbeeld op een Active Directory / Google for Work of ander OAUTH 2.0 product mogelijk in de vorm van een Okta of OneLogin. Het is dan juist zaak om deze tools mee te nemen in je diverse keuzes. Past het niet? Dan mag het niet, of in ieder geval altijd in samenwerking met de verantwoordelijke (it) afdeling.
Voor het maatwerk, of het communiceren tussen de diverse (web) services zul je ook de it afdeling moeten betrekken of dit uitbesteden aan een partij die je daarbij kan helpen.
Uiteindelijk wil je geen producten meer gebruiken die direct communiceren naar relationele databases, dit zou altijd via een webservice verlopen. Als je dit goed aan pakt is de term "on-premises" iets van het verleden geworden en ben je als organisatie vrij in je beweging.
Apps versus Applicaties is in mijn ogen een verkeerde focus.
Nogal wat stellingen die m.i. lang niet altijd opgaan ('applicaties zijn rigide', 'apps zijn microservices en bieden 1 functie'). Met name de laatste alinea ("Iedereen die met apps werkt zal echter ook de volgende problemen (h)erkennen") verbaast me: ik werk met apps maar herken ze namelijk helemaal niet. Apps bieden vaak afgebakende functionaliteit met weinig onderlinge relaties waardoor afzonderlijke app-updates de totaalbeleving juist niet verstoren en data-integriteit borgen geen probleem is. Misschien snap ik niet goed wat je er mee bedoelt, maar dan mag je het even toelichten. Verder is de titel wat vreemd omdat ze in mijn ervaring elkaar prima kunnen aanvullen.
Verbazingwekkend betoog.
Eerst wordt een tegenstelling beschreven tussen applicaties en apps.
Vervolgens heb je het over een fundamentele keuze die daarin gemaakt zou moeten worden.
Daarna over de realiteit : hybride scenario's. Inderdaad, vanzelfsprekend. Geen keuze dus.
Terloops nog even apps als microservice typeren, terwijl juist microservices by design open standaarden, coherentie, modulariteit en schaalbaarheid nastreven. Zou toch moeten aanspreken als architect.
Wat bouw jij zelf eigenlijk van die legodoos ?
Je vergelijkt nu een monolitische applicaties met een (monolitische) app? App is veel meer presentatie van data op basis van een microservice of linked data die op basis van een API wordt geconsumeerd.
Omdat je er niet onderuit kan is het hybride model nu van toepassing, de toekomst kan er anders uitzien.