In this post I want to share my experiences in the support of the governance process that is responsible for keeping the level of customization for a standard package solution under control. How do we approach this? It's easy to boldly say upfront that you rather adapt your way of working than to customize the software you bought. This post is all about sticking to that decision even when the going gets tough.
Previously I've pleaded for simple architectural designs that are easily understood by all stakeholders. This way the idea gets the support it needs. As a project evolves into the ICT design and development phase, both idea and design will need to be made more tangible. This is especially true when it comes to making it all work together. The purpose stays the same: to avoid ambiguity. The means? Keep it again as simple as possible by focusing on what really matters.
I'm an architect. As most architects, I like to design things and conceptualize ideas. But a common pitfall for us architects is that we design things that are very clear for... other architects. Other audiences are often left puzzled or confused. This is commonly referred to as the ivory tower phenomenon. I'm also a result driven pragmatist; I love to realize ideas. To make something happen, you first need to convince the stakeholder or sponsor that provides the budget to realize your idea. In this post I'd like to share my experience in architectural models that have proven to work for me.
This post is the first in a series of six that will take you through the bpost iHRM (integrated human resource management) program. With this series we want to provide some context on the program itself and highlight our contributions and approach on business architecture and project scoping.