Agile is inmiddels een term die heel bekend is geworden in de wereld de ICT, en in het bijzonder wanneer het om het ontwikkelen van software gaat. Agile werken is al geruime tijd een populaire manier van voortbrengen. De oorsprong van de huidige manier van denken ligt in het Agile Manifesto dat in 2001 werd gepubliceerd. Daar wordt de kerngedachte achter deze werkvorm uitgelegd, en in enkele principes verder uitgewerkt. Deze principes zijn relatief eenvoudig te vertalen naar werkafspraken en het team kan aan het werk.

In de praktijk veroorzaakt dit echter de nodige problemen. Er kan van alles scheef lopen, terwijl de belofte van Agile werken juist zo positief is. De problematiek ontstaat meestal omdat het manifesto en/of de principes onjuist worden geinterpreteerd, of te letterlijk worden genomen. ‘Werkende software voor uitgebreide documentatie‘ betekent bijvoorbeeld niet ‘geen documentatie‘.

Architectuur is een vakgebied dat vaak schuurt met het agile werken. De premisse van architectuur is dat je vooraf nadenkt voordat je begint, en agile gaat meer uit van het idee dat je begint en leert van fouten en aanpast aan verandering. Ik ben van mening dat beiden elkaar enorm kunnen versterken, juist wanneer je architectuur meer kortcyclisch toepast en vanuit de agile werkende teams de architect als helper wilt zien.

Om te helpen die werelden bij elkaar te brengen heb ik een Nederlandse vertaling gemaakt van het Agile Manifesto en de principes in de vorm van een Architectuur Model, daarbij dankbaar gebruik makend van het Engelse model dat al bestond. Met deze modellering kun je de werkwijze en de uitgangspunten van Agile eenvoudig opnemen in je bedrijfsmodel, je bedrijfsfuncties en de daarmee samenhangende strategie. In Archimate, zodat het matcht met de rest van architectuur.

Doel is dat de Architect Agile beter begrijpt, dat de Architect kan laten zien dat hij Agile begrijpt en dat de Architect meer rekening kan houden met agile en de voordelen ervan, en de Architect beter kan sturen wanneer de nadelen van Agile in de weg lopen. Zeker wanneer architectuur modelmatig wordt bedreven op basis van een stevige repository kan dit helpen om het gesprek te faciliteren en duidelijkheid te creeeren.

Het model staat op mijn github repository https://github.com/wkossen/Agile-manifesto-In-Archimate-NL en heb je ‘m liever toch in het Engels, kijk dan hier: https://github.com/teterkin/Agile-manifesto-in-ArchiMate.

Een kanttekening is dat ik in mijn vertaling een veelgebruikte vertaalfout heb gecorrigeert. De term ‘Self-Organizing Teams’ wordt in Nederland veelal vertaald in zelfsturende teams. Maar dat is echt iets anders dan Zelf-Organiserende Teams. Dat je je werk zelf organiseert (correct) is wat anders dan dat je als team zelf bepaalt waar je met de software naar toe gaat. Dat laatste is namelijk voorbehouden aan de business-owner die dat samen met de (Enterprise) Architect vaststelt en uitwerkt.

Ik hoor graag van je als je het modelletje bruikbaar vind, en ook als je vragen of aanvullingen hebt. Veel succes met de nieuwe vriendschap tussen Agile en Architectuur

Goede titel, toch? Dit is waar het in de wereld om gaat, dit is de kern van het leven, misschien wel de zin van het leven. En in de carriere is het niet anders. Waar gaat het nu echt om? Hoe wordt je nu echt succesvol? Hoe krijg je nu echt dingen voor elkaar?

En waarom lukt het misschien nu minder dan je wilt? Wellicht is het je opgevallen dat in de eerste alinea een paar vragen stonden, zinnetjes die eindigen met een vraagteken. Twee van die zinnen begonnen met het woordje Hoe. en daar zit wel een probleem. De vraag is namelijk of er wel een antwoord is op die vraag…

Succes, groot of klein, is niet iets waarvoor een handleiding bestaat. Succes maak je door actie, door dingen te doen. En voordat je dat kunt is de belangrijkste vraag vooral wie je bent en wat je echt wilt bereiken. Zolang je daar geen duidelijkheid over hebt wordt het helemaal niets. Dus dat is waar je begint. wie ben ik echt, en wat wil ik in deze baan, in deze relatie, in mijn carriere, in de vriendenkring, op mijn bankrekening enz.

Stel dat je het nu weet. Dan komt weer die hoe vraag, hoe verder, en hoe krijgen we nu wel voor elkaar wat eerder steeds niet lukte… Ik kan je vertellen dat je daarin eindeloos kunt blijven hangen. hoe dit, hoe dat, hoe zus, hoe zo… eindeloos. En het antwoord komt niet na het stellen van de vraag. Het antwoord komt na het doen, na het ‘gewoon beginnen’. Wanneer een kleine eerste stap is gezet wordt de weg naar het doel alweer ietsje duidelijker en kun je een tweede zetten. Het hoe wordt als het ware geleidelijk beantwoord door de oplossing in het doen te vinden. Werkt het niet, probeer iets anders. Immers, weer iets geleerd over het hoe. Acta Non Verba, Het motto dat ik al jaren onder mijn emails plaats, is precies dit. Geen woorden, maar daden, niet eindeloos praten of vragen, maar actie, en dan leren we vanzelf wat werkt.

Dat betekent natuurlijk niet dat je zomaar alles moet proberen, of niet meer moet nadenken. Uiteraard blijft koppie koppie belangrijk. uiteindelijk weet je echter allang wat je wilt en allang wat de beste eerste stap is, zelfs wanneer het hele pad nog in sluieren verhuld is. Door te beginnen ontstaat niet alleen helderheid, maar ook een gevoel van progressie, en dat geeft alleen maar meer energie. Het is de energie die uiteindelijk tot het doel leidt, en die creeer je door actie, niet door eindeloos vragen naar het hoe.

Succes !

Photo by Smabs Sputzer
This slowly is becoming the theme of my thinking. Why don’t we just get this done, do it right, make it work, etc. This is what’s interesting to me more and more. Simple things still being hard. Often the reasons aren’t that rational and the thinking isn’t that straight. The last few presentations i’ve been giving had those questions as their main thread of thought.

And I guess these things really are the important matters. With rational thoughts, most IT projects aren’t that hard at all. Most IT problems are fixable with simple measures. But making decisions about those projects has little to do with the technology or the simplicity of it. Instead most of the decisionmaking is about very different subjects. Those include simple ones (like money) but also very complicatied ones. What does this mean for my position as a manager, what risks does this bring for the image of my organisation, what will happen if we fail, how can I keep firm control without knowing the first thing about IT, etc.

I’ve had times where these things frustrated me. Maybe I’m just mellowing a bit, or caring less. Maybe I just got used to it. The frustration has been replaced with wonder. Wonder about the intricate and diffuse and ambiguous and dark nature of the human psyche. Dealing with that is a whole different ballgame compared to dealing with stubborn standards or faulty hardware. And as far as I’m concerned, a bit more interesting as well.

Soon I’ll be speaking again at a conference in the Netherlands. And again, the why question will pop up. I’ll be reporting here about it later. In the mean time, How do you deal with these matters? What’s your experience with decisionmaking in the field of IT? Don’t hesitate to comment!

Photo by quinn.anyaLast Thursday, may 12th 2011, I spoke at the Spring Conference of the Dutch Unix User Group. This conference was themed Open is Efficient. The culmination of 11 years of IT Consultancy boiled down to my presentation. For these 11 years, most of my clients were in Government or semi-government organisations, so that’s what the presentation was about. Why is it so hard for these not-for-profit public organisations to adopt Open.

The first think I did after my introduction was placing Open on the standard stack that IT Architects as myself draw up:

When you do that, it looks like this:

The new thing here is my position that

. This is an important observation as it serves to address the problems with Open Standards, Open Data and Open Source as being seen as technology things which aren’t ‘important’ to business people. That is in fact one of the reasons these Open things aren’t on every manager’s shortlist. Transparency actually touches their stuff. That is what you can talk to them about. Once they ‘get’ transparency, the other things follow naturally as they support transparency, democracy and freedom.

So why is it hard to open up? There are a number of reasons:

One. Private property and ownership. These concepts are ages old. Organisations, and people within them, have the idea that the information they are working on is theirs. In the case of public organisations, they’re wrong. The stuff they’re working on is owned by those paying for it, the tax-payers, us. So hiding stuff from us isn’t the way to go unless there are specific reasons (like endangering people’s lives). All information that isn’t a real and direct hazard when open, should be open.

Property and ownership are very old. They became important when we moved from the hunter-gatherer life into agriculture. In agriculture, the investment you make in terms of time and effort to get food is very big. This means that it’s very important to protect your crop, your field, your granary. Compared to the earlier life, where the investment may top a week (for a large hunting trip), farmers deal with months. Also, when people live together in villages, automatic sharing is lost. Where hunter-gatherers would travel (nomads) in small family groups, now several families flock together and each cares for their own fields, trading amongst themselves. Ownership is important in that situation.

When it comes to government information, this concept isn’t practical anymore. Yet it seems to be hard-coded into our brains. This is a deep-rooted cultural phenomenon and not a rational choice. Therefor, rational argumentation doesn’t help at all to fight it. That’s one of the reasons that it is so hard to get rid of this behaviour.

In next posts I will cover more reasons, so stay tuned.

Photo by Mike Licht, NotionsCapital.com

The problem with predictions is, they can only be evaluated after the fact. And then it’s easy… But let’s see what I thought would happen in 2010 and if it did…

The first thing I talked about in my predictions post was HTML5. I wasn’t so sure it would find broad adoption. I think I was both wrong and right. It certainly found adoption but it also found the age old struggle of conflicting standard implementations. This holds HTML5 back a bit. Apple helped by not supporting flash on their mobile platforms. I certainly didn’t see that coming. They did give people a strong incentive to jailbreak their device though… Youtube supporting HTML5 video certainly helped, too. Still there’s much to gain. I wonder if it will happen this year, but I think it will be a slow process…

The next one was spot on, but it was an easy prediction anyway. Mobile is the big thing in 2010. I even wrote an article about it in a magazine in the Netherlands (Dutch). One thing I didn’t predict was the immense popularity of tablet computers. That one took me by surprise. I don’t quite see the advantage of making something portable bigger. I wonder how much of the success happened because of hype rather than because of real usefulness. As you can tell, I’m not a tablet owner… Ah, and the Nexus died and so did the Microsoft phones.

The opening up of platforms is an ambiguous one. I strongly hope that it will happen but it doesn’t really follow through. You can now export your Facebook stuff but to call that dataportability really takes it too far. It’s a start nonetheless. We need much more though

The teaming up against Google didn’t happen. Google fights with plenty of competitors but doesn’t seems to be phased by them. Hey, and public pressure made wave stick around (but for how long).

The privacy thing. Well… This is an issue. Privacy is still very much in decline. And strangely Wikileaks (which I didn’t expect to be so big) didn’t help either. Because some narrow-minded people in power feel their private parts being stepped on by forced transparency, the call for even tighter security measures (that don’t actually bring any security to you!) has risen and strangely enough, a government that promised openness and transparency now seems to be in favour of measures that would more likely be expected in China, North Korea and Iran. And it’s not just the USA that’s heading the wrong way. This is really very worrying. We won’t see the last of it this year and it won’t change any time soon…

DRM is still here… sigh

but IPv6 has arrived. Not big yet, but the start has been made. In some countries there will be many people this year that won’t have IPv4 connectivity. This means that these people can’t visit your site and buy your products if you don’t support IPv6. I think that some people are slowly realizing that this is happening. Why don’t you become a IPv6 guru like me on ipv6.he.net.

I wasn’t sure if anything spectacular would happen in the Social Media world and I was right. It didn’t. There are slight shifts in popularity between platforms, but nothing spectacularly new happened.

Then about security. I expected to see big things happening in the Mobile world. And some things did, but not to the extend I expected. Are we just lucky?. In the security world there was one thing though that I didn’t expect and that happened: Stuxnet. This is actually really frightening. A very targeted well working hard to combat worm. There’s lots to read about this elsewhere. I suspect that this is the Security Winner of 2010.

Chrome OS takes a bit longer to arrive. I have begun to doubt if it will be successful after all. The reason is the coming of tablet PCs. They’ve taken the Niche that ChromeOS needs. Even though Google is calling this one of the top 3 projects the company is working on (and hiring people for), I am cautious in predicting much success. If people can have Android, why would they need Chrome?

Finally the Cloud and Saas computing. These indeed have become mainstream. Luckily people begin to see some of the drawbacks so we can now discuss the security issues without being silenced by noisy hype-sounds. I might well write a post about this one day…

So I didn’t do too bad, but I didn’t win all either. What do you think about my predictions of last year? And what happened to your predictions? Stay tuned for my Predictions 2011 post that will be following shortly (if time is available…)

ADVANCED WARNING: This post is going to be a bit rant-like… But you may will still like it. There’s some good information, too, that might keep you out of trouble…

You may already know I’m quite fond of OpenID. In fact, any security system that makes life easier for me is very welcome. For some time however, there’s something going on that makes the OpenID system a bit less attractive. Providers that quit. ‘Quit?’ I hear you ask? Yes, Quit!

And that wouldn’t necessarily be so bad if they told their users with advanced notice they were going to do just that. That’s just not what’s happening. I’ll just list a few of the OpenID providers that aren’t anymore:

• Technorati Read about that one here
• Identity.net
• Yiid.com (which is also Identity.net) I got the mail from them this week telling me they just turned of OpenID. So much for advanced warning…
• Cliqset.com I don’t even know what happened. It just stopped working.
• Logmij.in (Dutch OpenID provider) The site doesn’t even exist anymore.
• If you check each one on the list on this site, you’ll find quite a few more that seam to be terminated…

Just imagine that you’re using an OpenID from one of those providers. They gave you an OpenID which you actually used to log-in to other sites, for instance to update your weblog at LiveJournal. Now the provider quits. How are you going to access the sites you’re a valid member of? I’ll tell you, you’re not going to access it, and you’re going to have long talks with the helpful support team of those sites (if those even exist) to get your account back.

Since I’ve been fond of OpenID for a long time, I’ve been keeping multiple OpenIDs. That’s a reasonable back-up strategy, but unfortunately not all sites allow you to assign multiple OpenID’s to your account. This really puts you in a tight spot if your provider thinks it’s a good idea to quit. There are some good examples though. Plaxo for instance allows you to add many OpenID’s. What I don’t understand is why they put the management screen hidden as a sub-screen behind a link on the e-mail-addresses-management page, but this post isn’t about Usability…. 

Even better as a back-up strategy is the ‘Roll-Your-Own’ method. phpMyID allows you to do just that. Host your own private OpenID provider. It will only quit if you decide it will… I’ve been running mine for a long time and that’s the OpenID I add to a site first. If it’s possible to add more, I’ll do so because my site can be down as well and that would lock me out immediately…

Another (very useful) method is to have your own domain or website delegate to your current provider. If you switch providers, you just delegate to the next one from the same domain or website. That way the OpenID doesn’t change even though the back-end provider does… Delegation is easy to set up if you have access to the HTML source-code of your website. In the <head></head> section, you add the following code:

<link rel="openid.server"
      href="https://www.myopenid.com/server">
<link rel="openid.delegate"
      href="http://wkossen.myopenid.com">

Naturally, the entry in href=”” changes depending on who serves your OpenID. Your OpenID provider will tell you what settings to implement or with a bit of thinking, you’ll figure it out… Just note that again, if the delegating website is down, or the OpenID behind that is down, you’re still locked out…

There’s a natural trade-off here. You get to use ONE log-in for MANY sites, but if that breaks, your locked out EVERYWHERE. The alternative is remembering all those passwords and user-names on all those sites the way you used to do. I’ll opt for the first strategy and try to alleviate it as much as possible by adding multiples…

Let me end with stating the obvious here:

1. If you’re providing essential services people rely on like OpenID, don’t just quit,
2. If you have to quit, tell the customer well in advance,
3. Give those people options to move their data (it’s theirs in the first place) –> Dataportability,
4. Assist them in setting up their OpenID elsewhere and tell them how to move their accounts,
5. Even better, why not maintain their OpenID URL and let the user delegate it towards another OpenID?

It’s like the company that sells you petrol just quit and you come to the station in the middle of nowhere with your empty tank. What are you going to do, Push????

Your comments as always are very welcome below. Thanks for reading!

I’m always interested in adding security to information systems. One step in that process is adding authentication. Authentication is aimed at establishing without doubt the identity of the one trying to use (or abuse) the system. And that doesn’t stop with the old user-name-password combo. There are many alternative or additional means to do it, but that’s a topic for another post. There are also ways in helping people authenticate themselves more successfully. Without trying to be complete here, I’ll give you an overview of a few of the possibilities of helping you authenticate, even though it’s single factor authentication.

Passwords are problematic since our human memory isn’t quite foolproof. (how about that for an understatement…) This tends us to choose easy to remember, and therefor almost always easy to guess passwords. Difficult passwords are harder to remember locking the user out, rather then letting them in. Two services have created interesting ways to help you pick the right password without making it too easy for someone else to pick your password: MyVidoop and InkBlotPassword. Both will provide you with an open-id to use on several websites that support that technology.

MyVidoop is still alive.  It’s recently been acquired by http://www.confidenttechnologies.com, and hopefully it won’t shut it down  since this service really does a few thinks very well. Logging in means typing in your user-name and then selecting the pictures of your selected categories from a grid and entering the characters associated with those categories. An example of such a grid is here: 

So if your categories are dogs, computers and buildings, you’d enter NJA (in any order you like). Remembering categories is much easier then remembering a password. Even though this password is very short, since it’s different every time, it’s very hard to guess. I think it’s very cool. The technology is called Confident Imageshield(tm). One added bonus of MyVidoop is the way it let’s you know what’s happening with your account via e-mail notifications. If someones trying to abuse it, you’ll know about it!

InkBlotPassword has a different strategy. The idea here is that people remember best by association. Association of words with pictures in this case. They show you a number of inkblot-type pictures during sign-up and ask you to enter the first and last character of the word you associate with that picture. You could choose another mechanism (like the first and third character), just as long as you remember what it is. You can practice this mechanism before fixing it as your password. When logging in after typing your user-name you are shown your inkblot-patterns in random order. You enter the characters (first and last or any other way you chose) for each inkblot. It’s indeed not that hard to remember or to ‘re-associate’ the blots with words. Best of all, you can select how many inkblots you want to use therefor you can set the strength of the password you are using. Pretty nifty. Also here, the password is different each time since the order of the blots changes,

Do you know of other means adding security while helping you authenticate (even though it’s single factor)? Let me know in the comment-section.

Photo by GilmothScrum is a method used in software development that is aimed at creating software that fits the business needs better in managable projects with predictable outcomes. It can really help development projects along. There is however a big risk involved in the way selections are made what to implement, and what not.

Wikipedia tells us:

During each “sprint”, typically a two to four week period (with the length being decided by the team), the team creates a potentially shippable product increment (for example, working and tested software). The set of features that go into a sprint come from the product “backlog,” which is a prioritized set of high level requirements of work to be done. Which backlog items go into the sprint is determined during the sprint planning meeting. During this meeting, the Product Owner informs the team of the items in the product backlog that he or she wants completed. The team then determines how much of this they can commit to complete during the next sprint.[4] During a sprint, no one is allowed to change the sprint backlog, which means that the requirements are frozen for that sprint. Development is timeboxed such that the sprint must end on time; if requirements are not completed for any reason they are left out and returned to the product backlog. After a sprint is completed, the team demonstrates how to use the software.

The problem here is not the fact that the Product Owner decides functionality, but that the Product Owner may not have the right information to decide on the priority of non-functional requirements that originate in the technical teams within the organisation. Security, scalability, but also conformance to architectural principles, standards and directions are sometimes sacrificed against functional traits of an application. This is risky business that can stimulate unhealthy code and poorly performing software.

The method itself does not have means in place to insert priority boosters for non-business functions which is the main cause of the problem. The Product Owner therefor shouldn’t be a single person from the business side of the organisation, but a team of stakeholders. That way a balanced feature selection proces can take place and most of the risks are averted.

What’s your take on this?

There’s a lot of talk lately about ownership of content, but there isn’t a lot of substance. In this post I want to tell you what providers of Social Media Services should do to make things very, very clear for YOU regarding YOUR content.

It’s called Dataportability, and this is what it means.

Data portability is the ability for people to reuse their data across interoperable applications. The DataPortability Project works to advance this vision by identifying, contextualizing and promoting efforts in the space.

The fun thing about definitions is the fact there usually are many. The one I gave you is the one supported by the Dataportability Project in which I participate.

The key concept here is ‘who owns the data, and what can YOU do with it’. Companies should be perfectly clear in their communication about this so You know what to expect. That’s why we believe that they should have a portabilitypolicy, just as they have a privacy policy. (the privacy policy states what They can and will do with Your data). As an idea, it’s actually quite logical, don’t you think?

And this doesn’t necessarily mean that you should be given any control over your data whatsoever, it just means that you should know what control you have. Then you can make educated choices which companies to be a client of. This, as many other things, is just a matter of selection.

To aid companies in creating these policies there is now a website with example policies for inspiration. There will be services to aid companies further in there efforts to create these policies in the future. This hopefully removes some of the barriers of getting this not only accepted as a good idea, but also implemented as a standard procedure. I guess you head overthere and give us some feedback, either on the dataportability google groups or (my personal preference  ) here in the comments.

If you’re interested in following this fantastic project, be sure to read the Dataportability Blog.