Een korte historie van integratie in de ICT

“Wie het verleden niet interesseert, is een slechte visionair.”
                                                                                    - Sam Rain

In het begin was er spaghetti-code; programmeurs irriteerden zich mateloos aan het werk van hun voorganger, tot grotere irritatie van het bedrijf dat keer op keer het opnieuw uitvinden van het wiel moest financieren. En toen kwam er Java – een programmeeromgeving dat onafhankelijk kon werken op een diversiteit van systemen en makkelijker kon uitbreiden. Deze omgeving werd zo populair dat er voor de industrie een eigen versie werd uitgebracht – de Enterprise Edition.

Ergens in Sunnyvale, Santa Clara werkten een paar bedrijven aan een ‘nieuw’ soort systeem, dat met de hulp van Java, ook een nieuwe strategie en discipline de wereld in brachten: integratie van applicaties – Enterprise Application Integration. De ene partij van bedrijven koppelde applicaties aan elkaar met geavanceerde distributie van gegevens, terwijl de andere partij zich begaven op een nog prille hoop van standaarden in de jonge webtechnologie. Deze laatste partijen zijn verantwoordelijk geweest voor de komst van webservices.

Waar EAI zich specialiseerde binnen de muren van de ‘firewall’, opende webservices het terrein voor partners in de markt – zonder dat bedrijven zich ‘blootstelden’ konden zij informatie uitwisselen over en weer. Het duurde niet lang totdat deze twee disciplines moesten samenkomen tot een enkele oplossing. Integratie bleef belangrijk, maar werd steeds een minder onoverkomelijke taak. Deze fusie vroeg wel om de nodige veranderingen – als het ware moest de technologie door een evolutie heen. De applicatie server werd opnieuw geboren – dit maal als een architectuur: SOA.

De Service Orientated Architecture was gebaseerd op integratie via koppelingspunten mét webservice-functionaliteit. Waar eerst nog data structuren de hoofdrol speelden, werd ontwerp belangrijker – met de standaard webservices kon men de activiteiten niet alleen integreren, maar ook inzichtelijk maken. Snel kwamen Business Rules, Business Visibility, Business Logic erbij als paradepaardjes – men kon rapportages maken, metingen verrichten en nieuwe functionaliteit toevoegen. Echter ging het met de data wat minder soepel – het beheer lag voornamelijk onder de motorkap.

De Enterprices Service Bus maakte daar verandering in; interne formaten werden geschrapt en zelfs volledig losgekoppeld. Naast integratie werd het platform ineens veelzijdiger dan ooit – formulierontwerp maakte de laatste stap naar menselijke integratie mogelijk. Via instanties en losse processen kon de BPM-strategie van vele ontwerpers tot snelle bloei komen. Processen konden ineens omgezet worden tot werkelijke applicaties, die zonder veel ommekeer konden communiceren naar andere processen. De ‘orchestratie’ maakte het mogelijk om alles binnen een Business Proces Management System te plaatsen, wat voor ontwerpers een ware droom die uitkwam bleek. Niet langer hoefde de technische ploeg hoofdschuddend te reageren op mogelijkheden (en onmogelijkheden).

Het enige wat nog rest op het gebied van innovatie is de vervanging van Java. Hoewel programmeeromgevingen een hoge leeftijd halen, kent de Java omgeving zijn beperkingen op het gebied van snelheid en efficiëntie – de laatste doornen in het oog van de ontwerper. Want een industriële toepassing die trager reageert dan een website uit 1996, is natuurlijk nooit een resultaat die gewenst is.

Meer lezen over Informatie Technologie? Klik hier voor de inhoudsopgave van alle artikelen!

©SamRain
Historie ICT

Technische oplossingen begrijpen: De web-server uitgelegd

“Apollo heeft het ver gebracht: vroeger een God, nu een ruimte capsule”
                                                                                                            - Jerry Lewis

Een ware faciliteit zijn web-servers; het gaat niet om de kant-en-klare machines waar websites op geplaatst worden, maar het programma dat verantwoordelijk is dat al die sprakelende pagina’s verstuurd naar onze browsers. Het vervelende van de ICT-branche blijft het jargon; het woord ‘web’ en ‘server’ worden voor veel doeleinden gebruikt en misbruikt, het is dan ook niet raar dat veel niet-techneuten door de bomen het bos niet meer zien. Tijd voor wat ontbossing!

Als programma is een web-server ontworpen als faciliteit. De kerntaak van dit programma is het overdragen van bestanden over een netwerk (zoals het internet), wanneer een gebruiker hierom vraagt. Omdat de web-server zich niet bemoeid in essentie, met de inhoud van deze bestanden, valt deze onder de classificatie van een faciliteit. Hoe deze overdracht precies gaat, zou nu alleen maar verwarring opleveren, we houden het eerst makkelijk.

De bestanden die een web-server verstuurd zijn tekst documenten, die informatie bevatten voor ‘browsers’ (programma’s waarmee we op Internet surfen, zoals Internet Explorer, Mozilla Firefox of Google Chrome). Het programma werkt als een service die wacht op een ‘verzoek’ van een browser en spuugt daar het bijhorende bestand terug. Deze overdracht gaat heel snel waardoor vele gebruikers snel voorzien kunnen worden van de informatie die ze opvragen. Een grijpmachine van de kermis zou een redelijke analogie zijn van de technische mechaniek; de machine is de webserver, de prijzen zijn de bestanden, de munt inworp is het verzoek. Pas wanneer er ‘gegrepen’ is kan het volgende verzoek plaatsvinden en begint het hele proces opnieuw.

Omdat de webserver een ‘domme’ mechaniek heeft als sterkste voordeel, zit het nadeel in dat mensen nooit tevreden zijn. In de loop der jaren hebben knappe koppen programma’s en conventies toegevoegd om de webserver wat meer intelligentie te geven. Zo zijn er speciale programmeeromgevingen ontworpen om de bestanden die de web-server uitspuugt, net ervoor te bewerken. Praktisch zijn deze truukjes voor oplossingen zoals een ‘zoekmachine’: de zoekopdracht verandert elke keer, maar het originele bestand van de pagina niet. Wel wordt er ‘dynamisch’ informatie toegevoegd aan de hand van argumenten in het verzoek (de zoekopdracht).

De bestanden zijn documenten: ze bevatten inhoudelijke informatie en de richtlijnen om deze informatie weer te geven. De web-browser bepaalt echter tot hoe ver zij deze richtlijnen volgen, vandaar dat verschillende browsers dezelfde pagina soms anders weergeven dan we zouden verwachten. Deze documenten volgen vaak een conventie: HTML (Hyper Text Markup Language) is een populaire conventie voor de opmaak.

Omdat de web-server bestanden beheerd, zal deze ook een methode nodig hebben om iedere individueel bestand te benaderen. De webserver werkt over een netwerk, vandaar dat deze methode in de vorm van een ‘voetpad’ moet worden verwerkt. Zonder bekende eindbestemming zou de webserver nooit kunnen raden welk bestand er gevraagd wordt. Dit ‘voetpad’ heet een URL (Uniform Resource Locator). Wanneer de webserver een verzoek ontvangt met een URL, kan deze het bestand ophalen. De webserver wandelt het ‘voetpad’ af en eindigt bij de eindbestemming: het bestand met de nodige informatie.

Web-servers worden daarom gebruikt voor vele hedendaagse applicaties; ze worden uitgerust met speciale programma’s om informatie dynamisch weer te geven. Dankzij de opmaak-conventies hoeven ze maar een enkel bestand aan te passen om de weergave actueel te maken voor alle gebruikers, de browser hoeft alleen maar de pagina te ‘verversen’.

Applicaties die onderliggend gebruik maken van een webserver heten dan ook web applicaties. Populaire webservers zijn onder andere Apache™ web server, IIS™, Lighttpd™. Populaire programmeeromgevingen voor webservers zijn bijvoorbeeld PHP, ASP en Ruby.

Meer lezen over Informatie Technologie? Klik hier voor de inhoudsopgave voor alle artikelen!

©SamRain
Webserver

De software industrie begrijpen: de steigers van een oplossing

“Een wijs man bouwt zijn huis op een rots”
                                                                        - Jezus

Wanneer de software industrie wordt bekeken denkt men in de eerste plaats aan consumentenproducten zoals de machines van Apple of diensten als Google. Echter is de grootste industrie die van de automatisering; bedrijven die het hun vakgebied maken om bedrijven te voorzien van software producten voor hun financien, telecommunicatie, informatie-uitwisseling en digitale archivering. In de automatisering zijn er distinctieve takken aanwezig; namelijk de voorstanders van platformen en de maatwerkleveranciers. De platform voorstanders richten zich op het leveren van oplossingen met behulp van een groot arsenaal technologieën die gezamenlijk een industrie standaard vormen. De maatwerk leveranciers maken, met de riemen die ze hebben, een afgestemde oplossing ‘op maat’ aan de wensen van hun opdrachtgever. Beide vervullen een belangrijke rol; platformen bieden betrouwbaarheid, maatwerk innovatie.

Wanneer praktische automatisering wordt toegepast ligt de voorkeur bij het gebruiken van een platform; de mogelijkheden en restricties zijn vooraf bekend, de gekozen technologieën zijn volwassen en dus minder gevoelig voor fouten zodat een oplossing een robuust fundament heeft. De kosten liggen wel hoger voor de aanschaf van een platform in vergelijking met maatwerk. Dit is echter een bedrog, omdat software altijd zal worden uitgebreid en groeit naarmate er meer complexiteit gewenst is. Maatwerk kost op de lange termijn bijna drie keer zo veel meer voor dezelfde functionaliteit als dat van een platform.

Vaak verwarren techneuten ondernemers vanwege het jargon dat het bedrijfsleven gebruikt met het IT-jargon. Hoewel ze nauw verband hebben zijn beide appels en peren in vergelijking; in de automatisering is een platform een abstract begrip voor een verzameling van technologieën, concreet is het in de IT-technische wereld voor het type besturingssysteem.

Wanneer een oplossing wordt gepresenteerd aan de opdrachtgever is het belangrijk om deze te staven met een bestaand platform. Sterker nog, een goede leverancier van automatiseringsoplossingen zal zich hebben gespecialiseerd in enkele platformen, die als basis dienen voor hun concepten. Goed functionerende concepten worden bij platformen ook veel ‘herbruikt’ waardoor de oplossing onder de kap in betrouwbaarheid toeneemt, kinderziektes worden sneller ontdekt en maken de oplossing volwassen.

Een nog groter voordeel is die van onderhoud; de leveranciers van platformen (‘de vendors’) geven ondersteuning aan de opdrachtgevers die het product hebben aangeschaft zodat incidenten snel en efficiënt worden opgelost. Daarnaast leveren zij nieuwe versies van het platform en leveren extensieve documentatie.

Voor het kiezen van een goed platform zijn er een aantal factoren om rekening mee te houden. Het belangrijkste zijn de mogelijkheden van het platform, gevolgd door de documentatie en ondersteuning. Daarnaast is het kiezen van een bekend platform belangrijk; een platform is namelijk populair vanwege de betrouwbaarheid. Een vaak gemiste factor is de vereiste kennis om het platform te gebruiken (‘learning curve’), dus ook de mogelijkheden om training te volgen en certificering. De prijs is ook een factor; wees echter bewust dat er altijd met de prijs te spelen is, wanneer er sprake is van grotere projecten. Veel platformen bieden een ‘probeerversie’, het is dan mogelijk om de meeste factoren te toetsen.

Net zoals andere grote investeringen is het wijs om eerst zelf goed op de hoogte te zijn van het platform; de leveranciers leveren deze informatie ook vrijblijvend via hun website of medewerkers. Neem geen genoegen met tweedehands informatie; praktijk is de beste leerschool.

Meer lezen over Informatie Technologie? Klik hier voor de inhoudsopgave voor alle artikelen!

©SamRain
Automatisering

De software industrie begrijpen: de levensloop van een oplossing

“Om iets te bouwen heb je bouwstenen nodig en een idee wat dat iets zou moeten zijn”                                                                                                                                      - SamRain

Een oplossing is het antwoord in de vorm van een software constructie; het is de vertaling van de wensen van de opdrachtgever door middel van technologie. Oplossingen kunnen van alles omvatten vanwege hun natuur omdat ze altijd beginnen in een abstracte vorm. Naarmate ze gerealiseerd worden, (om uiteindelijk te belanden in de fase waar de oplossing ook echt deel gaat uitmaken van de kernactiviteiten) groeien ze steeds meer naar een concrete volwassen oplossing totdat ze aan vervanging toe zijn.

Er zijn vijf fases in de levensloop van een oplossing: concept, realisatie, implementatie, testen en productie. Iedere fase is een op zichzelf staan traject waarbij elke fase voorbouwt op het succes van zijn voorloper.

Het concept is de eerste stap van een oplossing. Nadat alle wensen van de opdrachtgever zijn geïnventariseerd moeten deze vorm krijgen in een demonstratie, beter bekend als een ‘PoC’ (proof-of-concept); dit kan een presentatie zijn of een interactief programma waarin functionaliteit verwerkt is dat voldoet aan voornaamste wensen. Het concept is tevens de belangrijkste fase omdat hierin de verwachtingen van de opdrachtgever worden geschept; de kunde van de dienstverlener, de mogelijkheden van technologie en de primaire voordelen die de oplossing biedt voor de opdrachtgever. Ook worden de kosten en benodigde tijd van het ontwikkelen van de oplossing bepaald.

Wanneer het concept wordt geaccepteerd door de opdrachtgever behoort deze gerealiseerd te worden. Ieder detail zal uitgewerkt moeten worden, zoals het samenstellen van een team van uitvoerders, de ontwikkelingsstrategie en voorlopige projectplanning, de opties qua leveranciers voor technische faciliteiten en de budgetten per subfase (‘milestone’); de realisatie brengt het project document voort.

Nadat het project document voltooid is, kan deze worden overgedragen naar de uitvoerders; de fase van implementatie kan gaan plaatsvinden. Tijdens de realisatie wordt de architectuur uitgewerkt. De implementatie is als het ware de start van de daadwerkelijke constructie van de oplossing.

Wanneer een deel tijdens het implementeren is afgerond, is er sprake van een ‘nieuwe’ functionaliteit welke uiteraard getest zal moeten worden of het opgeleverde voldoet aan de verwachtingen. De test fase ligt daarom deels in een grijs gebied, waar functionaliteit in drievoud wordt getest; eerst door de implementerende partij, vervolgens door de bewakers van het concept om vervolgens gepland te worden voor een test door de opdrachtgever. In de testfase worden ook een groep testgebruikers geselecteerd van de opdrachtgever, welke ook behoren tot de groep van daadwerkelijke gebruikers. Het is een cruciale, drukke fase; technische fouten of onverwachte situaties en gevolgen komen hier aan het licht. Als de testfase voltooid is, is er sprake van een geslaagde implementatie en is de software klaar voor industrieel gebruik.

De productiefase is de volwassen periode van de oplossing. Het dient te werken zoals de verwachting die geschept is voor een nieuw ‘apparaat’; snelheid, verwerking, goede documentatie en een positieve gebruikerservaring. Op het moment dat de productiefase ingaat wordt de oplossing ‘cruciaal’ genoemd; als de oplossing stil ligt, kan er niet worden gewerkt, wat dus verlies betekent voor de opdrachtgever. De productiefase staat dan ook in het kader van klachtafhandeling en de procedures van technische ondersteuning, welke al wezenlijk zijn afgestemd tijdens de concept fase.

Hoewel veel dienstverleners graag een cyclus voorspiegelen, blijft de ware levensloop altijd lineair; functionaliteit wordt vooraf bepaald, waarna deze wordt opgeleverd. Opdrachtgevers zullen altijd nieuwe functionaliteit wensen omdat technologie en wensen met tijd veranderen. Al bouwt men voort op bestaande oplossingen, begint men altijd weer aan de tekentafel; kleine oplossingen of groot, ze beginnen altijd met een idee.

Meer lezen over Informatie Technologie? Klik hier voor de inhoudsopgave voor alle artikelen!

©SamRain
oplossing