Recently, I've been working with a client as part of a major platform change they're making. It's the third time I've been involved with a big architecture shift, each at a different company, and each larger than the last, but there seem to be some observations that apply whether you've got five servers or five hundred.
1. Business carries on
It can be easy to get somewhat myopic when in the middle of an exciting architectural change. Major platform transitions tend to occur when there has been a realisation high up in the company that something needs to be done, so teams often have a fair degree of scope and freedom. However, it is even more likely that other parts of the business will need to continue to work on the existing system. If a new feature is required then it's going to get developed, even if that involves duplicating, or worse conflicting, with work that's being done as part of the platform change.
In part this can be mitigated by communication. If everyone knows what the new system will offer, and what the timescales are, they're more likely to take it into consideration when planning their own development.
This works both ways; the change team can help matters by considering outside priorities when planning the new platform itself. For example, if there's a particular service that old system projects could use, consider prioritising that, and making it accessible independently, ahead of the unrelated parts of the new platform. As well as maintaining harmony, this will have the major benefit of getting more eyeballs on the system right away - rarely a bad thing.
2: It can't be done in isolation
Even once the new platform, or a part of it, is in a fit state to be used by other developers, if the proper groundwork hasn't been done then there's a good chance of problems when they try to do so. Part of any architecture change has to involve removing the barriers to entry that developers will face when migrating.
In the first place, developers must be able to develop on the platform! It's extremely easy to gloss over serious setup problems because the change team are already past them, but if the system is operationally difficult to use then it's going to be much harder in transition, both for development and production.
VMware virtual machines are an excellent way of packaging up a development environment, and can be used to tear down and rebuild production builds until it's a seamless process. Change teams should consider creating a VM for new developers that contains a ready to go example of (all, or part of) the platform. This means services set up, appropriate libraries checked out, and everything as close to the production system as practicable. Doing so makes it much easier to get going, and bottoms out many of the important setup issues.
Of course, technology changes often involve moving to a whole new programming language, sometimes more than one. Even if the system is staying with the same language, moving from, say, PHP 4 to PHP 5 involves a significant change in style in order to make best use of it. It may be worth bringing in a few extra experts in the language, and devising a specific training programme tailored around the new system. As an added benefit, it should be reusable on new hires.
3: It's easy to lose focus
Once the architecture has been decided there's a good chance a certain project will be given the honour of piloting it. This may or may not be handled by the team that has worked on the platform change, but in either case it's easy for everyone involved to get focused on this one system, at the expense of the bigger picture.
It's worth everyone, not just the project manager, occasionally revisiting the reasons the platform change was necessary, and the goals it hoped to achieve. It's not a bad idea to have a written mission statement - even if it's just a page on the project wiki - to give everyone a baseline, rather than leaving it to one "Keeper of the Vision".
4: Transition is hard
Even when the pilot system is out the door and all the developers are on board, it's unlikely that the transition will be a sudden switch from old to new. More likely the systems will have to coexist, with the new platform gaining ground as sites or applications are moved over to it. It's worth thinking about how to handle that early on, and it may involve some work on the old system.
Two things that can help each here are proxies and SOAs. Something like mod_proxy for Apache can let you pass requests through existing servers, giving you a way to tunnel one system through the other. This might be the simplest way of maintaining access during the transitional period, and it may not be worth going any further, if it's not causing problems.
If the systems can't be split as easily, the team consider an SOA. Service Oriented Architectures are just the good programming practice of modularity writ large, and there's a good change that a modern architecture refresh will be involve them to begin with.
They can be used in a transition in the form of wrapping legacy systems, providing web services that offer a flexible way to give the new platform access, and allow a replacement to be dropped in once the wrapped system is ready to transition itself. Similarly, it's often reasonably straightforward to abstract out what would have been some database calls or file reads on the legacy system for calls to a simple web service, allowing the old system access to resources that now reside on the new.
Ibuildings Blogs
