CBS and Project Phoenix
Like most statistical organisations confronted with the explosive growth of the internet and associated social and technological developments, CBS had been forced to make small and large integrations into their data collection landscape. But these changes slowly deteriorated the landscape’s integrity. So, in 2014, CBS launched a project named Phoenix to futureproof its data collection. Its goal was to create an application landscape for all of CBS’s data collection so that surveys could perform more efficiently.
This year, thanks to careful planning and incremental implementation, Project Phoenix came to its timely conclusion. It was a long and difficult journey, and we would like to share CBS’s experience for when your organisation faces the same undertaking.
The Whys behind Phoenix
A variety of reasons led to CBS’s decision to create a new application landscape from the ground up. These ranged from IT and organisational reasons to concerns for the future of its data collection programmes.
Organisational changes within CBS
Before Phoenix started, CBS had undergone a structural change and centralised all its data collection into one department. But systems and processes weren’t harmonised yet.
CBS’s data collection lacked efficiency
CBS needed to improve its workflows and processes to become more efficient. It was necessary to reduce costs and the time-to-market for its surveys.
CBS’s IT landscape was outdated
CBS has an extremely complex data collection system because, as a central data collection office for the Netherlands, data is gathered and stored from a variety of sources. These range from self-interviewed citizens to external databases. CBS also performs personal (CAPI) and telephone interviews (CATI) but is increasingly relying on web interviews (CAWI). As such, the IT landscape has gone through many adjustments in the past decade which, bit by bit, fragmented the application landscape. Furthermore, some software systems were outdated and continuity was at risk. Over time, major maintenance had become impossible.
Changes in the environment required CBS to adapt
The internet’s explosive growth over the last decade has affected social and technological developments. Nowadays, huge amounts of collectable information are digitalised.
To increase respondents’ participation willingness, CBS wanted to reduce the burden on citizens and companies responding to data collection requests. Their data collection needed to include new methods, like the upload of excerpts from business administration. Further, extensive use of secondary sources, such as the Dutch tax authority, became desirable to eliminate the need for additional questionnaires.
Ever-growing concern for response reduction
Because respondents’ willingness to participate in surveys is declining, data collection needed to become more flexible and user-friendly. CBS wanted to make better use of its mixed-mode data collection. Though CBS’s suite of survey software tools already employed smartphones and tablets, the old application landscape hindered the use of Blaise 5’s full potential. The landscape needed to change so CBS could fully utilise Blaise 5’s layout flexibility and its resource database.
To improve its survey designs, user-friendliness, speed, and efficiency, CBS needed to overhaul its existing data collection landscape. CBS called its new landscape Phoenix after the mythical bird that rises from the ashes of its predecessor. A well-thought-out project was absolutely necessary for driving such a major change: Project Phoenix was born.
Project Phoenix
When developing processes and systems, there are two main approaches: Brownfield development and Greenfield development. Until Phoenix, CBS had applied the Brownfield approach, making slight changes to the business processes and adding new software to the already existing system landscape. But “the main disadvantages of the old system were maintainability due to ‘spaghetti code’, fragmented environments, and outdated technology”, says Rogier Hellenbrand, Information Analyst and a member of Project Phoenix.
The Phoenix project leaders decided it was necessary to switch to the Greenfield approach and build an entirely new system from the ground up. While this meant that they didn’t have to depend on or integrate old software and could implement new state-of-the-art technology, it also brought big risks, high start-up costs, and a long development time frame.
Conditions and Challenges
Since developing Phoenix would be a long-term project and CBS had to continue its data collection activities without interruption, it was essential that Phoenix not cause disruptions to the existing landscape. The new system also needed to remain flexible and modular. Phoenix needed to accommodate the replacement of abandoned applications and channels with ones that may arise in the coming decade, such as data collection through apps.
Additionally, since Phoenix was to be implemented incrementally, maintenance needed to continue on the existing architecture and also run for finished elements of Phoenix.
Goals and Methods
Because of the many development options, Greenfield projects require a clear direction and understanding of the new processes and systems in all their aspects. While developing the architecture, CBS took its most complicated surveys into account, to guarantee that all surveys worked in the new situation. Different ‘stress tests’ were conducted on paper.
Marc Houben, Chief Product Owner and Business Architect in Project Phoenix, explains: “One goal was to have the same process and systems to handle social and business surveys. In developing Phoenix, one major principle was to build smaller, specialised systems that interacted with each other instead of building one big IT-system. For each system, the project leaders decided to either buy an application from the market or build it.
“Blaise received a clear place in the total system landscape. We use Blaise in three collection channels: CAWI, CATI, and CAPI. So, for example, a system for allocating CAPI-interviewers (based on travel time) was bought and integrated with Blaise and other subsystems. Development of the new logistics focused on the idea of plug-and-play, meaning it will be easy to add new observation channels and remove old ones in due course.”
Another major principle was execution-by-design. Marc Houben explains the process: “First all the aspects of a specific survey, such as the mixed-mode collection strategy but also the actual Blaise questionnaire and its metadata variables, have to be described. All the design aspects are then entered into the system so that the execution of the data collection cycles of the survey goes automatically. As a result, almost no manual tasks need to be conducted during a survey’s execution.”
Based on a vision and strategy, Project Phoenix started by developing a business and IT architecture for the data collection domain. Below is a simplified graphic of Phoenix’s domain model.
An agile development method was used, wherein processes and software were developed in small iterations with rounds of feedback from users for every implementation. This allowed Phoenix to rise slowly, first implementing simple situations, and learning from that experience before moving on to more complex cases. This meant that while the project’s course was always clear, the architecture was adjusted whenever proven necessary.
Process and Organisation
From 2014 to 2015, the Phoenix project leaders evaluated the situation of CBS’s data collection landscape for the following decade and created the initial architecture.
During the entire process, the project managers included stakeholders and their input. The project was led by a programme committee with a programme manager. The seven members of this committee came from five departments within CBS: Data Collection; Socioeconomic and spatial statistics; Economic and business statistics and National accounts; Operations, IT and Methodology; and Process development and Methodology.
A group of seven people oversaw the programme staff. This group included specialists such as an IT architect, a business architect, and an implementation manager, from four divisions: Data Collection, IT and Methodology, Process development and Methodology, and Project- and Programme Management. Since the transition of all surveys from the old situation to the new was part of Project Phoenix, the programme staff also included a project manager for the transition.
The project members were divided into two groups, one for the development process and one for the transition. The development was carried out by three agile development teams, each responsible for developing a set of domains such as Survey Management and Data Access. These teams comprised scrum masters, product owners, architects, information analysts, software engineers, test engineers, and specialists for various tools. The transition group consisted of four teams.
Eight subject owners for different topics such as data access, communication products, CAWI, or CATI were the first point of contact for the product owners and agile teams.
Project Phoenix consisted of a repeated cycle of steps, each starting with a preliminary investigation and ending with the implementation of a new functionality. The preliminary investigation always included stakeholders for their input.
During each step, the product owners’ responsibility was to select and prioritise topics and consult with the subject owners. FIT/UAT (Functional Integration Test/ User Acceptance Test) was conducted by the appropriate stakeholders, depending on the functionality being built. Once the functionality was sufficiently tested, released and implemented, the product owner remained the point of contact for CBS’s employees. This way, the appropriate development teams could gather and deal with any occurring problems.
Transitioning to Phoenix
In September 2016, the Phoenix project celebrated its first big milestone: the School-leavers survey was the first survey to be conducted through Phoenix. In the last quarter of 2016, two more followed, one of which was CBS’s health survey. During the following years, CBS slowly transferred more surveys—139 in total—to the new landscape, using each to test Phoenix for weaknesses or missing functionalities. “For example, using collected data showed complications in the retrieval of the data, so the Phoenix team worked with the departments responsible for processing statistics to optimise data retrieval into a uniform action,” Marc Houben explains. Phoenix now stores all data in one place users can access.
Finally, only one year after the initial completion date, on the last day of December 2021, the final survey was transferred to Phoenix.
A Soaring Phoenix
Since the beginning of 2022, all CBS surveys run in Phoenix. Any survey can make use of mixed-mode data collection, and the entire data collection department has one streamlined framework for their assignments.
Having fulfilled its goals, Project Phoenix has officially ended. But “in these kinds of projects, maintenance never stops,” Marc Houben reminds. “You always need to add and adjust things. For maintenance of the systems, we have two agile teams with around seven people each, though they also work on non-Phoenix related items.”
We hope this article is useful to your organisation’s decision-making process for your own landscapes. If you have questions, Rogier Hellenbrand and Marc Houben are happy to explain or put you in contact with other specialists within CBS. You can