Xin's Across the Enterprise

Summary:  copy the master file, add in project and personal stuff; get to work.

Which is the good data, again?

A primary concept in data management is single sourcing:  avoid multiple copies or multiple sources of data (unless there are very clear boundaries to the various data sources).

One solution to maintaining standards:  a single read-only InRoads Preference file (.xin) with everything in it.  There's a lot of problems with this and a don't support it.

Here's one example of a sustainable implementation methodology:

Xin Master

A single master file that:

• is up to date
• everybody knows about
• is the clear source for all non-personal or non-project specific standards

Project Xins

Each project should have a xin file that contains the source for project-specific deviations.  Each project .xin should:

• consist only of project-specific deviations (the common stuff should be stripped out)
• should have a single person responsible for incorporating new changes and deleting obsolete data
• have many users contributing improvements to it (managed through the project .xin manager)

Working Xins

Doing it yourself

Users should copy the master file to a personal folder somewhere and work from that. Use the Xini Manager merge tool (when it's built) to add the Project .Xin and your Personal Stash .xin.

Working from Project Xin

You may have a Project Manager who is managing a .xin file that is both up-to-date both Project-wise and generally.  Be skeptical.  You can work from that file or a copy.  Add in your stash if you need to.

Project .xin files that have everything in them tend to drift all over the place and get out of date.

Once a project file starts to collect general customizations then a dual-source condition occurs and entropy accelerates very quickly.

Keep Updating

Don't forget to provide your corrections to the InRoads Administrator (how?)