Posts Tagged ‘architecture’

Digitale Duurzaamheid: Waarborgen voor authenticiteit en integriteit

In mijn eerste blog heb ik aangegeven dat er bij digitaliseringstrajecten op een aantal punten meer aandacht nodig is. In deze blog zal ik één van deze aspecten behandelen, namelijk het waarborgen van de integriteit en authenticiteit van documenten.

In de teksten die naar de tweede kamer zijn gestuurd rondom de wijzigingen van het wetboek van Burgelijke Rechtsvordering en de Algemene wet bestuursrecht in verband op de nieuwe wetgeving rondom de digitalisering van de Rechtspraak,  wordt een hele pagina aan dit onderwerp gewijd. Het is uiteraard van belang dat stukken die door de Rechter worden beoordeeld de goede stukken zijn en dat de samenleving er op kan vertrouwen dat er geen wijzigingen in stukken zijn aangebracht (ook niet onopzettelijk). Het feit dat dit in een memorie van toelichting op nieuwe wetgeving staat, geeft al aan dat het onderwerp niet alleen maar op de achterkamertjes van security specialisten wordt besproken, maar dat het op de agenda staat van bestuurders en besluitvormers. Lees Verder

Valt de architect met DevOps weer buiten de boot?

De opkomst van Agile en Scrum creëerde voor veel architecten een kleine identiteits crisis: mag ik nog meedoen, hebben de Scrum teams mij nog nodig, wat is mijn rol in deze nieuwe wereld?

Op dit moment krijgt DevOps veel aandacht, en weer mag de architect zich afvragen: wat is mijn rol in deze nieuwe situatie?

Eerste uitdaging is om helder te krijgen wat DevOps nou precies is? Development en operations in 1 team? Development die ook verantwoordelijk is voor operations? Soort Agile/scrum maar dan gericht op samenwerking tussen Development en Operations, zoals Agile focust op een betere samenwerking tussen opdrachtgever en ontwikkelteams?

Er zijn volgens mij 2 zienswijzen op DevOps die haaks op elkaar staan:

  1. Geen samenwerking – DevOps is ontstaan uit cloud (IAAS en PAAS). Cloud biedt ontwikkelaars een soort self-service omgeving waardoor ze eigenlijk alles zelf kunnen en dus helemaal niet hoeven samen te werken met operations. Operations is zo eenvoudig geworden dat ontwikkelaars dit zelf kunnen. De echte operations zitten bij de cloud leverancier en hebben nauwlijks nog contact met de ontwikkelaars. Ontwikkelaars zijn zelf operations geworden voor de applicaties die ze opleveren. Mooi voorbeeld: Amazon – You build it, you run it
  2. Meer samenwerking – De afstand tussen ontwikkelaars en operations is te groot (gooi maar over de muur, operations kan het aantal releases niet aan, etc) dit is op te lossen door beter samen te werken. Operations en development in 1 team.

De interessantste link die ik zie met architectuur is dat DevOps initieel volgens mij is ontstaan door keiharde standaardisatie vanuit de cloud. Het was duidelijk welke middelen beschikbaar waren voor projecten, onderhandelen met operations was niet meer nodig, en dus konden ontwikkelaars het zelf regelen via een selfservice interface. (IAAS zoals amazon, maar PAAS als heroku trekt dit nog veel verder)

Ik zie vaak dat architecten zich bezig houden met de vraag: “welke middelen gaan we beschikbaar stellen?” terwijl ervaren ontwikkelaars prima de vraag “Hoe gaan we die middelen inzetten voor dit project” kunnen beantwoorden.

IAAS en PAAS middelen worden echter steeds complexer, en het ontwerpen van een goede oplossing vraagt om veel kennis en ervaring. Vraag me wel af of de huidige architecten deze rol nu goed kunnen invullen, gezien ook dit verhaal: CloudCheckr: Amazon Complexity Challenges Many Users.

Net zoals bij Scrum draait DevOps vooral om het sneller leveren van software. Minder schakels levert meer snelheid op. Snelheid is iets wat erg gewenst wordt door “de business” en wat nu vaak als problematisch wordt ervaren.

Vroeger was snelheid vaak synoniem met productief: ontwikkelaars hadden productieve tooling nodig (drag en drop, visueel) en dan zouden ze sneller kunnen ontwikkelen, en daardoor sneller opleveren.

De laatste jaren zie je dat mensen zich realiseren dat snelheid meer aspecten heeft:

  • beter samenwerken, minder over de muur (agile), minder schakels,
  • automatiseren van alle stappen (test, continuous deployment, continuous integration)
  • automatisering van alle stappen betekent ook dat operations meer bezig is met scripten (dev) zodat alles sneller en herhaalbaarder wordt.

Als een architect iemand is die vooral bezig is met keuze van middelen, dan zou een DevOps architect dus goed moeten begrijpen dat de keuze moet gaan naar tooling die automatisering enabled. Tools die inzet van continuous integration en continuous deployment mogelijk maken, een cloud platform wat mbv APIs geautomatiseerd ingericht kan worden.

Pensioenfondsen met Enterprise Architectuur de toekomst tegemoet!

9 vlaks model Maes bij Pensioenfondsen

Recentelijk heb ik een uitvoeringsorganisatie van een Pensioenfonds geholpen bij het zetten van de eerste stappen richting het werken met Enterprise Architectuur. Op basis o.a. deze ervaringen besloot ik een blog te schrijven waarom Enterprise Architectuur de komende tijd zeer belangrijk kan worden voor pensioenfondsen. Het toepassen van Enterprise Architectuur kan pensioenfondsen helpen om voorbereid te zijn op toekomstige ontwikkelingen en hierbij een extra voorsprong te krijgen op concurrenten.

Door het versterkte toezicht van de afgelopen tijd door DNB en de vele herstelplannen die op dit moment in uitvoering zijn, is de focus van pensioenfondsen sterk gericht op risico reductie. Zo moeten processen ISAE 3402 gecertificeerd worden en worden risico analyses uitgevoerd op de gebruikte applicaties en techniek. Allemaal acties die bijdragen aan een gedegen uitvoering  van vermogensbeheer en pensioenbeheer processen, maar ook een aanpak welke zeer eenzijdig is.  Sterk geredeneerd vanuit zaken die nu niet goed zijn. Wat ik hierbij mis zijn de zaken waar een pensioenfonds sterk in wil zijn, zowel nu als in de toekomst.

De onderstaande figuur geeft mijn visie weer op de plaats waar Enterprise Architectuur een rol speelt in de organisatie.

In de figuur wordt het negenvlak model van Maes weergegeven. Dit model onderscheid 3 besturingsdomeinen (Business, Informatievoorziening en ICT) en een drietal besturingsniveaus zoals we die kennen (Strategisch, Tactisch en Operationeel). Bij Pensioenfondsen is de nadruk op dit moment sterk gericht op toezicht op het Inrichting niveau (tactisch) van de besturing. Aan de Business kant is dit de compliance van ISAE 3402 en aan de Informatievoorziening kant zijn dit risico analyses die daar worden uitgevoerd. Tegelijkertijd worden er mondjesmaat bedrijfsplannen en informatie beleidsplannen opgesteld om te kijken waar de organisatie heen dient te gaan.

Verbindende schakel
De factor welke als verbindende schakel kan dienen om al deze gebieden in samenhang te beheersen is Enterprise Architectuur. Op basis van strategische plannen, wordt een samenhangend bestemmingsplan ontwikkeld voor de gehele organisatie, waarin processen, producten, applicaties en techniek in samenhang worden bekeken. Enterprise Architectuur zorgt hierbij voor inzichtelijke modellen waarmee sturing door het management mogelijk is, maar ook voor samen afgesproken principes waaraan projecten zich dienen te houden, zodat alle nieuwe ontwikkelingen direct goed en beheerst kunnen verlopen. Een goed voorbeeld hierbij is de ontwikkeling dat er steeds meer behoefte ontstaat bij deelnemers van pensioenfondsen om inzicht te krijgen in hun specifieke situatie, maar ook om mogelijkheden door te kunnen rekenen rondom pensioenoplossingen. Prioriteitstelling op deze klantprocessen, zorgt voor een verhoogde prioriteit bij de ontwikkeling van de website van het pensioenfonds. Dit is echter vaak minder eenvoudig dan gedacht. Een uitvoeringsorganisatie kan kiezen voor een externe beheerde site (of gedeelte ervan), gegeven van de deelnemers dienen up to date te zijn en te raadplegen op de site, wat de nodige integratie problematiek en beveiligingsproblematiek met zich meebrengt en de servers waar alles op draait moeten uiteraard goed beveiligd zijn en vormen wellicht onderdeel van een (private) cloud. Kortom een de samenhang tussen processen, applicaties en techniek op basis van een ontwikkeling in de markt dient in samenhang te worden bekeken.

Uit mijn praktijk heb ik gemerkt dat het heel eenvoudig is om eerste stappen te zetten met de implementatie van Enterprise Architectuur bij een Pensioenfonds, waarbij direct ook veel toegevoegde waarde gecreëerd kan worden. Ik onderscheid een 3-tal stappen.

Inzicht in de huidige situatie
Het in kaart brengen van de huidige situatie rondom processen, applicaties en techniek is in mijn ervaring zeer waardevol gebleken. Processen die waren vastgelegd conform ISAE 3402, bleken in de praktijk toch niet zo volledig als gedacht. Het gestructureerd volgens Archimate (modelleertaal voor Architectuur) vastleggen van de product- en procesarchitectuur gaf direct toegevoegde waarde bij de identificatie van nieuwe processen en ook input voor het management team om hun eigen Operating Model af te stemmen en te bespreken.

Daarnaast gaf inzage in de applicatie architectuur direct input voor extra noodzakelijke risicoanalyses. Zowel voor applicaties die nog niet waren geïdentificeerd, als ook voor de veelheid van informatiestromen tussen de applicaties. Het voordeel dat Enterprise Architectuur biedt door te focussen op samenhang, kwam hierbij goed naar voren.

Visie op de toekomst
De volgende stap is het inbrengen van visie in de Enterprise Architectuur. Dit brengt met zich mee dat er duidelijkheid dient te ontstaan over de ontwikkelingen waar een Pensioenfonds voor staat, en de wijze waarop hier meer omgegaan zal worden in de komende jaren. Nieuwe wetgeving op pensioengebied is uiteraard een belangrijke input hierbij, maar ook nieuwe producten die een pensioenfonds wil gaan aanbieden voor andere verzekeringen, zoals Zorg. Een andere tendens is de verdergaande concentratie van uitvoeringsorganisaties, waar een pensioenfonds beter goed op voorbereid kan zijn dan zich dit te laten overkomen. Kortom, in de visie fase dient een echt bestemmingsplan opgesteld te worden waarin de richting welke een pensioenfonds op wil, wordt vertaald naar een bestemmingsplan van producten, processen, applicaties en techniek.

Sturen
Enterprise Architectuur is in wezen een besturingsinstrument voor het management. Op het moment dat het bestemmingsplan is opgetekend, kan er ook daadwerkelijke gestuurd worden. Dit sturen is mogelijk aan de hand van afgesproken architectuurprincipes. Deze kunnen door management teams van uitvoeringsorganisaties en de besturen van pensioenfondsen worden vastgesteld, en vervolgens kunnen ze daar op sturen.

Een architectuurprincipe geeft pas waarde op het moment dat ook beschreven wordt Waarom dit een belangrijk principe is en wat de consequenties van dit principe zijn. Een voorbeeld van een architectuur principe bij een uitvoeringsorganisatie is de volgende:

Architectuurprincipe: Snelle en kwalitatief goede Integrale Management Informatie
Toelichting De uitvoeringsorganisatie dient snel en kwalitatief goede Integrale Management Informatie te voorzien aan hun klant het Pensioenfonds, de toezichthouder DNB, als ook de interne organisatie. De informatie moet snel en zonder fouten op te leveren zijn
Rationale Gezien de steeds sterker wordende  toezichtfunctie op pensioenfondsen dient de management informatie snel opgeleverd worden met 0% fouten. Daarnaast verwachten pensioenfondsen een steeds betere dienstverlening op dit vlak, gezien de eisen die aan hun worden gesteld.
Consequenties Het proces van opstellen van management informatie dient zo min mogelijk handmatige bewerkingen te ondergaan.

Management informatie moet zoveel mogelijk geautomatiseerd uit brongegevens van de administratiesystemen worden afgeleid.

Applicatie overstijgende rapportages voor sturing en verantwoording wordt ondersteund vanuit een centrale rapportagevoorziening

Met de modellen van het bestemmingsplan in de hand en de principes vastgesteld, kan een pensioenfonds vervolgens een projectenportfolio opstellen voor de komende jaren. Hiermee kan gericht gewerkt worden aan het bereiken van de eigen doelstellingen, binnen de afgesproken kaders (principes).

Pensioenfondsen met Enterprise Architectuur de toekomst in

Enterprise Architectuur wordt een besturingsinstrument, wanneer deze projectportfolio regulier wordt doorgenomen en er ook rapportages worden opgesteld, waarin de samenhang tussen projecten inzichtelijk wordt weergegeven. Management kan dan besluiten nemen over nieuwe principes, afwijken van huidige principes, schuiven van prioriteiten ed. Enterprise Architectuur wordt een normaal onderdeel van de bedrijfsvoering welke zorgt voor samenhang, maar bovenal zorgt voor een stuk toekomstgerichtheid waarmee Pensioenfondsen een duidelijke toegevoegde waarde kunnen behalen. Een beetje minder de focus op wat er allemaal fout kan gaan in de huidige situatie, en een beetje meer wat er allemaal goed kan gaan in de toekomst.

Volgende blog
In een volgende blog wil ik stilstaan bij de 5 belangrijkste ontwikkelingen die ik zie voor Pensioenfondsen en de wijze waarop het gebruiken van Enterprise Architectuur daar toegevoegde waarde kan bieden.

Roundtable Product Management & Architectuur

Op woensdag 16 november organiseert IT-eye een roundtable rond het thema Product Management & Architectuur. De roundtable zal worden gehouden ten kantore van IT-eye aan de Waterveste 1-3 in Houten.

Wat gaan we bespreken?

Agile systeemontwikkeling is niet meer weg te denken uit de dagelijkse praktijk van IT afdelingen van grote en kleine organisaties. Technieken als Scrum en Open Agile worden steeds meer toegepast, maar nog met wisselend succes. IT-eye vindt dat Agile systeemontwikkeling binnen organisaties sterk kan verbeteren door de toepassing van Product Management & Architectuur.

Tijdens de agile roundtable deelt IT-eye haar visie met de aanwezigen en gaat in de op de vraag hoe je met agile echt successen boekt. Daarnaast is er natuurlijk voldoende ruimte om kennis en ervaringen te delen, te leren van collega’s, en kritische vragen te stellen. Na deze avond heb je een helder beeld van de toegevoegde waarde van Agile, en wijze waarop de juiste inrichting van Product Management & Architectuur je grip bieden op IT ontwikkelingen in je organisatie.

Het programma

Het programma voor de roundtable ziet er als volgt uit:

16:00-16:30 Ontvangst
16:30-17:15 Roundtable 1: Product Management is the key!
17:15-17:30 Pauze
17:30-18:15 Roundtable 2: Architectuur is cruciaal voor Agile
18:15-19:00 Diner
19:00-19:45 Roundtable 3: De IT-eye methode voor Architectuur binnen Agile: Agile Architecting
19:45-20:30 Borrel
Tijdstip Beschrijving

De avond is opgedeeld in 3 onderdelen:

  1. Roundtable 1: Agile draait niet om software development. Het is in eerste instantie een raamwerk voor product managers. Voor een succesvolle inzet van Agile is het essentieel dat dit wordt onderkend in de organisatie.
  2. Roundtable 2: ”Agile is leuk voor kleine teams, maar werkt niet voor grote organisaties”. Dit is een veelgehoorde zorg. Architectuur biedt hier de oplossing. Wij laten u zien waarom architectuur essentieel is voor bedrijfsbreed Agile ontwikkelen.
  3. Roundtable 3: Afsluitend kijken we naar het architectuur proces: hoe zorgt u ervoor dat de manier waarop u architectuur bedrijft zo goed mogelijk aansluit bij Agile product development? Traditionele manieren van architectuur bedrijven gaan vaak ten koste van de voordelen van Agile. Agile Architecting is de methode die IT-eye hanteert om Architectuur zo goed mogelijk aan te laten sluiten bij Agile.

Inschrijven

Nieuwsgierig? Meepraten? Meld je nu kosteloos aan via secretariaat@it-eye.nl

Source Code is the documentation

In an Agile environment we try to creat “just enough documentation” and “just enough architecture”. To achieve this we need our source code to become a part of the documentation.
At this point most developers will jump in the air and all others will go “oooh NO”. The reason why we have such reactions is because developers think they don’t need to do anything and all others think the code is not readable. I must say that in the past the last argument was pretty much true, but all of this has changed or it needs to change fast.
Developers need to start creating more clean and readable code. The first reason why they need to do this is because the code gets better and is easier to maintain. The second reason is Developers need to be aware that the source code is part of the documentation, because they are not the only ones that need to be able to read it. But it’s not only the Developers that need to change, others in the project need to accept that the source code is a part of the documentation as well.

There are enough books, tips and principles to achieve this clean and readable code, some examples SOLID principles, Clean Code, Boy scout rule. To show what I mean here is an example.

Bad example, we can all conclude that this peace of code is not easy to read.

@Override
    public void onCreate(Bundle savedInstanceState)
    {
	context = getApplicationContext();

	// TODO: check for incoming intent?
	intentValue = null;
	checkForIntent(getIntent());
	super.onCreate(savedInstanceState);
	properties = PreferenceManager.getDefaultSharedPreferences(Beta_SMS.this);
	// Check if the account is valid, if not open the wizard (should happen only the first time you open the app
	if (!Utils.checkForValidAccount(properties))
	{
	    startActivity(new Intent(this, Wizard.class));
	}

	// Set the view
	Log.d(Const.TAG_MAIN, "Creating the view and the rest of the GUI.");
	super.onCreate(savedInstanceState);

	//allow custom title
	requestWindowFeature(Window.FEATURE_CUSTOM_TITLE);

	setContentView(R.layout.betasms);

	//set custom title
	getWindow().setFeatureInt(Window.FEATURE_CUSTOM_TITLE, R.layout.title);
	txtTitleSaldoValue = (TextView) findViewById(R.id.txtTitleSaldoValue);
	txtTitleSaldo = (TextView) findViewById(R.id.txtTitleSaldo);	

	//show providers
	providers = getResources().getStringArray(R.array.providers);

	//get the rest of the ui components
	to = (AutoCompleteTextView) findViewById(R.id.txtTo);
	txtTextCount = (TextView) findViewById(R.id.txtTextCount);
	txtSmsText = (EditText) findViewById(R.id.txtSmsText);
	send = (Button) findViewById(R.id.btnSend);
	contact = (Button) findViewById(R.id.btnContact);

	// get the balance
	showBalance();

	txtSmsText.addTextChangedListener(new SmsTextCounter(txtTextCount));

	if (intentValue != null)
	{
	    to.setText(intentValue);
	}

	// auto complete contacts, show all phones
	phoneHandler = new PhonesHandler();
	to.setAdapter(phoneHandler.getContactsPhonesListAdapter(getContentResolver(), this));

	// Set the intent for selecting the contact
	intent = new Intent(Intent.ACTION_PICK, ContactsContract.Contacts.CONTENT_URI);

	// When taped it will fire up an intent for showing Contacts,
	// when a contact is selected it will return and fire up
	// onActivityResult function
	contact.setOnClickListener(new View.OnClickListener()
	{
	    public void onClick(View v)
	    {
		Log.d(Const.TAG_MAIN, "Double taped, show contacts");
		startActivityForResult(intent, Const.PICK_CONTACT);
	    }
	});

	// when send clicked
	send.setOnClickListener(new View.OnClickListener()
	{
	    public void onClick(View v)
	    {
		onSend();
	    }
	});

	// set focus on the sms text field
	txtSmsText.requestFocus();
    }

Good example, I hope we all agree when I say that this code is easy to read and to follow.

@Override
    public void onCreate(Bundle savedInstanceState)
    {
	Log.d(Const.TAG_MAIN, "Starting the application");
	// set context to a helper class
	ApplicationContextHelper.setContext(getApplicationContext());
	super.onCreate(savedInstanceState);
	setBroadcastReceiver();

	loadProperties();
	validateAcount();
	setView();
	assignUiComponentsToVariables();
	showBalance();
	checkIntent(getIntent());
	setListeners();
	// set focus on the sms text field
	txtSmsText.requestFocus();
    }

Both the first and the second example do exactly the same but the second one can be understood in seconds where the first one first needs to be interpreted. In the second example I left the “detailed” code out on purpose because it is not about the detailed code. When we talk about documentation we want to know more about the flow and the relations not the details. If done correctly the details should already be tested and can be reviewed by looking at the test cases.

To consolidate or not?

Interesting discussion: does it make sense to consolidate ERP systems into one, or is it ok to have multiple systems in your enterprise?

Big Data offers an interesting alternative to consolidation. You can do it later. No need to integrate the operational ERP systems. Just dump all your data into your Big Data solution, and analyze it when needed.

Contact

Wattbaan 51-1, 3439 ML Nieuwegein, Nederland
Telefoon: 030–602 82 80
Website: http://iteye.wpengine.com
Email: info@it-eye.nl