nice discussion about MDM – Master Data Management – and that the efforts for MDM governance and MDM processes are much higher than the technical implementation and the distribution to data consumer.
Techies just like to talk rather about technology than governance 😉
However, as an enterprise architect it is just more than this …
I guess I am not the only one struggeling with the definition and differentiation for products, platforms, applications, components and all those other words used to desribe what systems or IT things and entities are.
In my case a product has been defined as something, which can be sold to a customer and has a SLA (Service Level Agreement), Product Description, Cost Model, etc.
A platform, an application and an infrastructure [product] are sub categories of product, i.e. a platform x is part of the group product. It’s like generalization and specialization in the UML world.
A component’s defined as one piece of a product, independent if it is a platform, infrastructure or applications product. Either one component or multiple componants make a product, then.
The term “system” is not yet reflected so far and I know that there a some definitions for system. However, we did not consider it in our world so far.
Now, as this is still completely related to IT, how would you encapsulate it for customers, who do not care what ever IT thing is behind the product?
And where would you place the term service?
As our department is responsible for the IT Strategy and the Roadmaps for some weeks now, I just want to share some views and concerns and of course also some lessons learned.
In each and every transition phase of whatever topic to another person or department, it comes to the question: What do you actually want to transfer?
Therefore, of course you need a good understanding on what is on the plate.
Now, IT Strategy and Roadmaps seems to be an easy task. However, it isn’t as in our case the intention was to transfer the IT Strategy and Roadmaps, but not the Strategy of the IT Department.
So people had to understand that first, there is a difference between the IT Strategy of the IT environment (whatever that means) and the IT Strategy of the department actually managing the IT environment.
Some, maybe many, people were confused and always struggeled to differenciate between both.
Then, we had to communicate again and again to not loosing the people’s committment.
But why shall we care of the committment of the people?
Don’t we create the IT Strategy and tell the people what to do?
Well, this is my next lessons learned that everything we do in an IT Department IS the IT Strategy.
To me IT Strategy consists of multiple key elements.
1. Objectives describing the desired target state.
2. Strategic directrions in order to achive the objectives
3. Strategic roadmaps reflecting the strategic directions in order to break the long term view into long, mid and short term views
4. Several deliverables reflecting the strategic directions and strategic roadmaps such as
As many people support the creation, change, adoption, manage, share and publish of all deliverables, they logically ARE the IT Strategy.
So it is not only a group of people within the IT department, but all people in the IT department.
aViewOnIt 