Net als de afgelopen jaren heb ik afgelopen vrijdag een presentatie over Agile Architectuur gegeven. Kern van de presentatie dit jaar is dat bij het schalen van Agile vooral de problemen/uitdagingen die je onderweg tegenkomt aangepakt moeten worden en niet klakkeloos een framework gaat implementeren. Aan de hand van voorbeelden leg ik uit hoe we dit binnen bol.com aanpakken.
Recently while listening to OTN ArchBeat podcasts, a panel discussion on Reference Architectures (part 2 and part 3) I was thinking back to some pieces I wrote on industry data models and processes that I didn’t share with you yet. There a some similar argument to using these and reference architectures.
The value of reference models whether it contains data models, standardized messages, processes of a reference architecture, is or should be in a faster time to market and better quality of the solution.
Handle with care
What makes it hard to achieve this value, is the fact that these models contain always far more than is needed. That can be considered a waste. Even the parts that are not used still require attention while implementing and maintaining. This incurs work to understand the complex model, hide the details you don’t need, and customize and extend the parts you need.
Implementing a reference model requires spending time to determine how and to what extend this model meets the needs of your business? That is typically something you have to discover for yourself. It is where the majority of the time is spend! If you don’t go through the effort of understanding your business requirements, you are missing understanding of how the business can and should use the model. That makes it very hard to determine the value of the end solution to the business.
When using a reference models you should be aware that your business is not average. In some shape or form it delivers value to your customers in away a reference model doesn’t provide. Reference models should be used with care your business deserves.