One thing most Enterprise Architects have in common: frustration with resistance to change. Channeling the words of some of my friends, frustration sounds like this: “We know many of the answers to common problems in IT, especially in how systems are developed and used, how data is organized and mastered, and how capabilities should produce shared components or systems. We know many of the answers… but no one listens!”
Yep. We do work and sometimes, no one uses it. Or we develop advice, and no one follows it. Common problem.
For some reason, the “answer” that I’ve heard bandied about is to buy software. “If we only had a repository for architecture, then people would use our models.”
um – no – not really.
If your models are not used, putting them into a collaborative storage and retrieval system will not get them used. It will make them more available, but in 85% of the cases, availability is not your problem. Either no one sees the value in using your models, or they don’t know how to read them, or using your models works against some political aspect of their lives.
It’s not that your stakeholders didn’t know the model was there. It’s that they don’t care.
Adding a repository won’t make them care.
Your first order of business is to build demand for the architecture models. Once demand is there, worry about the repository. Until then, a simple modeling tool will work.
Nick, While I agree with the problem, I’m not sure I agree with the solution. Or at least only partially.
The whole point a repository matters is that it builds an inventory of objects that can be related to one another and create information and knowledge. Simple Models do not achieve this except on the model itself. And if they are never kept for future use, we loose the information and re-use.
I think the way to resolve this is as usual somewhere in the middle. Use a simple tool that works both to just do simple models (and other things like Data Visualization, Matrices, Tree Maps, etc.) but that keeps this information such that it is in a position to be used later. See Point solutions here: http://www.inspired.org/eva-enterprise-architecture/?rq=point%20solutions