I read an interesting article about how the pendulum is swinging back to centralization of IT resources. Two of the most important results are an increased effectiveness in decision rights – the way technology investment decisions are made – and in information flows from IT to the rest of the business. This is related to, but not identical to some of the observations I’ve been making in this blog. With centralized data, everyone can see the same information as it is being added and manipulated. With centralized data, you can better control access to the data – ensuring that the people who should not be able to modify a requirement can’t modify it, and ensuring that the people who should not be able to read the project plan for a new secret project can’t read it. You can control the processes you enforce around manipulation of the data. For instance, when evaluating some third party software for inclusion into your next release you may start with an initial technical evaluation, followed by a business case analysis, followed by legal signoff, followed by a purchasing decision. As other stakeholders need to get involved, you can change the workflow. Workflow needs to grow as your organization matures and it’s a lot easier to evolve your workflow if the process is owned and managed by head office.
A centralized source code repository is required if you wish to have follow-the-sun development practices to increase your agility and development speed. It is also required for effective reuse of information assets such as source code modules, requirements repositories, documentation artifacts, test cases and designs.
But (and there always is a but) data centralization comes with a new set of challenges. Follow-the-sun organizations have no downtime to maintain their infrastructure, creating more stringent requirements for the tools and infrastructure used by the organization. This makes the tools more expensive. In addition, it creates new requirements for your development team – they must be more careful about how frequently they check in their changes. You must have systems in place to effectively hand off work from one development center to the next. I can’t imagine how you can manage these processes without the use of tools. Tools need to remind developers when they should start thinking about checking in the code, and ensure they don’t leave the office without checking in all the pieces they need to check in. Tools to help them describe to the next team what they have done and what still needs to get done. Additional communication channels need to exist – not just email, but also instant messaging, online conferencing, and annotations on defect incident reports.
The management of centralized information assets requires more planning, more attention to stakeholder needs, more time to roll out changes, and more communication to stakeholders. Communication has to take more forms than occasional emails. The corporate intranet becomes a more strategic asset. Training becomes more important. Information must flow more easily not only from head office to the satellites, but the other direction too. Metrics around adoption rates, usability and productivity, however imperfect, must be maintained and constantly tweaked to ensure that you keep track of rollout progress and of snags in deployments.
Perhaps the most important requirement of a centralized data repository is that it be easier to use and more efficient than simply keeping local copies of everything. Your stakeholders outside of head office have their own financial targets that they must meet. They must meet project deadlines. They must keep morale high. It depends on your exact circumstances, but in many cases it is so easy to go “off the grid”, as it were, that if you are not delivering real value to your satellite offices, they may start to abandon or ignore your poorly crafted central repository. You never want that to happen! Thus, one of the true benefits of data centralization is the implied obligation to your decentralized stakeholders that they will always have best-of-breed infrastructure at their disposal. And that can only be a good thing.