New CIO arrived as an Enterprise System Renewal Program was being initiated — more than twenty major business applications were being moved from mainframe to cloud in a multi-year (four-to-five year) roadmap. There is a lot of business process reengineering needed here, and a lot of technical change!
Program commenced in 2018 and is still (principally because of the Student Information System being pushed out) running now.
There was a need for change, which was exacerbated by the institution a best-of-breed approach (best HCM, best RMS, etc) rather than a single-vendor approach, and each team was using its own technical-infrastructure-integration tools. The delivery of integrations was felt to be slow (four–six weeks) and none of the integration platforms involved were built for or ready for the new cloud environment — major blockers here to having an "integration factory":
What got deployed? At the centre of this blueprint is the integration-platform-as-a-service core:
...comprising these key elements:
The rollout of all this technology needs people, governance, process, and technology all to work together in a comprehensive and well-coordinated way!
Over the programme implementation there has been a big shift from in-house application development to a strong focus on integration, and a strong focus on integration using the new core platform. This is moving away from having groups of developers "attached" to particular business domains (e.g., a group of developers looking after the Finance Management domain, another for Housing & Dining, another for Student Administration, etc).
An example of the change required is the implementation of Oracle Financial Cloud, which replaced the functionality of a lot of separate on-premises and mainly-bespoke application solutions. Anything bespoke that needed to continue as a localised special function needs to be rebuilt on the new stack, including the new iPaaS.
These domain-aligned groups each had their own processes and their own development lifecycles and their own tools. Through the Enterprise Systems Renewal Program there was a huge shift from homegrown applications developed over many years by passionate and skilled technical and development teams to brand-new software-as-a-service solutions — there is a lot of managing-the-effects-of-change-on-people required here to overcome change resistance and to build people up. Some folk were very excited and very empowered by the change from the legacy and the bespoke to the contemporary and the streaming, with common platforms and tools and standardized processes. Overall, there are around forty developers part of initial ESR project.
The change-management used the ProSci "ADKAR" methodology, with the clear identification of sponsors, of stakeholders, of people involved in and affected by the change and their posture (e.g., supportive or resistant) to making the change:
In the identification of "change champions", people with growth mindsets and an open approach to experimenting with new tools and technologies and new ways of working were identified and worked with to help effect, communicate, and cement the changes.
A good solid communication plan was established, and there was a point at which the term "iPaas" was banned (jeff: this sort of thing does seem to happen quite a lot!). The organizational-change team was run through the Organizational Change Management Office, working with the Communication Office. Nathalie was the change lead for the ESR programme, but this was overall a very small team! The PMO was involved in this throughout.
The Organizational Change Management approach taken here was basked upon ProSci ADKAR (https://www.prosci.com/methodology/adkar) methodology:
Each of these ADKAR change-management modes is considered in turn below, as applied to the Enterprise Systems Renewal Program at USCD.
The kick-off event was the department-wide "iPaaS is here!" event, which outlined the what-and-the-why of the new approach, emphasising the value of streaming (over historical batch-based approaches to data integration). The presentations and content here were developed centrally and were recorded for later playback.
This was followed by targeted conversations and deeper-dive sessions with specific technical groups that will need to start using iPaaS. The senior leadership gave a blessing to use selected developers from various teams to undertake the new integration development work for the new Oracle Financials Cloud — and these people put their hands up to be part of this, and were drawn from right across the domain-aligned teams, forming a new interdisciplinary group and having better conversations about iPaaS.
User provisioning and training and the beginning of the development work happened with the kick-off meetings that followed with these delivery teams.
Pizza parties! Change Champions would share experience and reflections and lead discussions with next-wave delivery teams to be coming onto the platform. Important to have the sponsors there and engaged and showing their support.
Vendors and contractors with expert knowledge were brought in to work with change champions and the delivery teams, identifying the use-cases and starting to build actual integration products in the right ways. Subsequently, the change champions started to engage in train-the-trainers session to uplift their colleagues.
There was a list/manifest of integrations required for (for example) Oracle Financials Cloud, and people in the teams were then working together and holding collaboration workshops to create these necessary integrations for the new solutions.
Online training provided on an ongoing basis to builders. There are dedicated pages for new developers that shows the overview of the iPaaS approach and has information about its components and the UCSD patterns and what onboarding looks like. Information about best practices is also made available there.
iPaaS is here to stay! — note there is a Pattern Catalog that's been published to standardize development, so there are recipes for (for example) shipping data from a database to a file, from a file to a SaaS solution, etc. From an architecture-and-artefacts perspective there was a general focus on the purpose and goals of what success looks like and the emphasis on the Pattern Catalog.
...and also J.J. du Chateau