API Management in Azure using Microsoft's solution - API-first design

This is a series of posts regarding the topic of API's and API Management on Microsoft Azure. Not all posts in this series are directly related to Microsoft Azure and their implementation of API Management, that is intentional. The series also explains about API's, about creating API's and about what it construes to in order to manage them, conceptually and in reality. The reason for this series is that over the past 12 months I've come across many articles on the web, have been in many discussions and advised various clients of mine on this topic. Sometimes discussing with fellow architects, other times with vendors, still other discussions where with developers and managers. But the overall situation has always been that none of the people at the other side of the table had a full grasp of what developing API's in an organisation means, what it entails to manage them or what should be worried about when deciding to go API. I hope you enjoy reading these articles, and when you feel like it, comment on the articles. I always take serious comments serious and will reply to my best effort.

Summary

API's are about the hardest thing to create in software engineering. Designing software to act as an API before anything else is even harder.

There's a new buzz going around in IT; API Management, and everything associated with it. I think it's even more buzzy than Microservices. Especially with shout-outs like "API First", compared to "Cloud First", "Mobile First" and "Web First" of yesteryear, we need to be cautious about what this means. This post is not about what API's are, why you should develop API's, or why API development is probably the hardest area in software development in this day and age. This post is about how you should look at Microsoft's offering on API Management and how to use it. Not the definitive guide, but a guideline instead.

This post is focusing on the API-first buzzzzzz...

Microsoft Azure

Skip to the next section when you're not interested in a view of mine on Azure, otherwise keep reading.

Whatever you think about Amazon AWS and the incredible pace by which Dr. Werner Vogel and his team is telling the world what The Cloud is and will be, you have to agree that the more amazing player in the Cloud arena at this point in time is arguably Microsoft.
Amazon has a track record of providing an amazing experience to their customers, both at Amazon.com but also on AWS. Clearly considering what the customer wants and doing everything to make the customer want to spend more money with them then anywhere else. They're doing this for over a decade now. I would argue that AWS is for those that understand the Cloud. Microsoft is arguably only since about 5 or 6 years a Cloud player to consider. Although announced in 2008, their implementation of the Cloud was in early 2010 and called Microsoft Azure in 2014. It really matured in 2016 with proper RBAC (Role Based Access Control) and proper infrastructure-in-code capabilities through the Azure Resource Manager. Other than AWS, which is a true 'API first' and 'Automate everything' platform, Azure is only since recently truly catching up in allowing everything to be done through API's and automation. Which is too bad since one of the Cloud's most awesome traits is the virtually infinite amount of resources allowing to provision and deploy a virtually infinite amount of versions of an application. Anyway, Microsoft's lack of API's and automation capabilities in the Cloud is consistent with its desktop platform Windows, which is a point-and-click affair instead of a scripting affair. Even administrators on Windows will use the point-and-click interface instead of the CLI (Command Line Interface) which is so accustomed to their Unix and Linux colleagues. It makes the platform less intimidating and many of the hard work is hidden behind a button and some checkboxes. This is how the Cloud is managed as well, through a Portal. It's a "point-and-click first" philosophy it seems. And many of the customers of Azure are happy with this. Who wants to be intimidated by a computer after seeing 2001 and Terminator anyway?

Setting AWS and Azure side-by-side one might see the following key difference: AWS allows you to do IT like playing with Lego. Amazon started with the basic building blocks. The Lego of 30 years ago and they allow you to build pretty much everything, if you're willing to spend the time. As time passes they come out with more advanced blocks, like the roofs in Lego. And just like Lego came with the little Lego men, gears, axles and so on, Amazon introduced more and more advanced services on AWS. But the idea, it seems, has always been to allow the customer to build pretty much everything she wants. Microsoft on the other hand seems to have followed the PlayMobil path. The fun is in the playing part and not so much in the building part. So open the Azure box and unlike AWS, you can start playing from day one. And as time passes by, there are more and more lower level components available, so you can start playing new games by building new toys.
Neither approach is better than the other, but you should carefully look at where you are, what you can do and what you want in order to be able to select either AWS or Azure. And IMHO, if you're just selected to go with Azure, don't even think about also doing AWS. And the other way around, because you would be most likely dealt lemons and you won't be able to make lemonade out of them.

API Management

First of all, API Management is a concept. I'm taking it you understand what an API is and I won't go into it any further than necessary for understanding this post.
API Management is done by people and some of them are using tools and technologies we call API Managers. Just like an enterprise, it has Management, and Management is made up of Managers.

Second of all, API-first design is not a fluke and it's not a hype either. Instead it is calling doom and gloom over your IT organization, or quite the opposite when you really know what you're doing.

Third of all, there's nothing MicroServices about API's although you see both walking around hand-in-hand more often than not.

Let's start with number 2...

API-first design
With API-first design, what you do is, you think about the functionality or information you want to expose and design it such that you don't have a clue about who will need or want to use that functionality or information. What you need to do next is worry about this. Start worrying a lot, because if you don't have a clue about who will access your functionality or information, let's call it a service, you don't know their intent either. And you don't know how often they'll access your service. You don't know whether or not you can trust them either. Are they taking security as serious as you do? Are they complying with all regulations you need to comply with? etc. Worries, worries, worries.

By not making any assumptions about the consumer of your service, you will need to make sure that it can stand the assault of all kinds of consumers. I do see your mind fluttering into the direction of non-functionals. Things like resilience and availability maybe? And encryption and access management possibly as well. Drop the mother in the cloud and you've got your scalability straight out of the Cloud's elasticity. (Of course you're very intimate with my post on this topic). And when you're in the Cloud, you know pretty much for sure that your Cloud provider will have all kinds of network protection in place without you even knowing it. Making sure that you, nor any other customer of theirs, will suffer from a DDOS attack and the likes.
But when we talk about API-first, we also need to think about the granularity of the service's exposed functionality or information. We need to think about it very, very carefully. In general we can say that less is more when it comes to this. But in fact, you want to hit that sweet-spot, because only then you're API is build to last.

That sweet-spot is something really important and almost impossible to find, let alone to hit. It's like the mythical G-spot. We know it should be there, but once you find it, you don't have the guarantee you will be able to find it all the times you're looking for it.
Granularity of your service defines it's usability and it is extremely business-bound. So first of all, you will need to know exactly the business context of your API and, and this is important, understand the business context of your consumers. And you should, no you must, accept that you'll have this latter one wrong. The most unlikely consumer will be your most valuable customer, so unless you're capable of reacting to her needs very quickly. Able to adapt to a massive change in positioning of your API in the grand scheme of the universe due to a pivot of your business, don't even try to go for API-first design.

By getting down to business, understand that an API is to be considered a product. It's not just access to your productised software solution, no it is your product. Nobody will care and shouldn't care how you do the magic behind the API as long as you're doing it. So you need to treat your API as a product. And that means that your API should have business value and as such, you should be very much aware that your API is valuable to your customers. In short, think about your revenue generated by your API. This is where your business context is showing it's ugly face again, because initially you can only assume how your API can be valuable to your customers. Hence you can only guess, albeit an educated guess, how you can get revenue from your API. Here again you'll need to be able to adapt to changing views and accept that hindsight is 20-20.
What this means is that you'll have to build (business) metrics into your API. Think upfront how you can verify your hypothesis and then do the validation of it as well. And don't be shy to change your product. A good product is one that is used, a great product is one that is valuable.
A key aspect of your API's granularity is about how elementary it is. You don't want to have an API that is only providing basic information, one that is only spewing data. Instead you want an API that is providing information in context. How much context is part of finding that sweet-spot. For example an Address by itself might mean nothing unless you know whose address it is, so a service that spews out addresses is of limited value, but one that provides access to a person and her address might be invaluable. Or maybe access to information is not that much of a thing to consider and instead you provide access to a function, for example to put some random text on API Management on the internet.

A good product is one that is used, a great product is one that is valuable.

The point here is that there's no way to determine what makes sense as an API and what not, unless you understand the context of your API at your end. And this only because it provides you with a starting point to make educated guess about the context of your API's consumer.
And at all times, the quality of your product needs to be such that you won't need to enter dialogue with the customer about the product, explaining why it's not working.

By the way, your architecture, blue-prints or design-patterns are no indication of what should be an API in the sense of API-first. In fact, I would argue that they are not an indication of what should be API's and managed as such and what not.

Considering you're developing according to service oriented concepts, and quite possibly adopting the principles of Forrester's 4-tier architecture. Which is in fact not a bad thing at all and probably a very beneficial view on things in general. So considering this, you might be inclined to consider very service in a specific architectural layer to be an API. For example the Aggregation Tier in Forrester's model or the Systems Tier in that model, could be considered to be an API. Which is total rubbish!
In software engineering we don't just do, we think about it and decide. So calling something a service in a specific part of our architecture an API is nonsense, should be cause of being fired in fact. And in fact, after thinking about it and deciding you have a service that is bound to be reused doesn't mean that will be an API either. So you'll have to do some more thinking... think... think... think. And then worry about calling something an API when you know in what situation the service is going to be used. Worry about calling something an API when you know who's going to call you to yell at you because the service is not abiding the service contract. Because if you know this, you know who your service's consumer is, and most likely there's no need to do any API'afyication on your service. Doesn't mean that you shouldn't treat it as an API, it means you don't have to treat it as an API if that doesn't warrant the effort.

In software engineering we don't just do, we think about it and decide.

API's have all kinds of stuff in them one way or the other, that allows them to be unleashed into the world. It's all the stuff that ensures that they survive the onslaught of calls by initially unknown subjects, the unsubs.
It's the part of API-first design that ensures that none of the wonderful promises of pots with gold by exposing the service's splendour, is compromised. It's the resilience, availability, scalability, security as well as metrics and other business requirements we too often consider IT stuff.
Think about the idea of implementing it over and over again for every service interface. If that means you're starting to sigh, and very deep at that, than only do it for the real API's. The service interfaces for which you don't know who'll call them. But when you get a smile on your face, eyes start to gleam, then you might as well take it from the other end; think about why you shouldn't treat the service as an API. Could be because of money (using standard tooling to API'afying service interfaces cost money) or maybe the operational overhead is not worth it.

So, in order to do API-first design, you need to understand your own business, meaning you need to understand what you want to expose and how you can create business value with your information or capabilities. This is hard enough for most software engineers, so they'll need the support of a business expert. Than you need to think about why others, and you don't know who that might be, would like to use your API, your product, and why it's valuable for them. This requires business knowledge and some understanding of how to see business value in using information flows. This is not the average business person you need to work with.
Than you need a thorough understanding of how to develop a resilient, performant and secure piece of software that can run in the Cloud, i.e. and elastic environment that is to be considered to be crashing all the time. And if you have all this in place, you need to be able to be roll-out new versions of your product on a very regular basis, with an extremely high level of quality. And on top of that, never get frustrated because your business pivots over and over again, because they're not really sure for whom the product is intended.

API's are about the hardest thing to create in software engineering. Designing software to act as an API before anything else is even harder.

The complete series:

• API-first design
• API's and Architecture, match made in heaven 
• Why API's should be managed and by whom
• Resources and Templates [1/2] 
• Resources and Templates [2/2]

Thanks once again for reading my blog. Please don't be reluctant to Tweet about it, put a link on Facebook or recommend this blog to your network on LinkedIn. Heck, send the link to my blog to all your Whatsapp friends and everybody in your contactlist.
But if you really want to show your appreciation, drop a comment with your opinion on the topic, your experiences or anything else that is relevant.

Iwan

The Demise of the Project Leader in the DevOps world (Google Translated version)

Disclaimer: This is a translation by Google of the post "De Teloorgang van de Projectleider in de DevOps wereld", which is in Dutch. So bear with me when stumbling over tricky grammar and in case you can read and understand Dutch, head over to the original post by clicking here.

They are still, last week, I have seen one. A real project[manager]. The kind that, when you [ask] him or her, can show a certificate that clearly states that Prince2 course is successfully completed.

The project[manager] is a dying profession. At least, in Software Development. Fortunately, because they have absolutely no business. At least, in Software Development.

The question is why there still are so many project managers in the IT sector. A simple answer is no, but probably it's because we have so many project managers in other sectors. In the construction example, we have developers who realize projects which are then led by project leaders. And just when we compare make the fundamental error in the IT architecture by the IT architect with a 'buildings' architect [1], we do so with project leaders.

We think we need project managers in IT and that is mainly due to that damned waterfall method we used to see in our IT projects since time immemorial. Kolder course, waterfall method, there has never completed a project within the planned budget and completed in the scheduled time period something useful. Can not, because there is no single user that actually knows what he or she wants. Let alone that the user knows what he or she needs.

No wonder that we have our sights now focus on agile methods, the sweetest as they do in Spotify. In brief:

You define an idea, you develop software, you let the user whether it was a good idea and you go on to the next idea.

And so here it happens. This is what comes to light that the project does not belong in IT. Because if you think this cycle is a project, you'll miss it a lot. Also by the way if you think that some of these cycles form a project.

The fundamental problem of the project is that a project is finite. You start on a project and at one time the project is finished. We're ready when the project is finished. And that of course is nonsense for IT projects for IT projects are never finished. Haha, you think now, which is the well-known IT joke that projects always on time and on budget go. But it's not a joke, because when an IT project is completed, it all begins actually.

When the project is in fact finished, the software is used and only then we can work to make it usable it. we look at the project, his or her job done when the project is completed. The project will therefore only give the software to a user. Within time, within budget. Irrespective of the fact whether the software turns out to be usable.

The project thus focuses on what the user wants and not what the user needs. And that is the fundamental reason why IT projects are absurd, and why project managers are disastrous.

We happily watching for a while, so we have a few years ago started with agile. Apart from the agile manifesto [2] and the hype around Scrum, we're in IT for over 20 years, very active in the iterative development with the shortest development cycle. And therefore we are since then, until about 5 years ago, been busy with projects delivering software iteratively. Instead of long journeys waterfall project managers have divided their projects into small waterfalls. We see that iterative projects anticipate less in terms of time and money. But still the user gets what he wants and not what he needs. Or they naturally.

It should be clear; As long as software is developed by project-led projects, then that results in desired unusable software.

And then there was agile and Scrum, and since then the user gets what they need, not necessarily what he wants. By not from the outset to define what functionality the software should provide, but gradually adjust the scope and adapt existing functionality to something useful, we need agile projects that provide something useful.

The really good project managers know to think to this new way of working. It is the type of project that is not immediately shoot the stress is not clear what should lead his team. The scope of the project, but also the duration is thus determined by the budget. The project is over when the money runs out. The Project Manager will, if he or she has heart of the matter, therefore deliver the greatest possible functionality for that budget.

And therefore the project is no longer necessary. Because it makes no sense to scopes projects based on how much money is available. That should be clear.

Then there is another small, tiny, point of focus to work with new agile. Early on, namely as soon as possible, there, in a real agile project, something in production and is used by real users. That may have to be adjusted because it is not usable. And suddenly, the project manager is also responsible for solving production problems.

All, or at least too much, organizations have a galvanic separation between the project and operational management. Change-run organizations with clear, often indefinitely elaborate, hand-over procedures. Different responsibilities and often different budgets. [3] These organizations are full of silos that do the best work by itself, but together are far from optimal.

The Change-Run model does not work in practice. This is often denied. Especially by people who think the waterfall method works. And many of those people are project leaders who deny their demise and otherwise not recognize yet.

They be lost because organizations have projects in IT are extremely absurd. Of course there is a whole group of organizations that is just hip and do not understand why they are. A growing group understands the ups and focuses what is desirable and what is no longer needed.

IT departments transform themselves more and more from project organizations to product organizations. Organizations abandon Change Run divorce and move to DevOps [4]. Specialist teams are dissolved and multifunctional teams are appointed. No software projects to be done, but products developed software. Because there are no projects to be done there are no project managers needed. In any form. However, there are product requires owners. Unfortunately for all those without work-come-to-sitting project, a product owner is no such thing as a project manager. namely the product owner is the owner of a product that understands the product, and above all understand what is and is not usable. He or she is responsible for the product, cradle to grave, from the cradle to the grave so.

He, or she, has the mandate to the functionality offered by any means. Is also another budget responsible for the product. The product owner is not judged by the amount of features that will be hoisted into production in the time available and the available budget, but the value of his or her product for the organization. And that value can only be measured when the product is actually used.

But there is hope for the project. Indeed, there are quite a few product owners who do not understand it yet. They develop their products in a project that has quite a few puffs of a waterfall process. Or at least iteratively. And as long as product owners do not yet fully understand what an MVP [5], the project still work. The current crop of product owners are not sufficiently experienced in the delivery of a thing. The project leader, and certainly one with iterative processes is known, is therefore a big setback for. But for how long?

The tide turns namely, product owners understand more and more what is their role and how they can fill it the best. Organizations are finding that it is not wise to their project to schools to product owners. Apart from the odious Prince2, it also be that the project has sufficient knowledge and often no affinity with the product. That 'one thing' that an organization makes money with it. Product Owners then get out of the business and not like the project leaders from the IT. The project is unnecessary.

Thus the demise of the project is therefore inevitable. Not a matter of if but of when.

As always, thanks for reading this post and I hope that the post has put your thinking. I realize that I quite bluntly go and drop it all pretty black / white. And as with anything on the internet you should this article with a dose of common sense reading. Should you make the nuance. I want to invite you to do that last through the comments of this post. Likely that others also find it interesting to know how you think, and of course there is no doubt that I find it interesting.

PS: There are projects in IT that drop something then never come to more, or evolve. These are the projects that you might be comparing projects from the building. IT infrastructure projects that will be delivered something physical. In the best case will be completed in phases, so that it can be enjoyed quickly yields, but when completed can not really speak of further development. In these cases, a project still certainly useful. But in a world in which more and more infrastructure code is expressed is it rather than product development.


[1] But this article is not about, you want to know what's wrong with that, you can read my blog post about the architect. Which can be found here: https://itarchitectureandstrategy.blogspot.nl/2015/02/how-youll-fail-as-it-architect-when-you.html.
[2] Look at http://agilemanifesto.org/ the manifesto. Read it carefully before you draw your conclusions.
[3] Change-run organizations are the result of not understanding Taylorism. https://en.wikipedia.org/wiki/Scientific_management, like the agile manifesto.
[4] In a DevOps organization working Developers (Dev) and managers (Ops) closely. See also: https://en.wikipedia.org/wiki/DevOps
[5] A MVP Minimum Viable Product, is a version of a product with the minimum set of functionality to still create value for the user. See also: https://en.wikipedia.org/wiki/Minimum_viable_product

De Teloorgang van de Projectleider in de DevOps wereld

Disclaimer: This post is in Dutch, I will translate it into English at some point, but by clicking here you can read a translation by Google.

Update: Lees ook het artikel "Agile Projecten: De veranderende rol van de Project Manager" voor een bredere uiteenzetting.

Ze zijn er nog, vorige week heb ik er nog eentje gezien. Een echte projectleider. Zo eentje die, wanneer je het hem, of haar, vraagt, een certificaat kan laten zien waarop duidelijk vermeld staat dat een Prince2 cursus met goed gevolg is afgerond.

De projectleider is een uitstervend beroep. Althans, in de Software ontwikkeling. Gelukkig maar, want ze hebben er helemaal niets te zoeken. Althans, in de Software ontwikkeling.

De vraag is echter waarom er toch zoveel projectleiders in de IT-sector te vinden zijn. Een simpel antwoord is er niet, maar waarschijnlijk komt het omdat we in zoveel andere sectoren ook projectleiders hebben. In de bouw bijvoorbeeld, daar hebben we projectontwikkelaars en die realiseren bouwprojecten en die worden dan weer geleid door projectleiders. En net als dat we de kapitale fout maken in de IT-architectuur door de IT-architect te vergelijken met een ‘gebouwen’ architect[1], doen we dat ook met projectleiders.

We denken dat we projectleiders nodig hebben in de IT en dat komt vooral door die vermaledijde waterval methode die we sinds mensenheugenis in onze IT-projecten toegepast zien. Kolder natuurlijk, die waterval methode, er is nog nooit een project opgeleverd dat binnen het geplande budget en in de geplande tijdspanne iets bruikbaars heeft opgeleverd. Kan ook niet, want er is geen enkele gebruiker die ook daadwerkelijk weet wat hij, of zij, wil. Laat staan dat de gebruiker weet wat hij, of zij, nodig heeft.

Geen wonder dus dat we al onze pijlen tegenwoordig op agile methoden richten, het liefste zoals ze dat bij Spotify doen. In het kort:

Je hebt een idee, je ontwikkelt de software, je laat de gebruiker bepalen of het een goed idee was en je gaat verder met het volgende idee.

En hier gebeurt het dus. Dit is waar aan het licht komt dat de projectleider niet in de IT thuishoort. Want als je denkt dat deze cyclus een project is, dan heb je het flink mis. Ook trouwens als je denkt dat een aantal van die cycli samen een project vormen.

Het fundamentele probleem van een project is dat een project eindig is. Je begint aan een project en op een gegeven moment is het project klaar. We zijn klaar als het project af is. En dat is natuurlijk kolder voor IT-projecten want IT-projecten zijn nooit af. Haha, denk je nu, dat is de bekende IT-grap, dat projecten altijd over tijd en over budget gaan. Maar het is geen grap, want wanneer een IT-project klaar is, dan begint het allemaal pas eigenlijk.

Wanneer het project namelijk klaar is, wordt de software gebruikt en pas dan kunnen we eraan werken het bruikbaar te maken. Kijken we nu naar de projectleider, dan is zijn, of haar, werk gedaan als het project is opgeleverd. De projectleider wil dus alleen maar de software aan een gebruiker geven. Binnen de tijd, binnen het budget. Los van het feit of de software wel bruikbaar is.

De projectleider richt zich dus op wat de gebruiker wil hebben en niet wat de gebruiker nodig heeft. En dat is de fundamentele reden waarom IT-projecten onzinnig zijn, en waarom projectleiders desastreus zijn.

Dat hebben we gelukkig al een tijdje in de gaten en daarom zijn we met agile begonnen een paar jaar geleden. Los van het agile manifesto[2] en de hype rondom Scrum, zijn we in de IT al meer dan 20 jaar heel actief in het iteratief ontwikkelen met een zo kort mogelijke development cyclus. En daarom zijn we sinds die tijd, tot ongeveer een jaar of 5 geleden, druk geweest met projecten die software iteratief opleveren. In plaats van lange waterval trajecten hebben de projectleiders hun projecten in kleine watervalletjes verdeeld. We zien dat iteratieve projecten minder uitlopen voor wat betreft tijd en geld. Maar nog steeds krijgt de gebruiker wat hij wil en niet wat hij nodig heeft. Of zij natuurlijk.

Het moge duidelijk zijn; Zolang software ontwikkeld wordt in door projectleiders geleide projecten, dan resulteert dat in gewenste, onbruikbare software.

En toen was er agile en Scrum en sindsdien krijgt de gebruiker wat hij nodig heeft en niet per se wat hij wil hebben. Door niet van meet af aan vast te leggen welke functionaliteit de software moet opleveren, maar gaandeweg de scope bij te stellen en bestaande functionaliteit aan te passen tot iets bruikbaars, hebben we agile projecten die iets bruikbaars opleveren.

De echt goede projectleiders weten om te denken naar deze nieuwe manier van werken. Het is het type projectleider dat niet meteen in de stress schiet als niet duidelijk is wat zijn team moet opleveren. De scope van het project, maar ook de duur, wordt daarmee bepaald door het budget. Het project is afgelopen als het geld op is. De projectleider wil, als hij, of zij, hart voor de zaak heeft, dus zoveel mogelijk functionaliteit voor dat budget opleveren.

En daarom is de projectleider niet meer nodig. Want het snijdt geen hout om projecten te scopen op basis van hoeveel geld er beschikbaar is. Dat moge duidelijk zijn.

Dan is er nog een ander klein, piepklein, puntje van aandacht met dat nieuwe agile werken. Al vroeg, namelijk zo snel mogelijk, staat er, in een echt agile project, iets in productie en wordt het gebruikt door echte gebruikers. Dat moet misschien worden aangepast omdat het niet bruikbaar is. En plotseling is de projectleider ook verantwoordelijk voor het oplossen van productieproblemen.

Alle, of in ieder geval nog teveel, organisaties hebben nog een galvanische scheiding tussen de projectorganisatie en het operationele beheer. Change-Run organisaties met duidelijke, vaak tot in den treure uitgewerkte, hand-over procedures. Verschillende verantwoordelijkheden en vaak ook verschillende budgetten.[3] Deze organisaties staan bol van de silo’s die wel op zichzelf optimaal werken, maar gezamenlijk verre van optimaal zijn.

Het Change-Run model blijkt in de praktijk niet te werken. Dat wordt vaak ontkent. Vooral door mensen die denken dat de waterval methode werkt. En veel van die mensen zijn projectleiders die hun teloorgang ontkennen en anders nog niet onderkennen.

Ze gaan teloor omdat organisaties door hebben dat projecten in de IT uitermate onzinnig zijn. Er is natuurlijk een hele groep organisaties die gewoon hip is en niet snapt waarom ze het zijn. Een steeds grotere groep snapt het wel en richt zich wat wenselijk is en niet meer op wat gewenst wordt.

IT-afdelingen transformeren zich meer en meer van projectorganisaties naar productorganisaties. Organisaties stappen af van Change-Run scheidingen en stappen over op DevOps[4]. Gespecialiseerde teams worden ontbonden en multifunctionele teams worden ingericht. Er worden geen softwareprojecten gedaan, maar producten ontwikkeld in software. Omdat er geen projecten meer worden gedaan zijn er geen projectleiders meer nodig. In geen enkele vorm. Wel zijn er product eigenaren nodig. Helaas voor al die zonder-werk-komen-te-zittende projectleiders, is een producteigenaar niet zoiets als een projectleider. De producteigenaar is namelijk de eigenaar van een product, die snapt het product, en begrijpt vooral wat wel en wat niet bruikbaar is. Hij, of zij, is verantwoordelijk voor het product, cradle-to-grave, van wieg tot in het graf dus.

Hij, of zij, heeft het mandaat om te welke functionaliteit op welke wijze geboden wordt. Is ook nog eens budgetverantwoordelijk voor het product. De producteigenaar is wordt niet beoordeeld op de hoeveelheid functies die in de beschikbare tijd en met het beschikbare budget in productie gehesen wordt, maar wat de waarde van zijn, of haar, product voor de organisatie is. En die waarde kan alleen gemeten worden wanneer het product daadwerkelijk gebruikt wordt.

Maar er is hoop voor de projectleider. Er zijn namelijk aardig wat product eigenaren die het ook nog niet snappen. Ze ontwikkelen hun product in een project, dat nog behoorlijk wat trekjes heeft van een waterval traject. Of in ieder geval iteratief. En zo lang product eigenaren nog niet helemaal snappen wat een MVP[5] is heeft de projectleider nog werk. De huidige lichting producteigenaren zijn nog onvoldoende ervaren in het opleveren van een iets. De projectleider, en zeker een die bekend is met iteratieve trajecten, heeft hier dus een flinke streep voor. Maar voor hoelang?

Het tij keert namelijk, product eigenaren begrijpen meer en meer wat hun rol is en hoe zij deze het beste in kunnen vullen. Organisaties komen erachter dat het niet verstandig is om hun projectleiders om te scholen tot product eigenaren. Los van het verfoeilijke Prince2, is het ook nog eens zo dat de projectleider onvoldoende kennis en vaak geen affiniteit heeft met het product. Dat ‘ene iets’ waar een organisatie geld mee verdient. Producteigenaren komen dus uit de business en niet zoals de projectleiders, uit de IT. De projectleider is dus overbodig.

Daarmee is de teloorgang van de projectleider dus onvermijdelijk. Niet een kwestie van of maar van wanneer.

Zoals altijd, bedankt voor het lezen van deze post en ik hoop dat de post je aan het denken heeft gezet. Ik realiseer me dat ik nogal kort door de bocht ga en het allemaal redelijk zwart/wit neerzet. En zoals met alles op het internet moet je ook dit artikel met een dosis gezond verstand lezen. Moet je zelf de nuancering aanbrengen. Ik wil je uitnodigen om dat laatste te doen via de comments van deze post. Waarschijnlijk dat anderen het ook interessant vinden te weten hoe jij erover denkt, en uiteraard staat het buiten kijf, dat ik het interessant vind.

PS: Er zijn projecten in de IT die iets neerzetten om er vervolgens nooit meer aan te komen, of door te evolueren. Dit zijn de projecten die je wel zou kunnen vergelijken met projecten uit de bouw. IT-infrastructuur projecten waarbij iets fysieks wordt opgeleverd. In het gunstige geval wordt er gefaseerd opgeleverd, zodat er snel genoten kan worden van de opbrengsten, maar wanneer opgeleverd kan er niet echt worden gesproken van doorontwikkeling. In deze gevallen is een projectleider nog zeker wel nuttig. Maar in een wereld waarin ook infrastructuur meer en meer in code wordt uitgedrukt is ook hier eerder sprake van productontwikkeling dan van projectontwikkeling.

---

[1] Maar daar gaat dit artikel niet over, wil je weten wat daar mis mee is, dan kan je mijn blog post over die architect lezen. Die vind je hier: https://itarchitectureandstrategy.blogspot.nl/2015/02/how-youll-fail-as-it-architect-when-you.html.

[2] Kijk op http://agilemanifesto.org/ voor het manifesto. Lees het aandachtig voor je je conclusies gaat trekken.

[3] Change-Run organisaties zijn het gevolg van het niet begrijpen van Taylorism. https://en.wikipedia.org/wiki/Scientific_management, net als het agile manifesto.

[4] In een DevOps organisatie werken ontwikkelaars (Dev) en beheerders (Ops) nauw samen. Zie ook: https://en.wikipedia.org/wiki/DevOps

[5] Een MVP, Minimum Viable Product, is een versie van een product met de minimale set aan functionaliteit om toch nog waarde te scheppen voor de gebruiker. Zie ook: https://en.wikipedia.org/wiki/Minimum_viable_product