donderdag 1 september 2022

(Dutch) Hoe staat het met het gebruik van open standaarden in in aanbestedingen, de toepassing in overheidsbrede voorzieningen en overig gebruik?

Forum Standaardisatie onderzoekt jaarlijks het gebruik van de standaarden van de "Pas toe of leg uit"-lijst. Het onderzoek richt zich op de vraag naar open standaarden in aanbestedingen, de toepassing in overheidsbrede voorzieningen en overig gebruik.

Het Forum is medeoprichter en lid van het Platform Internetstandaarden. Samen met het Platform Internetstandaarden maken ze zich sterk voor de adoptie van Internetstandaarden die fraude met e-mail en websites tegengaan. Het Platform Internetstandaarden heeft het zelf test tool internet.nl ontwikkeld.

Meer informatie en de rapportages vind je hier: https://www.forumstandaardisatie.nl/metingen/monitor

donderdag 30 januari 2020

Capgemini CoP Architecture NL evening on Agile & Architecture: the continuing discussion...

How do you ensure that your architecture is kept up-to-date and actively used when working with Agile/SCRUM teams or in a SAFe organized company? And how do you break through the demand-supply culture between business and ICT (which is crucial for being "agile")?

What we did this evening...

During our CoP Architecture NL evening on "Agile & Architecture", we shared knowledge and discussed our experiences on the role of the architect and his/her work in an Agile context.



Our colleague Ben Kooistra gave us an excellent introduction in Agile/SCRUM/SAFe and the position & work of the architect. He also teaches the Capgemini Academy "Architecture in Agile context - Practitioner training".



In our CoP Architecture NL we did a brief study on the experiences of our architect colleagues who work for clients who work to a greater or lesser extent according to Agile / SAFe. This evening we shared and discussed the results with the attendees. It seems that our findings are broadly supported.



The CJIB (Centraal Justitieel Incassobureau) also shared their Agile & Architecture experiences with us. A lot has been achieved there but (also) there is still a lot to do.

During a forum discussion in which I was one of the panel members, we had the opportunity of discussing questions and standpoints with the audience. Lively discussions, and lots of inspiration!




This will certainly have a follow-up, we are actually already thinking of an ongoing discussion within the Wednesday Evening Training.

Thanks Ben Kooistra for sharing your knowledge with us! Thanks to Birgitte Starrenburg, Dennis Hermsdorf, Martin Brommer, Mirko van der Maat for the organization and contribution!

Learn more? Join us?

​​​​​​​Contact me to learn more on Capgemini and our Architect Community of Practice.

maandag 23 december 2019

Capgemini Netherlands' yearly tradition: Patatjesdag (French-fries-day)!

A great opportunity for our kids get acquainted with new technologies, to have a lot of fun ... and have tons of French fries in the bargain!


















vrijdag 20 december 2019

Architecting the Ecosystem: 5 Challenges for 2020 and beyond

The web is getting more complicated, due to increasing pressure on companies to adapt faster and more efficiently and lots of new technologies that are made available, at a much broader scale.

It has become a huge continuously changing ecosystem in which we must find new ways to control architecture.

Read more about 5 challenges for 2020 and beyond: https://hansrontheweb.blogspot.com/2019/12/architecting-ecosystem-5-challenges-for.html

donderdag 1 augustus 2019

UPDATED! My collection of links to various architecture (mostly technology related) resources

I've updated my collection of links to various architecture (mostly technology related) resource. This collection is not complete (it is quite a mess actually) but it will be supplemented and restructured on a regular basis. 

See: https://hansronarchitecture.blogspot.com/p/architecture-resources-my-link.html (or the "Architecture resources" link in the header)

zondag 8 februari 2015

vrijdag 4 april 2014

Capgemini's TechnoVision: an update on technology trends with transformation potential

A yearly "need to know" explanation on technology trends with transformation potential in Capgemini's TechnoVision. It looks at technology first and business second...

Links

TechnoVisions of pas years:
Download the TechnoVision 2014 paper
Technovision 2014 presentation on SlideShare
TechnoVision 2017
TechnoVision 2018: The Impact of AI

TechnoVision Clusters: Capgemini has identified 17 key information technology trends that it believes will be most relevant to our clients and have grouped these trends into seven TechnoVision clusters.

maandag 3 maart 2014

Reviewing an ICT solution/platform: what documentation and other things you need?

On a regular basis, I'm asked to do a quick review on an ICT solution or platform. This with the intention to take over the management and maintenance of the system. For a quick but effective review, you'll need documentation and contacts. To avoid being flooded with a lot of irrelevant documentation I have devised a set of documents that help me to form a decent picture of the quality of the solution or platform.

The document set is based on the information that you need to make changes and extensions to the software, to solve incidents, to explain the operation of the system and to advice on modifications, extensions and migration.

Principles and requirements

To be able to determine what purpose the software has been created for and what standards/high level requirements are to be met.

Documents:

  • (Project) Start Architecture: e.g. basic principles, design and implementation standards
  • Roles / persona's and user stories
  • Requirements; both functional and non functional

Solution / software architecture

Preferrably a high level solution architecture diagram that refers to more detailled documentation like technical designs.

Information on:

  • Standards/standards/frameworks to be used
  • Solution scope, interfaces with adjacent ICT components and other dependencies
  • Scalabilty: what boundaries are known to the system and how can the solution be scaled?
  • Security: in what way the system is secured?
  • Flexibility: in what ways the solution can be configurated, extended?

Design documents

  • Standards used
  • Functional design: functions, interaction/flow, entities
  • User interface model: screens, flow, controls, navigation
  • Technical design: database design, classes/objects models, interface designs
  • Implementation/deployment model

Implementation

  • Standards, e.g. frameworks, patterns used
  • Detailled program structure
  • Version history, branches etc.
  • Version planning for future versions, work items, etc.

Deployment/installation and configuration

  • Installation and configuration documentation
  • Release documents of the past x versions / period
  • Environments used (specified) for Development, Test, Acceptance and Production (DTAP)

Quality management

  • Test method used
  • Test plans for smoke tests, system tests, integration tests, regression tests, user acceptance tests
  • Test reports of the past x versions / period

Deployment

  • Infrastructure requirements
  • Software maintenance manual
  • Implementation guide

Techical support and maintenance

  • Health checklist
  • Known issues, solutions and workarounds
  • Backup and disaster recovery procedures and manuals
  • Incident log of the last x months

Usage

  • User documentation
  • Super user documentation (for local support)

Supporting tools

Description of required tooling for:
  • Architecture
  • Design tools
  • Development, e.g. code editors, workbenches, source control
  • Deployment

People

Who can I contact to gain more information and insight on the particular solution/platform?
  • Business owner(s)
  • Architect(s) (solution) responsible
  • Designer(s) / engineer(s) responsible
  • IT professional(s) (installation, configuration, maintenance and support) responsible
  • End user, each role

Of course, this is not an extensive list. Any suggestions are welcome!



donderdag 10 oktober 2013

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).

donderdag 27 juni 2013

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?

donderdag 9 mei 2013

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


donderdag 2 mei 2013

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...

zaterdag 30 maart 2013

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.

maandag 5 december 2011

Architectuur standaarden

ArchiMate:
Business Process Modeling Notation (BPMN)

Design and Engineering Methodology for Organizations (DEMO)

Integrated Architecture Framework (IAF)

Model Architectuur Rijksdienst (MARIJ)

Nederlandse Overheid Referentie Architectuur (NORA)

Provinciale Referentie Architectuur (PETRA)

The Open Group Architecture Framework (TOGAF)

TOGAF online: reference guide

Unified Modeling Language (UML)

Zachman








Tools

http://www.modelworld.nl/
Modelworld is een gratis online tool voor het maken van business architectuur modellen, business proces modellen en informatie systeem modellen. Ondersteund worden: ArchiMate, DEMO, BPMN, UML, Mockups.

Archi
Archi is gratis, open source, cross-platform en ondersteunt ArchiMate.

ArchiMate Starter's Kit
Veel documentatie over Archimate, maar ook een aantal Visio sjablonen waarmee meteen aan de slag gegaan kan worden.



Online modeling tool: www.modelworld.nl

Modelworld is een gratis online tool voor het maken van business architectuur modellen, business proces modellen en informatie systeem modellen. Ondersteund worden:
- ArchiMate
- Design and Engineering Methodology for Organizations (DEMO)
- Business Process Modeling Notation (BPMN)
- Unified Modeling Language (UML)
- Mockups

Modellen worden op een centrale server opgeslagen. De modelleertools werken in een browser, zonder daarbij gebruik te hoeven maken van plugins. Aangeraden browsers zijn Internet Explorer 9, Firefox 5, Chrome 12 en Safari 5.1.

De modellen kunnen door meerdere gebruikers tegelijk worden onderhouden. Ideaal voor in situaties waarin je niet de beschikking hebt over tools of wanneer je tools niet mag installeren op je pc.

Beta versie
Het gaat hier om een beta versie. Daardoor kunnen opgeslagen modellen verloren gan wanneer de server wordt gereset.

http://www.modelworld.nl/
Modelworld kan hier gevonden worden.
Voor uitleg is een Wiki beschikbaar.

vrijdag 11 november 2011

Een informatie werkplek bestaat uit meer dan een website

Soms kan ik wel van de daken roepen. Dit is niet iets dat ik vaak bij klanten doe, tenzij ik te vroeg mijn koffie uit de automaat tracht te halen, het blijkt dat ik eerst een bekertje had moeten plaatsen en de automaat de hete koffie plichtsgetrouw maar niet gebruiksvriendelijk over mijn hand giet. De reden waarom ik dit soms figuurlijk wil doen is dat SharePoint weer een keer als Steen der wijzen wordt gebruikt. Nogmaals: het is een mooi, veelomvattend platform, maar soms zijn er handiger oplossingen waarin SharePoint een onderdeel is, en niet de totale oplossing. Dit vergt echter een kritische blik en vantevoren nadenken.

Maar wat is het geval?
SharePoint wordt vaak inzet als portal (in de vorm van en website), als (web) toegangsdeur en bewaarplaats voor documenten, andere informatie en functionaliteit. Dat is op zich terecht, want SharePoint leent zich daar uitstekend voor. Maar bij het doen van "dagelijks werk" hebben eindgebruikers nueenmaal indivuele eisen en wensen. En gezien eindgebruikers zowel de beschikking hebben over een ruime hoeveelheid aan gereedschappen (lees: applicaties en apparatuur) en ze de laatste decennia veel ruimte hebben gekregen hun eigen informatiewerkplek (lees: pc, desktop, "windows" of andere omgeving) zelf in te richten, is het opleggen van een nieuwe werkwijze (lees: een website waarin ineens (samen)gewerkt moet worden), een uitdaging.

Een concreet voorbeeld: de "startpagina"
Een voorbeeld van wat ik in de praktijk tegenkom is de zogenaamde startpagina; een pagina die als verplichte toegangspoort wordt gebruik voor functionaliteit die ook (of beter) via andere wegen kan worden benaderd. Neem nu een startpagina voor het maken van vergadersites. Een vergadersite is een SharePoint website waarin informatie over een vergadering en documentatie bij een vergadering wordt opgeslagen. Aanmaken ervan wordt verplicht gesteld via de startpagina terwijl vergaderverzoeken door eindgebruikers worden gemaakt in Outlook. De eindgebruiker moet dan twee handelingen uitvoeren in twee verschillende applicaties: namelijk aanmaken van een nieuwe vergadering in Outlook en de bijbehorende website aanmaken via de startpagina in SharePoint. En tot overmaat van ramp moet de eindgebruiker de vergadersite ook nog op de een of andere manier laten gebruiken door de deelnemers aan de vergadering. Dat kan hij doen door de een mail te sturen of door de link in de vergadersite op te nemen. Dit legt de eindgebruiker dus een omslachtige manier van werken op die in de praktijk natuurlijk slecht zal worden gebruikt en zal worden omzeild.
Een betere oplossing voor de bovenstaande casus is de vergadersites via Outlook te kunnen aanmaken en beheren en de startpagina te gebruiken als "een handig overzicht van alle vergaderingen". Zo sluit de SharePoint vergaderruimte aan op de vertrouwde en handige werkwijze van de eindgebruiker. Gevolg: de eindgebruiker is eerder geneigd vergadersites te gebruiken en informatie wordt beter en op een handiger manier gedeeld; deelnemers aan de vergadering hebben bijvoorbeeld allemaal dezelfde versies van agenda's, notulen en andere documentatie.

In het bovenstaande voorbeeld is duidelijk is dat de inzet van alleen SharePoint (websites) onvoldoende (en zelfs onhandig) is.

Wat hier verkeerd gaat is dat uitsluitend wordt uitgegaan van de website functie van SharePoint, niet van het totaal aan gereedschappen (lees: apparatuur en applicaties) die de gebruiker ter beschiking heeft. Daarmee wordt SharePoint, en niet de eindgebruiker, als uitgangspunt genomen. En dat is fundamenteel fout.

Uitgangspunt: de eindgebruiker
Uitgangspunt zal altijd moeten zijn: de eindgebruiker. In dit geval natuurlijk gemodelleerd in een persona (of meerdere persona's). Een persona, een archetype van een gebruiker, ofwel een karakterisering van een bepaald type van gebruiker (zie: http://nl.wikipedia.org/wiki/Persona_(IT)), geeft de analist, ontwerper, bouwer inzicht in de doelstellingen, omstandigheden en voorkeuren van een eindgebruiker(stype). Daarmee kan de te bouwen oplossing beter afgestemd worden op de behoeften van de eindgebruiker. Wat hierin, mijnsinziens, nogal eens over het hoofd gezien wordt, maar toch belangrijk is, zijn de gereedschappen die de eindgebruiker tot zijn beschikking heeft en het gebruik ervan voor zijn taken in de diverse omstandigheden waarin deze eindgebruiker terecht kan komen. Klinkt misschien cryptisch? Laat ik een concreet voorbeeld geven...

Maak kennis met de Accountmanager
Persona Accountmanager heeft als taak om produkten bij klanten te verkopen, klanten voor te lichten en klanten te vragen hoe ze de producten ervaren. 't Is een drukke baan waarvoor hij veel onderweg is en onder hoge druk moet presteren. Hij werkt dagelijks in de ochtend op kantoor en tegen de middag gaat hij naar zijn afspraken. Als hij de afspraken heeft gehad gaat hij naar huis en werkt hij daar op zijn laptop verder. Hij heeft daarbij toegang tot het netwerk van zijn werkgever.

De accountmanager werkt onder drie verschillende omstandigheden:
- Op kantoor
- Onderweg, in de auto
- Bij de klant
- Thuis

De accountmanager heeft de beschikking over de volgende gereedschappen:
- Zijn laptop, met daarop MS-Office (Word, Excel, Outlook, Access en PowerPoint ('t blijft een accountmanager), VPN applicatie voor toegang tot het netwerk van zijn werkgever, een WiFi zender/ontvanger, een synchronisatie applicatie om mail met zijn smartphone uit te wisselen.
- SharePoint: de verzamelplaats voor alle documenten van zijn verkoopafdeling, waarvoor een speciale site is ingericht. Hierin zijn offertes, documentatie over de procedures, klantinformatie et cetera opgeslagen. De omgeving wordt door alle accountmanagers gebruikt.
- Zijn smartphone, met daarop een e-mail "App", een "App" voor navigatie, een WiFi zender/ontvanger en GPS (voor zijn navigatie)
- Een WiFi thuisnetwerk voor thuisgebruik van zijn laptop.

In de bovenstaande omstandigheden kunnen niet alle gereedschappen gebruikt worden. En daarbij heeft de accountmanager onder verschillende omstandigheden een voorkeur voor bepaalde gereedschappen.

Voorbeelden
Enkele voorbeelden:
- Op werk mailt de accountmanager met Outlook vanaf zijn laptop. Gebruik van zijn SmartPhone is voor hem minder gebruiksvriendelijk, tenzij hij natuurlijk in een vergadering zit.
- De accountmanager werkt veel in Outlook, Excel en PowerPoint. De documenten slaat hij voornamelijk op op zijn lokale harde schijf. Definitieve versies en versies die door anderen beoordeeld of gebruikt worden, upload hij naar SharePoint (als hij op dat moment tenminste toeganbg heeft tot het netwerk van zijn werkgever). Vanwege de drukte schiet het "delen" van documenten via SharePoint er in de praktijk weleens bij in.
- Onderweg mail de accountmanager via zijn SmartPhone (even aangenomen dat de auto dan stil staat).
- Bij de klant heeft de accountmanager geen toegang tot internet en daarmee ook niet tot het netwerk van zijn werkgever (dit is een aanname voor deze casus, in de praktijk kan toegang technisch mogelijk zijn). Zodoende kan hij niet mailen, en niet bij documenten (SharePoint). Hij kan alleen offline werken. - Thuis heeft de accountmanager via zijn laptop toegang tot dezelfde informatie en applicaties als op werk.

Uit het bovenstaande blijkt dat de accountmanager de beschikking heeft over een aantal gereedschappen die hij onder verschillende omstandigheden wel, liever niet of helemaal niet kan gebruiken. Wat al grote verbeteringen zouden zijn in de gereedschapset van deze accountmanager zijn:
- Kunnen mailen van documenten naar dde gezamenlijke SharePoint site.
- Documenten beschikbaar stellen via een Outlook folder zodat de accountmanager voor de meest recente documenten niet naar de SharePoint web site hoeft te navigeren.
- Automatische synchronisatie van lokaal (laptop) opgeslagen documenten met de documenten in de SharePoint site.

En wat daar natuurlijk bij hoort is een instructie / training om de gereedschappen doeltreffend en doelmatig te gebruiken.

De juiste communicatiemix
Bovenstaande verbeteringen kunnen natuurlijk verder worden aangevuld, maar wat ik ermee wil zeggen is dat hierin verder wordt gekeken dan SharePoint zelf. Er wordt rekening gehouden met (bijna) alle gereedschappen en (bijna) alle omstandigheden waarin de persona zijn taken uitvoert. In andere woorden: de "communicatiemix" (zie voor een aardige definitie hiervan: http://pensioen-wiki.wikidot.com/communicatiemix) wordt zoveel mogelijk afgestemd op de taken en omstandigheden van deze persona.

Te veel focus op websites
In SharePoint implementaties zie ik in de praktijk echter een te grote focus op de website functie van SharePoint en daarmee wordt de eindgebruiker verplicht om alle functionaliteit en informatie via de webbrowser te benaderen. En dat legt de gebruiker beperkingen op, bijvoorbeeld:
- De website is lastiger te gebruiken op apparatuur met een kleiner beeldscherm als SmartPhones
- De gebruiker moet op dat moment toegang hebben tot de SharePoint omgeving, online zijn en b.v. via VPN toegang hebben
- De gebruiker moet zijn voorkeur werkwijze aanpassen. Nu moet hij documenten vanuit een website ophalen en, na aanpassen, hierin weer uploaden.

De makkelijkste weg kan leiden tot ondoelmatig (samen)werken
En in de praktijk zal de eindgebruiker (en zeker eindgebruikers die het druk hebben, zoals onze Accountmanager) de makkelijkste weg kiezen en de beste manier van werken wellicht omzeilen. Dit heeft gevolgen voor het doelmatig uitvoeren van taken (ergens omheen werken kost nueenmaal meer tijd dan nodig), en voor het doelmatig kunnen samenwerken (delen van informatie gebeurt nu minder en meer op ad hoc basis).

Conclusie en aanbevelingen
Bij het bedenken van gebruikersondersteuning wordt vaak uitsluitend uitgegaan van slechts 1 stuk gereedschap, vaak alleen de website functie van SharePoint, niet van het totaal aan de voor de eindgebruiker beschikbare gereedschappen (lees: apparatuur en applicaties). Daarmee worden oplossingen bedacht die niet aansluiten op de behoeften en mogelijkheden van de eindgebruiker, hetgeen het doelmatig uitvoeren van taken en samenwerking niet ten goede komt.
Denk dus breder dan websites en inventariseer eerst de beschikbare gereedschappen en de omstandigheden waarin deze gebruikt kunnen worden.
't Is weer een kwestie van (durven) nadenken voordat de weg van de implementatie wordt bewandeld, en het risico nemen dat dat niet altijd in dank wordt afgenomen.

(Dutch) Hoe staat het met het gebruik van open standaarden in in aanbestedingen, de toepassing in overheidsbrede voorzieningen en overig gebruik?

Forum Standaardisatie onderzoekt jaarlijks het gebruik van de standaarden van de "Pas toe of leg uit"-lijst. Het onderzoek richt z...