Can I use this technology in that version of this browser?

In many web projects, the question "Can I use this in the targeted browsers?" is posed too late, resulting in ill fit customer expectations and a lot of tricks to make things work. Solution to his is simple; think before you promise. To help you with that there are many list available on the internet which give you a list of supported technologies for browsers. The site below is (IMHO) particularly handy:

http://caniuse.com: gives you al lot of technologies and techniques with the supporting browser(versions).

Weg met de vuistdikke handboeken voor interface design... er zijn maar een paar simpele regeltjes...

Weg met de vuistdikke handboeken voor interface design... er zijn maar een paar simpele regeltjes... Net zo doeltreffend, maar veel beter te onthouden.

"...

The principles of user interface design are intended to improve the quality of user interface design. According to Larry Constantine and Lucy Lockwood in their usage-centered design, these principles are:

1. The structure principle: Design should organize the user interface purposefully, in meaningful and useful ways based on clear, consistent models that are apparent and recognizable to users, putting related things together and separating unrelated things, differentiating dissimilar things and making similar things resemble one another. The structure principle is concerned with overall user interface architecture.
2. The simplicity principle: The design should make simple, common tasks easy, communicating clearly and simply in the user's own language, and providing good shortcuts that are meaningfully related to longer procedures.
3. The visibility principle: The design should make all needed options and materials for a given task visible without distracting the user with extraneous or redundant information. Good designs don't overwhelm users with alternatives or confuse with unneeded information.
4. The feedback principle: The design should keep users informed of actions or interpretations, changes of state or condition, and errors or exceptions that are relevant and of interest to the user through clear, concise, and unambiguous language familiar to users.
5. The tolerance principle: The design should be flexible and tolerant, reducing the cost of mistakes and misuse by allowing undoing and redoing, while also preventing errors wherever possible by tolerating varied inputs and sequences and by interpreting all reasonable actions.
6. The reuse principle: The design should reuse internal and external components and behaviors, maintaining consistency with purpose rather than merely arbitrary consistency, thus reducing the need for users to rethink and remember.

..."

Bron: http://en.wikipedia.org/wiki/Principles_of_user_interface_design

En achteraf gezien is het eigenlijk zo logisch als het maar kan zijn. Waarom houden we het voortaan dan niet zo simpel eigenlijk?

Leesvoer en andere bronnen

Modellen

(Microsoft) Developing Models for Software Design (UML)

Technologie

(Microsoft) MSDN Channel9 video's over diverse technologieen

Praktijkervaringen en patronen

Microsoft patterns & practices: Application Architecture Guide 2.0 Knowledge Base

Downloadable boek ("Web Architecture Pocket Guide") en:
App Pattern - Four-Tier Web Application Scenario (Table Module)
App Pattern - Three-Tier RIA Application Scenario
App Pattern - Two-Tier Rich Client Application Scenario
App Pattern - Three-Tier Mobile Application Scenario
App Pattern - Three-Tier Web Application Scenario (Domain Entity)
App Pattern - Two-Tier Service Application Scenario (REST)

Microsoft patterns & practices: Windows, Phone, ALM, Web, Engineering Fundamentals, Cloud

Aggregatie, compositie en andere afhankelijkheden: hoe zat het ook alweer?

Aggregatie, compositie en andere afhankelijkheden: hoe zat het ook alweer?

Aggregatie en compositie zijn beide vormen van associatie.


Aggregatie: een ouder-kind relatie tussen objecten waarbij de objecten onafhankelijk van elkaar (kunnen) "leven". De ouder is geen eigenaar van het kind. Wanneer een van de objecten wordt verwijderd, hoeven de kind objecten niet noodzakelijkerwijs te worden verwijderd. In andere woorden: de lifecycles van kind objecten zijn niet afhankelijk van de lifecyle van het ouder object.

Voorbeelden:
Leraar-Studenten
Vader-Kinderen

Compositie: een ouder-kind relatie tussen objecten waarbij de kind objecten afhankelijk zijn van de ouder. De ouder is de eigenaar van het kind. Wanneer de ouder wordt verwijderd, kunnen de kinderen niet meer bestaan. In andere woorden: de lifecycles van kind objecten zijn afhankelijk van de lifecyle van het ouder object.


Voorbeelden:
Huis-Kamers: zonder huis bestaan de kamers niet meer.
Menu-Menu items: zonder menu bestaan geen menu items, menu items behoren noodzakelijk tot een menu.

Leesvoer

UML Association

De beste tools voor een architect

Voor een architect zijn de beste tools: een white board, een setje white board markers, een goede wisser en een aantal inspirerende en kritische collega's.

HansRontheWeb, 3 mei 2013.

Case: de rol van architectuur bij uitbesteding van SharePoint ontwikkeling en beheer (deel 1)

Laat ik met de deur in huis vallen: een klant vroeg mij laatst om "een architectuur te bedenken" om te gebruiken wanneer SharePoint ontwikkeling en beheer uitbesteed zouden worden. Om hier een passend antwoord op te bedenken (eentje waarbij het antwoord niet bestaat uit een stapel papier of PowerPoints die niet worden gebruikt) moeten we de vraag eerst analyseren. Wat bedoelt de klant hier eigenlijk mee en wat heeft hij echt nodig?

Hiervoor moeten we, vanuit de bij uitbesteding betrokken partijen, kijken naar de volgende onderwerpen:

• Uitbesteding;
• SharePoint projecten,

en bepalen in welke opzichten architectuur hier ondersteuning kan bieden.

In deze blogpost deel 1: hoe architectuur kan ondersteunen bij uitbesteding. In een vervolg post de rol van architectuur bij uit te besteden SharePoint projecten.

Uitbesteding
Dit is het contracteren van een externe dienstverlener of toeleverancier om de vantevoren gedefinieerde taken in het vervolg uit te voeren. In de praktijk is het gevolg hiervan dat de samenwerking tussen de verschillende betrokken teams sterk geformaliseerd wordt. En daarbij zijn goede werkafspraken van cruciaal belang. En dan hebben we het alleen nog over het uitvoeren van opdrachten, er zijn in uitbesteding ook anderen fasen van belang. We hebben het hier over:

1. Selectie van een leverancier
2. Transitie van de dienstverlening naar de geselecteerde leverancier
3. Leveren van diensten door de leverancier
4. Beëindiging van het contract met de leverancier en overdracht van de werkzaamheden aan een andere leverancier.

In al deze fase speelt de kwaliteit van werkafspraken een cruciale rol. Dit geldt voor alle betrokken partijen; voor zowel de opdrachtgever als de leverancier:

Als opdrachtgever wil je...

De regie in handen hebben; enerzijds veranderingen kunnen sturen en anderzijds de Total Cost of Ownership (TCO) van het geheel aan diensten beheersbaar houden. Hiertoe moeten diensten, programma's en projecten voldoende op kwaliteit, geld en doorlooptijd kunnen worden beheer(s)d.

Bij de selectie is het daarom van belang om een goede inschatting te maken in hoeverre de diensten van een leverancier bij kunnen dragen aan de bovenstaande doelen. In hoeverre beschikt de leverancier bijvoorbeeld over de juiste kennis en ervaring? In hoeverre ondersteunt hij de gevraagde standaarden? In hoeverre sluit hij aan op het geheel van diensten (b.v. infrastructuur)? Hoe beter de aansluiting, hoe beter de leverancier kan presteren.

Een architectuur beschrijving kan voor de beantwoording van de bovenstaande vragen als een checklist worden gebruikt waarin de aansluiting van de diverse leveranciers kan worden beschreven. De architectuur beschrijving bestaat dan onder anderen uit beschrijvingen van de infrastructuur, platformen, applicaties, koppelvlakken, maar ook van proces standaarden als ontwikkel - en beheerprocessen. Op hoger abstractieniveau (contextueel) kan een beschrijving van de strategie, doelstellingen et cetera worden gegeven om de "richting" aan de geven waarin de opdrachtgever zich wil ontwikkelen. Aansluiting van een opdrachtnemer hierop is eveneens van belang. Immers; als de opdrachtgever zijn diensten op den duur in de cloud wil aanbieden, moet de leverancier daar wel de benodigde ondersteuning voor kunnen (gaan) leveren.

Bij het uitvoeren van de transitie dient de architectuur in eerste instantie ook als checklist. Daarnaast zullen, op de gebieden waar aansluiting niet optimaal is, voorzieningen getroffen moeten worden die ook weer van invloed kunnen zijn op de gebruikte architectuur.

Maar waar het uiteindelijk om gaat is de uitvoering van diensten. Deze moeten beheersbaar uitgevoerd worden (kwaliteit, geld en doorlooptijd). Een architectuur (principes en beschrijvingen) vormen hiervoor uitgangspunt in de vorm van Project Start Architecturen.

Tenslotte, wanneer de dienstverlening wordt beëindigd en de opdrachtgever overstapt naar een andere leverancier, is het voor de opdrachtgever van van belang dat de overdracht van alle lopende diensten zo gladjes mogelijk verloopt en de continuïteit zoveel als mogelijk blijft gewaarborgd. En omdat dit in de praktijk niet van groot belang is van de leverancier waarvan afscheid wordt genomen, is het voor de opdrachtgever des te belangrijker om zorg te dragen voor een kwalitatief goede architectuur.

Al met al wil je als opdrachtgever zowel de opdrachtnemer optimaal laten presteren, en aan de andere kant de risico's van het uitbesteden van werk minimaliseren.

Als opdrachtnemer wil je...

Winst maken en meer opdrachten gegund worden. Hiertoe zal doelmatig en doeltreffend gewerkt moeten worden: hoe beter dit gebeurt, hoe meer winst er immers wordt gemaakt en hoe groter de kans is op een tevreden opdrachtgever die "meer" wil.

Bij de selectie is het daarom van belang om een goede inschatting te maken in hoeverre de eigen diensten aansluiten bij de gevraagde dienstverlening. Net als de opdrachtgever kan een architectuur beschrijving  als een checklist worden gebruikt waarin de aansluiting van de eigen diensten wordt bepaald.

Ook bij het uitvoeren van de transitie dient de architectuur in eerste instantie ook als checklist. Ook hier zullen, op de gebieden waar aansluiting niet optimaal is, voorzieningen getroffen moeten worden die ook weer van invloed kunnen zijn op de gebruikte architectuur. Over eventuele wijzigingen zullen goede afspraken gemaakt moeten worden, die vastgelegd moeten worden in de architectuur, en dienen als uitgangspunt voor de te leveren diensten. Een ontwikkelstraat (omgeving, methoden, tooling) kan als standaard dienst worden geleverd door een leverancier. Om hiervan optimaal gebruik te maken kan het nodig zijn dat de opdrachtgever zijn ontwikkelprocessen en ICT infrastructuur hierop aanpast. Hierop zal de architectuur moeten worden aangepast.

Voor een tevreden klant is het van belang dat diensten minimaal binnen gemaakte afspraken (kwaliteit, geld en doorlooptijd) uitgevoerd worden, en indien mogelijk, "above customer expectation". Dat laatste maakt de kans op meer en gunstiger/omvangrijkere opdrachten groter. Een architectuur (principes en beschrijvingen) en de daaruit afgeleide Project Start Architecturen (PSA) vormen hiervoor het uitgangspunt. Hierin worden de doelen en randvoorwaarden vastgelegd en wordt vastgelegd in hoeverre hierop (natuurlijk afgestemd met de opdrachtgever) afgeweken wordt. Een goede PSA minimaliseert de risico's die in een project gelopen worden en verhoogt de kans dat de opdrachtgever tevreden is met het geleverde werk.

Daarnaast leveren de noodzakelijke en afgestemde afwijkingen op de bovenliggende Domain - en Enterprise Architecturen die in het PSA worden beschreven leerervaringen op die gebruikt kunnen (moeten) worden voor diezelfde Domain - en Enterprise Architecturen.

Bij beëindiging van de dienstverlening moeten de lopende diensten worden overgedragen aan een andere opdrachtnemer. In eerste instantie lijkt een goede overdracht (en daarmee een goede, actuele, architectuur)  niet in het belang voor de "oude" opdrachtnemer, maar in de praktijk ligt dit wat genuanceerder. Een rommelige overdracht is voor zowel de opdrachtgever als de "oude" opdrachtnemer frustrerend. Een goed ingeschat (kosten, doorlooptijd) traject, daarentegen, heeft daarom de voorkeur. En die inschatting kan goed gebeuren met een actuele en complete architectuur (documentatie). Daarnaast laat een goed verlopen overdracht een goede indruk achter die bij een volgende aanbesteding voor de opdrachtnemer gunstig kan zijn.

In het vervolg op deze post de rol van architectuur bij uit te besteden SharePoint projecten...

Architectuur: eenmalige egotrip of gezamenlijk goed?

In de praktijk zie ik nog regelmatig dat architectuur wordt gezien als een onregelmatig terugkerende exercitie waarin grote hoeveelheden PowerPoint slides en lijvige Word documenten worden opgeleverd of als een noodzakelijk kwaad dat (ook vaak achteraf) aan projecten wordt toegevoegd.

Architectuur lijkt vaak (te veel) tijd (en geld) te kosten en te weinig toegevoegde waarde te hebben.

De toegevoegde waarde van architectuur
Komt het bovenstaande bekend voor? Dat is jammer, want architectuur heeft voor u dan niet de toegevoegde die het uw organisatie kan bieden. Architecten kunnen er namelijk voor zorgen dat uw ICT projecten doeltreffender en doelmatiger verlopen. Wat hier dan wel voor gedaan moet worden is dat architectuur zelf doeltreffend en doelmatig wordt ingezet. Hoe dit (op hoofdlijnen) kan worden gedaan zal in dit artikel worden beschreven.

Het doel van een architectuur is, grofweg, het vastleggen van richtlijnen voor (de ontwikkeling van) ICT oplossingen en business processen. Het biedt dus een uitstekende mogelijkheid om programma's en projecten op elkaar af te stemmen. En een juiste afstemming betekent doeltreffender en doelmatiger uitvoeren van programma's en projecten, en daarmee een doeltreffender functioneren van de organisatie in zijn geheel.

Wat hiervoor echter nodig is, is een juiste inzet van architectuur. En daar gaat het in de praktijk vaak mis. Reden hiervoor is dat architectuur vaak veel te veel "los" staat van de van de daadwerkelijke veranderingen in een organisatie (lees: programma's en projecten). Hierdoor wordt architectuur in de praktijk vaak niet of onvoldoende toegepast, wordt niet geleerd van de toepassing ervan en verliest architectuur daarmee snel zijn waarde.

Een geïntegreerde inzet van architectuur
Om architectuur waardevol te laten zijn voor een organisatie is een geïntegreerde inzet ervan cruciaal. Architectuur moet op alle niveau's in een organisatie worden ingezet en leerervaringen die opgedaan worden bij de toepassing ervan moeten ook daadwerkelijk worden verwerkt in de architectuur. Hierdoor wordt architectuur praktisch toepasbaar en wordt de waarde van architectuur zichtbaar verhoogd.

Architectuur op verschillende niveau's
Architectuur kan op verschillende niveau's in organisaties worden ingezet:
- Enterprise level: richtlijnen die gelden voor de hele organisatie
- Domain level: richtlijnen die gelden voor een specifiek toepassingsgebied
- Programma/Project architectuur: richtlijnen die gelden voor een specifiek programma of project

Ieder niveau biedt concrete principes (richtlijnen) voor het daaronder liggende niveau. De principes moeten helder, concreet en praktisch toepasbaar zijn, en zijn daarmee van waarde voor het onderliggende niveau. Principes zorgen ervoor dat keuzes gemakkelijker gemaakt kunnen worden, concepten en oplossingen kunnen worden hergebruikt en risico's beperkt kunnen worden. Daarmee zorgen principes ervoor dat in programma's en projecten doeltreffender en doelmatiger gewerkt kan worden.

Leren van ervaringen
Maar dat is slechts een deel van het verhaal. Richtlijnen bieden in de praktijk namelijk niet altijd een perfecte "oplossing". Soms bieden de richtlijnen geen (precies) passend antwoord op de vraag en moet hierop afgeweken worden. Nieuwe ontwikkelingen, innovaties, uitzonderingen zorgen voor een vraag naar nieuwe antwoorden en nieuwe - en aangepaste principes. En juist aan het doorvoeren van deze nieuwe - en aangepaste principes wordt in organisaties vaak te laat, weinig of geen aandacht besteed.
In programma's en projecten worden vaak nieuwe problemen (uitdagingen) tegengekomen en daarvoor nieuwe concepten en oplossingen bedacht. En jammer genoeg worden leerervaringen vaak niet voor hergebruik geschikt gemaakt waardoor andere programma's en projecten hier niet van kunnen profiteren.

Wat hiervoor nodig is een extra stap die in ieder programma en project zou moeten worden opgenomen: evaluatie en aanpassing van de gebruikte architecturen.

Aan het begin van een programma of project wordt meestal een Project Start Architectuur (PSA) opgesteld, op basis van een Domain (DA) - of Enterprise Achitectuur (EA). Relevante principes uit de DA en EA worden hierin opgenomen, waarbij noodzakelijke afwijkingen hierop worden bepaald, beschreven en onderbouwd. Deze afwijkingen worden met de DA en EA architecten besproken, doorgevoerd, tijdens het project bijgehouden en na afloop van een project geëvalueerd en gedocumenteerd.

Hiermee wordt bereikt dat "leerervaringen" van de toepassing van architectuur doeltreffend en doelmatig worden verwerkt in de diverse architecturen en deze snel praktisch toepasbaar zijn in andere programma's en projecten. De organisatie in zijn geheel leert hiermee dus snel en doeltreffend van de opgedane ervaringen.

Snel veranderende omstandigheden eisen snelle aanpassing
In deze snel veranderende wereld zullen organisaties zich steeds sneller moeten aanpassen aan veranderende omstandigheden. Een organisatie zal dus snel moeten leren van ervaringen. Dit is al een uitdaging op zich, wat alleen maar een grotere uitdaging wordt wanneer organisaties met elkaar gaan samenwerken. Wanneer opdrachten bijvoorbeeld worden uitbesteed aan meerdere partijen is de "grip" die een organisatie heeft op de uitbesteedde programma's en projecten van een nog groter belang. Onjuiste afstemming kost hier namelijk nog meer tijd (en geld) dan het geval is wanneer opdrachten binnen de eigen organisatie worden uitgevoerd. En een goede afstemming kan alleen bereikt worden met een gedeelde architectuur.

Des te meer reden dus om architectuur serieus te nemen, dit op de juiste manier in te richten en dit van "jaarlijks terugkerende exercitie" om te vormen in een continu proces waarmee de organisatie en de partners snel en doelmatig leren van de opgedane ervaringen.