One thing that I’ve noticed organizations can struggle with once they’ve bought a modeling tool is planning what needs to be done to roll the tool out. Many vendors offer some kind of services package to assist their customers, but for those organizations who do not have budget for this (or who simply want to understand the process better), I’m going to walk through creating a tool implementation project plan over the next four blog posts.
Summary: The first significant step in defining a project plan is identifying the activities that need to take place during the project, so we will start the discussion by examining the various tasks that you might need to undertake when rolling out an enterprise modeling tool. Not all of the tasks I list here may be relevant to a given implementation – prune as necessary.
There are three basic work streams that you need to consider when implementing a tool.
Identify Organizational structure
The first thing that you need to do when implementing a modeling tool is to identify the Organizational Structure of the community using the tool. Who will be creating information? Who will be editing models? Who will be viewing information via whatever web presentation capabilities the tool has? Who will want to see dashboards? The answers to these questions are important because they input into defining how the information is organized and what access needs to be granted to it.
Identify Governance Model
A related question is: what is your Governance Model? How do changes get planned and approved? What level or co-ordination is there between projects and EA? Definition of the different repository partitions (Libraries in iServer for example) falls out of how much coordination during design there needs to be between different teams.
Identify Reference Models
These two items feed into the design of your repository structure, but the third item might be surprising – identifying what reference models you will use. Various tool vendors offer solutions for TOGAF and ITIL, but what about BIAN? What about ACORD? Knowing what frameworks you want to use will feed into the design of where they will live in the repository.
Define Repository Structure
With these items identified, you can then plan the repository structure, and at the same time define what access roles will exist, and what permissions they will have to the different locations in the repository.
Implement Reference Models
Once you have defined the repository structure, including the locations of the reference models that you will use, you can then implement these reference models.
The above activities conclude one work stream; the two remaining work streams relate to the data that you put into the repository.
Define Modeling and Branding Standards
It’s natural that an organization may wish to import some of the work that it’s already done into their new modeling repository. But before they do, the organization should establish some standards. What modeling standards will they adopt? Will the organization use ArchiMate and BPMN? What about UML? What about the TOGAF metamodel? And what branding and logos do they want to implement?
Clean up legacy data
Once the templates, headers and footers, and what standards will be used have been established,the organization can move to start converting their legacy information. Most tools can import from some format or other. Once the legacy information has been cleaned, then it can be brought into the tool.
Data definition
The final stream out of the three work streams centers around data. To start with, it’s necessary to define what fields will be recorded against modeling entities, and against models. This is a dependency for two important aspects of the tool.
Create Data Feeds
First of all, the reality of modeling tools is that they have a scope. You don’t use a CMDB to track processes; you don’t use an EA tool as a CMDB. But the different repositories that an organization uses have overlapping information – and so many tools offer some kind of data import and data export facility. Usually there is some level of integration involved, and so defining and implementing the data feeds that the tool will use stands as a work item in its own right.
Define Reports and Dashboards
The other key item that the data definition is required for is – reporting. There is some value in a modeling repository in that it offers a single location, access privileges, audit trails and the like… but at the end of the day, you can get all of that by dumping a bunch of PowerPoint slides into SharePoint. It’s the analysis and reporting capabilities that are the value of a modeling tool, and so any implementation effort that does not define and implement the reporting and analysis capabilities that the organization needs is… rather farcical.
Tailor Training
With the three work streams accomplished, then it’s time to roll the tool out to the wider organization. This involves two main activities. The people who will be using the tool – architects, process modellers and the like will need training on those aspects of the tool that they will be using. This will ideally be tailored according to their specific roles, and so definition of the tailored training is a possible work item.
Deliver Training
With the tailored training developed, the organization can finally deliver it.
Execute Communication Plan
The second activity is the communication of the tool to those who will not be using it, but who have a need to know that it has been implemented – executives and the like.
So at this point we’ve defined the key work items for a modeling tool implementation. In the next post I’ll consider the factors that can affect how much effort is required for each of them.