In my previous post I talked at length about how integrating between your architecture modeling tool and your Configuration Management Database is possible and can have value, but like most things in corporate IT, it’s not as simple setting up an import and reaping the rewards.
Today I’m going to talk about another possible integration into your architecture modeling tool that is not quite as common but still comes up from time to time – what level of integration does there need to be to your project tracking system?
It’s a fair question; given that any significant change to the architecture is going involve expenditure of funds, such a change is going to fall under the control of one or more projects – whether it’s solutions architecture project driven by a business unit, or part of a wider scale business transformation project.
The natural impulse might be to model the projects and programs themselves within the architecture tool. After all, the TOGAF meta-model includes gaps, and work products, and requirements, and so on. Likewise ArchiMate has a delivery extension that is explicitly intended to model projects and a motivation extension that, among other areas, allows you to model requirements. So the natural impulse is to check what mechanisms exist to import the list of projects and programs into the modeling tool.
However, this ignores a simple fact – modeling the projects in the architecture tool is naturally going to require an extra expenditure of effort. So the question becomes – is there a point to doing so?
As stated before useful rule of thumb is always to ask – what analysis or insights is the model supposed to provide? I would hope that no-one would suggest that you should use a modeling tool as the primary project tracking tool; the value that you can obtain from modeling projects in the architecture tool comes from being able to trace specific projects to the architectural elements that they affect essentially, the ability to create traceable roadmaps.
So, the decision of whether it’s worth importing projects and programs, and modeling them as part of the architecture model, comes down to the question of whether the area of focus for the architecture practice is a formal roadmapping effort. It should not be based on whether there is an intention in the future; it is something that is being engaged upon now. Without this, without the commitment to actively map projects to changes, any such import becomes a pointless exercise.
If this is the case, then a more basic level of integration may still have value. Most architecture tools have some kind of web interface, and they may enable links to specific models within this interface. Assuming that this is the case, there can be value in incorporating the link to the models for the project within the project tracking tool. While this is obviously less comprehensive a linkage than the formal import discussed above, it does at least provide a ‘quick win’ with minimal effort.
The issue with importing from one tool to another is often not whether it’s possible, but whether it’s worth doing. As we’ve seen in this post, there’s only a point in setting up some form of integration between the architecture tool and the project tracking tool if there is a formal roadmapping initiative in place.