DOORS Information Architecture Workshop. Part 4 of 4

From the previous three articles in this series, we know what we have and what we want to have; we just have to plan the route. I have started this section with definition of the database schema, which is arguably a part of the to-be. I have included it in this roadmap planning phase because it is implementation, as distinct from requirements.


As a reminder this series covers:

1. What information needs to be collected for the as-is
2. How to collect the information for the as-is
3. Identifying the to-be solution
4. The plan to move from as-is to to-be

Finally the roadmap.  We have an as-is and a to-be, how do we get from one to the other?

This is in two parts, first the structure of the data, and secondly the roll out plan.

There are some easy parts to structuring the data.  From the discovery work we did, we had types of data connected by verbs.  Each type of data is a Formal Module (or a set of Formal Modules), and each verb is a Link Module. A folder hierarchy for a typical project can be produced with knowledge of project size, duration and formality, combined with some good practice guidelines. The access control needs will in part shape the hierarchy.

We looked at how the data would be analysed.  If you want to analyse requirements by, for instance, complexity, then you have to capture the complexity. The analysis and reporting requirements give us our requirement attributes. There is no point in capturing data that will not be used, and we must capture all the data that is necessary for these activities. To decide upon the views that are necessary, the process steps will be a good starting point.

We are now well on the way to a database schema.

Roll out is a separate problem. First we have the issue of deployment; installing everything server side and client side and making sure that user accounts are planned – either through LDAP or by having a plan to add users manually. Backups need to be configured and security, disaster recovery, availability and administration need to be planned for.

Once this infrastructure is in place, a template project is often used as a starting point for new projects. This template will be built to the schema described by the process above.

Users need to be trained, and while this doesn’t need to be extensive for all users, there should be some basic introduction. Projects can then either migrate or start in the new database, and some processes will change to take advantage of the new capability.

The assumption should always be that there is no customisation necessary, but the reality is that some customisation is almost always required.  This is why we have DXL, but it should be used sparingly, as any scripts need to be quality checked to ensure they work as intended, and maintained through upgrades. A small number of people will need to become proficient if DXL scripting is a key part of the solution. A large scale scripting deployment needs to be treated as a serious project in its own right.

I have completed mini versions of this workshop in a day for a very simple implementation and an undemanding customer. A workshop would more normally run for something like 3 days, with a follow up of a full report documenting all the as-is and to-be findings, along with a database schema and migration and roll out plan.

Most organisations will also want some help with setting up and rolling out their deployment. Typically there is insufficient expertise in the organisation, although some do buy in that expertise with recruitment. In my experience it is worth spending a little longer on the set up and roll out phases to ensure that knowledge and skills are transferred to the new team.

Without a start up similar to this Information Architecture Workshop it is unlikely that there will be consistency between projects, and there is likely to be a need for restructuring of data after the projects are underway.