connected company

Waarom zijn uw systemen niet agile? (Deel I)

16 februari 2017

connected company

Veel organisaties vinden het nodig om connected te worden, omdat hun klanten ook die trend volgen. Partners en klanten verwachten dat organisaties hen de mogelijkheid bieden om hun businesscapaciteiten te gebruiken in hun bedrijfstoepassingen. Op die manier kunnen ze bedrijfstoepassingen ontwikkelen die een rol gaan spelen in een ecosysteem dat talrijke organisaties omvat, die soms over de domeingrenzen heen werken.

Connected Companies hebben platforms nodig om het voortouw te nemen in deze digitale transformatie. Een reeks API's vormt een wezenlijk onderdeel van dergelijke platforms.

Agile en API’s

Het agile-beginsel is tegenwoordig een veelbesproken thema in heel wat organisaties. Het agile softwaredeliveryproces is immers een goede methode om bedrijfstoepassingen sneller op de markt te brengen. API-leveranciers doen uiteraard ook hun uiterste best om hun eigen diensten en bedrijfsprocessen agile te maken.
Hier gaat het echter niet over agility als softwareontwikkelingsproces. In dit artikel bekijken we de agility van de API of het systeem in zijn geheel in runtime.
 
Wat als het gedrag van de API afhankelijk is van de locatie waar hij wordt aangeroepen? Hoe flexibel is de API in verhouding tot een gebruiksomgeving die voortdurend verandert?

Deze vragen moeten vanuit een architecturaal oogpunt worden beantwoord.

Aangezien onze klanten altijd verbonden zijn en ze onze toepassingen of API's op eender welk moment, op eender welke locatie en op eender welk toestel willen kunnen gebruiken, moeten we ervoor zorgen dat onze API-architectuur klaar is om aan die vraag tegemoet te komen. Deze parameters noemen we contextinformatie. Met contextparameters bedoelen we alle gegevens die kunnen worden gebruikt om de situatie van een entiteit te typeren. Onder 'entiteit' verstaan we een persoon, plaats of object die of dat relevant wordt geacht voor de interactie tussen een gebruiker en de toepassingen zelf [Dey and Abowd’s]. Door gebruik te maken van verschillende contexttypes, zoals locatie, weersomstandigheden, gebruikersactiviteit, sensorgegevens en beacons in de buurt, kan uw app de huidige situatie van uw gebruikers beter begrijpen en de informatie gebruiken om een geoptimaliseerde ervaring op maat aan te reiken.

Gebruikerservaring op maat

Het gebruik van contextuele informatie over gebruikers en toestellen kan helpen om de klant in minder interacties een ervaring op maat aan te reiken. De sensorhardware die wordt gebruikt om contextuele informatie te verzamelen is breed beschikbaar. De low-level sensorgegevens, zoals fysieke locatie, tijd en hartslag, kunnen worden gebruikt om contextuele informatie op een hoger niveau af te leiden, bijvoorbeeld een situatie als "ochtendjogging in het park". De van contextuele informatie afhankelijke gebruikerservaring in toepassingen kan sterk worden verbeterd door die toepassingen automatisch te voorzien van uit sensorgegevens afgeleide contextuele informatie. De stap om het Internet of Things in de oplossingsarchitectuur van een Connected Company te integreren lijkt dan ook zo gezet.

Het meest geschikte ontwerpparadigma om tot dit soort architectuur te komen is service-oriëntatie. Services vormen de bouwstenen van het service-georiënteerde computerplatform, elk met hun specifieke taak en toegankelijk via standaardprotocols en -interfaces. Toepassingen worden gevormd door services uit de service inventory te combineren en te herschikken binnen het bedrijfsdomein. Daarbij is het vooral van belang om services te identificeren die herbruikbare functies leveren en dus maar eenmaal worden ingezet en door verschillende toepassingen worden gebruikt. Dat geldt ook voor API's: API-leveranciers streven eveneens naar een maximaal hergebruik van hun API's.

Beide paradigma's – context-aware computing en service-oriëntatie – kunnen elkaar helpen en versterken. Een contextgevoelig systeem moet contextuele informatie kunnen opvragen uit diverse bronnen. Services om informatie te distilleren uit ruwe sensorgegevens zijn de beste manier om contextuele informatie te verstrekken aan andere onderdelen van het contextgevoelige systeem. Anderzijds kunnen service inventory's contextuele informatie gebruiken om de kwaliteit van de zoekresultaten te verbeteren en hun gedrag zoveel mogelijk af te stemmen op de gebruiker van de services. Ook bij het servicediscoveryproces kan contextuele informatie worden gebruikt, om de meest relevante service of API voor te stellen in een gebruiksomgeving die voortdurend verandert.

Er zal bijkomende technologie nodig zijn om ervoor te zorgen dat systemen binnen paradigma's als service-oriëntatie, API-beheer en contextgevoeligheid op een meer automatische manier servicecomposities kunnen samenstellen, waardoor tussenkomst van een designer of modeler (late (runtime) binding) minder vaak nodig is. Daartoe moeten de services, IvdD-toestellen en mogelijk ook de gegevens worden beschreven in een indeling die door het systeem zelf kan worden geïnterpreteerd, zonder tussenkomst van een mens (designer). Deze beschrijving zal worden gecreëerd met behulp van semantische webtechnologieën. Op basis van de beschrijvingen kan het systeem op (semi-)automatische wijze achterhalen welke onderdelen nodig zijn om aan het verzoek van de klant te beantwoorden.

In een oogopslag

Onderstaande afbeelding vat de kernboodschap van deze blogpost samen. Allerlei input wordt gebruikt om informatie te achterhalen over de omgeving waarin het systeem actief is. Deze informatie wordt door het systeem omgezet in kennis om zijn gedrag te veranderen, met als resultaat een ervaring die sterker is toegespitst op zowel onze klanten als onze partners.

infographics_cc_blog@2x-100_compressed.jpg

 

In mijn volgende blogpost zal ik dieper ingaan op deze beschrijvingen en leg ik uit hoe ze kunnen worden gebruikt in de architectuur. Realdolmen biedt een aantal van deze componenten (zie SEE4SOA) aan voor uw architectuur, die rekening houden met al deze dingen, zodat u zich op de businesslogica in de services en API's kunt concentreren en zich geen zorgen hoeft te maken over de onderliggende componenten die de visie van een Connected Company ondersteunen.

jkpw297_LThumb.jpg Johan Kumps, Solution Architect. Voor meer informatie over dit onderwerp kunt u me contacteren via Johan.Kumps@realdomen.com.

 

Wilt u meer informatie over hoe u een connected company kunt worden? Neem dan contact op met onze expert Roel De Cuyper, Division ManagerThe Connected Company via roel.decuyper@realdolmen.com.

Wilt u meer te weten komen over connected companies lees dan de vorige blogposts:

Word een Connected Company met deze 10 principes

Proximus en het IoT: een verhaal over "getting there together"

Blockchain is meer dan een digitale munteenheid. Enkele toepassingen die vandaag al mogelijk zijn

CoZo wordt mobiel

PSD2: uitdaging wordt opportuniteit met Secured Runtime


 

Inschrijven op de nieuwsbrief

Blijft u graag op de hoogte van nieuws, aanbiedingen en events over onderwerpen die u zelf kiest?

Schrijf u hier in