- Introduction
- Deciding To Move to a Common Architecture
- Coordinating Between Teams
- Project Requirements
- Human Factors
- Development
- Testing Code
- The Payoff
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Deciding To Move to a Common Architecture
Each site was originally built from scratch with its own features and options. This means that if site A wanted a feature that had been implemented on site B, the team had to write it all over for site B. Or if site A had created a new feature, site B wouldn't get it until they asked for it (and the team wrote it again for them). Crazy, huh? To complicate matters, PTG changed hosting firms about the same time as the redesign work was underway, so the IT department had to plan and implement a data center move concurrently.
Product development convinced management that it would be cheaper in the long run to implement a common architecture and code base for all sites under PTG. The redesign uses the magic of CSS to ensure that each site has a unique user interface, while maintaining the same underlying code.
According to Michael Hughes of PTG's project management, the motivation to bring all of the partner sites into a common architecture, in a nutshell, was efficiency. This includes a reduction in the time required to produce common functionality one site at a time for multiple business units over 12–18 months, as well as planning and performing all aspects of new work (business development, prototyping, coding, and so on) over the life of the program. Now, when site A wants a feature on site B, all the team has to do is turn it on for site A. If site B wants a new feature, site A can have that new feature as well, as soon as it's available.
Challenges of the conversion? Many. First, everyone had to agree that this was the best course of action and would lead to improvements in service, bug fixes, and new feature implementation. Next came the development of a list of features to be supported, which of course had to be accepted by all parties. Documentation had to be created, describing all of the features for the development team.