There's a fundamental problem faced by almost every organization adopting a tool. They will be at a low level of modeling maturity. Using the standard 1-5 scale popularized by the Capability Maturity Modeling Institute, every survey that I've seen, process or architecture, has rated most organizations at level 1, or maybe 2. This means that it will take time to show results. But managers, having invested money in the initiative, need to see results. So how to show some quick wins?
Summary: Adopting modeling discipline involves a business transformation that is necessarily slow. However, there are few achievements that a team rolling out a tool can achieve and point to very quickly. Providing controlled access to up-to-date information, enabling reference models and providing immediate answers to burning questions all score with business stakeholders.
The first quick win that you can point to is simply: controlled access to information - a single source of up-to-date, monitored, controlled information. The immediate question that this usually meets with is: ‘how is that different to the existing SharePoint library?’ The difference lies in the words monitored and controlled. The reality is that the majority of SharePoint libraries end up as warehouses of legacy information that was once correct, but is no longer. And this is assuming that people even use it.
Maintaining an up-to-date model of the core architecture, function decomposition, or capability map ends up being different to simply creating a PowerPoint deck and stuffing it in a SharePoint library somewhere. First of all, the modeling tool enables the ability to search for specific information – somewhat different from a stack of PowerPoint slides or Visio diagrams (even, as I've seen in a few places, one single gigantic diagram with 200 different components on it). Second, the very discipline of adopting a modeling tool implies a commitment to maintaining the model – which reinforces the idea of an up-to-date model rather than a static document that is hard to use and even harder to maintain.
The second quick win that you can accomplish is creating and making available a set of organizational reference models for projects. These could be process models, architectural models – ideally, both. Again, in theory you could accomplish this by using a set of Visio or PowerPoints, but in practice this solution does not offer enough usability or maintainability. The adoption of the tool, which facilitates this, provides a second quick win to demonstrate to stakeholders.
The final quick win is more organization specific – a technique that I’ve seen work well is to identify specific stakeholders who have concerns that the tool can address. These tend to be of two kinds; reports (e.g. what percentage of applications are Free and Open Source Software (FOSS), Commercial off the Shelf (COTS), or in-house, what percentage of applications have no identified owner) and analysis (which applications support which business units, which datacenters or racks support which applications). In both cases, the information could in theory be gathered without the tool – but the tool makes it practicable.
While adopting a modeling tool as part of an overall adoption of modeling discipline offers long-term benefits, the nature of most organizations is a need to see short-term results. In this post we've seen that this is possible without compromising the long-term goals.