Flexibiliteit en standaardisatie, vrienden of vijanden? .. Flexibility and standardization: friends or foes?

….

Bij veel projecten is scrum het toverwoord. De achterliggende gedachte is flexibiliteit, aanpassen aan voortschrijdend inzicht en tegen minimale kosten een optimaal product leveren. Daarnaast is de roep om standaardisatie. In veel situaties gedreven door de behoefte om een project snel te realiseren tegen acceptabele kosten en zonder veel problemen.

De vraag is: kunnen standaardisatie en flexibiliteit samen gaan? Graag maak ik daarvoor gebruik van een vergelijking met de ontwikkeling van een auto.

Bij de ontwikkeling van de auto kun je uitgaan van maximale flexibiliteit waarbij alle onderdelen zelf worden geproduceerd. Dat kost niet alleen veel tijd en geld, maar vergroot ook de kans op problemen. Daarnaast de standaard auto waarbij geen modificaties mogelijk zijn. In de dagelijkse praktijk wordt er gekozen voor een ‘basis’-model waarbij modificaties mogelijk zijn door in onderdelen te variëren. Dit kan alleen maar goed gaan als onderdelen goed op elkaar zijn afgestemd en op elkaar aansluiten. Stel je voor dat je een ander motortype kiest maar alle aansluitingen zitten aan de verkeerde kant of de krukas draait de verkeerde kant op. Dan kom je in het ergste geval na veel aanpassingen tot de conclusie dat je alleen hard achteruit kunt rijden.

Deze vergelijking gaat ook op voor IT-oplossingen; alleen is het dan minder aansprekend. Ook bij IT oplossingen is flexibiliteit mogelijk met gebruik van standaard onderdelen. Ook dan is van groot belang om de componenten zo samen te stellen dat niet alleen de juiste functionaliteit wordt geleverd maar ook dat de onderdelen op elkaar aansluiten en kunnen samenwerken.

Terugkomend op de vraag ‘flexibiliteit en standaardisatie, vrienden of vijanden’.

Flexibiliteit en standaardisatie kunnen niet alleen samen gaan, maar elkaar ook versterken zodat er sneller een beter product kan worden geleverd. Mits er aan bepaalde condities wordt voldaan:

  • Zorg voor de juiste functionaliteit in de juiste samenstelling (functionele decompositie)

  • Zorg dat de onderdelen een ‘gemeenschappelijke taal’ hebben en op elkaar zijn afgestemd (referentie architectuur).

Een voorbeeld hiervan is ‘Programme Management for Non-Profit Cloud’ ontwikkeld door g-company. Het generieke doel is programma management voor non-profit organisaties. Maar binnen de veelheid van organisaties kunnen de doelgroep, focus en werkwijze anders zijn. Ook hier dus behoefte aan flexibiliteit. Maar er is ook de wens om een oplossing te realiseren zonder de hoge kosten van initiële software ontwikkeling en de bijbehorende problemen. ‘Programme Management for Non-Profit Cloud’ bestaat uit verschillende modules, toegespitst op functionele aandachtsgebieden die onderling optimaal samenwerken. Afhankelijk van de wensen van de organisatie kunnen desgewenst onderdelen (modulen) worden gebruikt.

Wil je meer weten over dit onderwerp? Neem dan eens contact op met info@g.company.

..

Scrum seems to be the magic word for a lot of projects. The underlying thought is one of flexibility, to adapt to advancing insights and to deliver an optimized product at minimal cost. Furthermore, there’s a demand for standardization. In many situations, this call is driven by a need to realize the project quickly, at an acceptable cost, without too many issues.

The question is: can standardization and flexibility go hand in hand? I would like to explain this by comparing it to the development of a car.

During the development of a car, you could assume maximum flexibility, which means all parts are produced by the factory itself. But that doesn’t only cost a lot of time and money, it also increases the chance of problems occuring. Another option is the standard car, which doesn’t allow for customization. However, daily practice is to opt for a ‘base’-model, whereby customization is possible through variation of the car parts. This only works when the parts are tailored to fit properly. Imagine, for instance, choosing a different engine, only to notice all connectors are on the wrong side, or that the crankshaft turns the wrong way. Worst case scenario is that, after many modifications, you end up with a car that can drive at a high speed, but only backwards.

This comparison holds true for IT solutions too, it’s just a little less appealing. IT solutions can be just as flexible, while using standard parts. And it is of equal importance to properly tailor these components, in order to deliver not just the right functionality, but also to allow for the components to fit and work together.

Going back to the question of ‘flexibility and standardization: friends or foes?’.

Flexibility and standardization can not only go hand in hand, but they can amplify each other, to deliver a better product quicker. It’s important, however, to adhere to the following conditions:

  • Have the right functionality in the right composition (functional decomposition)

  • Make sure the parts have a ‘common language’ and are tailored to fit together (reference architecture)

An example of this is ‘Programme Management for Non-Profit Cloud’, a solution developed by g-company. The general objective is to provide programme management for non-profit organizations. But there are many different non-profit organizations, with just as many different target demographics, focus points and ways of working. This means flexibility is needed here, too. However, this flexibility should be realized without the high costs of initial software-development, or the accompanying issues. ‘Programme Management for Non-Profit Cloud’ is made up of different modules, which focus on functional fields of attention, which can be combined to interact perfectly. Depending on the wishes of the organization, optional parts (modules) can be implemented as well.

Would you like to learn more about this subject? Be sure to contact info@g.company.

….

nl
en