Oplossingen ontwerpen: De 5 zuilen van bedrijfsapplicaties

“If you can’t find out the real conditions, then you know who will prevail.”
                                                                                                            - Mei Yaochen

Wie als architect van oplossingen aan een ontwerp wilt beginnen leert al gauw een hoop filosofieën door elkaar. Volgens vele zelfgedeclareerde guru’s zijn er onbreekbare formules – en ik ben van mening dat deze ‘5 zuilen’ een ontwerpfilosofie is die de ‘Tao’ is voor ICT-oplossingen.

Een goed ontwerp vraagt om vijf strategieën vooraf in acht te nemen: de ‘snelheid’, de ‘functionaliteit’, de ‘vormgeving’, de ‘veiligheid’ en de ‘uitbreidingsmogelijkheden’. Verzuim in één van deze en kom te laat achter de pijnlijke resultaten. Beslis verkeerd in één van deze en dweil gegarandeerd met de kraan open. Het excuus is vaak ‘tijd’, maar de waarheid draait altijd uit op onwetendheid. Geen van deze ‘zuilen’ is vanzelfsprekend en ieder van hen is verbonden – wie dat gegeven onderschat, betaald de rekening achteraf. Een hoge rekening, wel te verstaan.

Snelheid, vaak aangeduid als ‘performance’ wordt altijd beloofd, maar zelden gehaald. Een ‘stress’-simulatie wordt vaak achteraf uitgevoerd, waarna de demonstratie veel minder ‘gelikt’ wordt. Dan moet men achteraf ineens compenseren door ‘spierkracht’ in de infrastructuur te plaatsen (wat een dure grap wordt). Ontwerpen voor snelheid is een kwestie van concessies doen en informatie doseren.

1.     Verwerken, uitwisselen en opslaan van informatie kosten snelheid

2.     Complexiteit, modulariteit en synchroniteit kosten snelheid

3.     Een infrastructuur, de omgeving en het platform bepalen de potentiële snelheid.

4.     Snel voor de ‘gebruiker’ en snel voor het systeem zijn twee verschillende begrippen.

De functionaliteit, oftewel de ‘features’, zijn het hart van een ontwerp; ze zijn het skelet van de ‘wensen’. Vaak worden functionele bouwstenen in overvloed gemaakt voor er echt sprake is van kennis over ‘hoe’ de functionaliteit gebruikt zal worden. Teveel functionaliteit die niet gebruikt wordt is als cholesterol voor de aders in een applicatie.

1.     ‘Less is more’, want ‘more’ kosten tijd, onderhoud en snelheid

2.     Gebruik ‘black boxing’, want details kosten flexibiliteit

3.     Vind het wiel niet opnieuw uit, tenzij het wiel vierkant is

4.     Vermijd ‘bottlenecks’ met simulaties, deze kosten snelheid.

De vormgeving is wat een gebruiker ziet. in bedrijfsoplossingen zijn het eigenlijk interactieve formulieren. Beschouw ze dan als zodanig. De vormgeving is cruciaal voor de productiviteit.

1.     Verdeel informatie in brokken – meer informatie kost snelheid

2.     Maak gebruik van ruimte; wat prettig oogt, werkt prettig

3.     Laat zien wat men wilt zien; onzinnige informatie is onzinnig

4.     Voorkom ‘dubbele’ invoer, maar forceer uniformiteit.

De veiligheid wordt vaak naar de infrastructuur geschoven; slechts 10% van de veiligheidslekken vinden er echter plaats buiten het ontwerp. Bescherm daarom op gepaste wijze het ontwerp tegen aanvallers van buiten én binnen.

1.     Alle informatie afkomstig van gebruikers wordt niet vanzelfsprekend vertrouwd – bewaak de ingangspoorten van het ontwerp.

2.     Gevoelige informatie mag niet zonder authenticatie ingezien of aangepast worden

3.     Veiligheidsmaatregelen kosten snelheid; reguleer daarom de informatiekanalen waar de infrastructuur dit toelaat.

4.     Ontwerp een aantal ‘catastrofe’ scenario’s – zonder ‘reddingsplannen’ is de schade bij een lek onbeheersbaar.

Schaalbaarheid (of: scalability) is een andere benaming voor uitbreidingsmogelijkheden. Een ontwerp dat niet kan ‘schalen’ is niet flexibel. Deze zuil lijkt het gemakkelijkst, maar is de pees van Achilles in ontwerpen. Schalen staat gelijk aan snelheid maar ook aan onderhoud. Een ontwerp dat gelimiteerd is aan een bepaalde omgeving is niet schaalbaar. Een ontwerp dat niet parallel kan werken is niet schaalbaar.

1. Ga er vanuit dat alle informatie niet exclusief is voor een individueel ontwerp
2. Ontwerpen moeten parallel ‘naast’ elkaar kunnen werken, zonder de wetenschap van elkaar.
3. Cloud computing maakt de infrastructuur schaalbaar, niet het ontwerp.
4. Ontwerpen moeten beheerd kunnen worden vanuit een ander losgekoppeld ontwerp.

Hoe pak je het ontwerpen van een oplossing dan pragmatisch aan? Filosofisch klinkt het altijd ‘mooi’ – maar hoe doe je dat op de tekentafel?

Een industriële oplossing vereist een scheiding van ontwerp en informatie. Informatie dient daarom altijd thuis te horen in een database. Vanuit een database begint de informatiestroom en is, naast het ontwerp, een cruciaal orgaan. Een database ontwerp bepaalt al vanaf het begin de verwerkingssnelheid – vandaar dat een database ontwerper een aparte discipline is. Een vuistregel voor informatie uit databases is deze: informatie krijgen ‘kost’ minder verwerking dan informatie opslaan. De informatiestromen in kaart brengen is de eerste stap, de data modellen zijn de tweede stap. De derde stap is het advies vragen aan een ‘database expert’ – die kan je haarfijn uitleggen waar ‘views’, ‘indexes’ en ‘stored procedures’ voor zijn.

Een ‘Interaction Designer’ is een communicatie deskundige van formulieren en mensen. Een grafisch vormgever is niet hetzelfde als deze discipline – het gaat om de ‘logische’ opbouw van een formulier en de plaatsing van besturingselementen. De grootste valkuil voor de meeste ontwerpers zijn formulieren – wie als laatst aan deze begint, ontdekt de ‘vergeten’ informatie te laat en doet veel gedaan werk te niet. Bij grote ontwerpen waar meerdere ‘rollen’ gebruik maken van de grafische ‘schil’, is een Interaction Designer geen overbodige luxe.

Qua veiligheid gaat het met name om drie cruciale punten binnen het ontwerp: authenticatie, integriteit en distributiekanalen. Een gebruikersnaam en wachtwoord zijn niet voldoende ter bescherming; zaken als encryptie en database integriteit tegen aanvallen zijn geen zaken om ‘licht’ te nemen. Win daarom advies in van een veiligheidsconsultant. Vuistregel: aanvallen van ‘buitenaf’ zijn infrastructuur, aanvallen op de database via invoervelden en ‘controllers’, identiteitsdiefstallen bij authenticatie procedures. Voorkomen is beter dan genezen!
Functionaliteit is afhankelijk van de componenten; het is een goed plan om het ontwerp a la Scrum/Agile – in de vorm van ‘stories’ op te bouwen – en deze te modelleren als ‘black box’ in simplistische vormen, waarbij de informatie invoer, uitvoer en secundaire informatie duidelijk zijn:

Zodoende kun je functionaliteit ‘hergebruiken’.

De 5 zuilen vragen een ‘omschakeling’, maar het resultaat wordt merkbaar bij een tevreden klant als een opvolgend project, waar je niet bezig bent met het ‘lijmen’ van een ontwerp, maar naar een nieuwe fase van ontwerp ‘volwassenheid’.

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

©SamRain
Bedrijsapplicaties