• 04 February 2022
  • University of California at San Diego
  • Nathalie Gholmieh
  • Ashish Pandit

Discussion Notes

Context, Scope, and Motivation

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:

  • Kafka
  • NiFi
  • API Manager
  • GoAnywhere
  • Airflow
  • EKS

The rollout of all this technology needs people, governance, process, and technology all to work together in a comprehensive and well-coordinated way!

Managing the Effects of Change on People

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:

  • Awareness of the need for change
  • Desire to be part of it
  • Knowledge of how to change
  • Ability to change
  • Reinforcement to sustain the change in the long term

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.


Meeting Details



  • 08:11:14 From  Jim Phelps  to  Everyone:
        Feel free to raise your hand in the participants panel or submit questions via chat
  • 08:19:08 From  Kevin Muller (Fordham)  to  Everyone:
        Wondering how many FTEs will comprise UCSD's InfoTech org once the ESR effort is complete?
  • 08:19:37 From  Jim Phelps  to  Everyone:
        What Org Change model are you using (ADKAR or other)?
  • 08:20:39 From  Piet Niederhausen  to  Everyone:
        Prosci ADKAR model link for anyone who’s not familiar: https://www.prosci.com/methodology/adkar
  • 08:21:17 From  Ashish Pandit  to  Everyone:
        There are around 40 developers part of initial ESR project.
  • 08:21:48 From  Kevin Muller (Fordham)  to  Everyone:
        TY @Ashish.
  • 08:22:25 From  Curtis Scheer  to  Everyone:
        Thanks Piet
  • 08:24:29 From  Jim Phelps  to  Everyone:
        How big is the Org Change team?
  • 08:34:07 From  jeff kennedy  to  Everyone:
        In some methodology-heavy institutions, the "go | no-go" decision for a project sometimes includes a change-readiness assessment to ensure the ongoing ADKAR activities have achieved what they need, to ensure the changes will be successful and sticky... but with hard deadlines around implementation that's not always a luxury that can be afforded!
  • 08:35:25 From  Ashish Pandit  to  Everyone:
        Very true
  • 08:37:01 From  Henry Pruitt  to  Everyone:
        how bad was dealing with the migration issues, and how many process areas / domains cut over at once? - ie big bang, or completed in waves by function where possible
  • 08:40:59 From  Jim Phelps  to  Everyone:
        Relationship between PM and OCM is described in Prosci  PCT Model https://www.prosci.com/resources/articles/project-change-triangle-overview
  • 08:41:40 From  Tony Turrin  to  Everyone:
        Thank you!  I'm new to ADKAR, so this is very interesting! 😁
  • 08:42:26 From  jeff kennedy  to  Everyone:
        i'm interested in the architecture artefacts (standards, guidelines, patterns) around the use cases... what was stood up around that sort of thing?
  • 08:45:06 From  J.J. Du Chateau (Wisconsin)  to  Everyone:
        Sorry I have to run. Thanks for the interesting presentation.
  • 08:45:27 From  jeff kennedy  to  Everyone:
        i'm also interested in the training! = beyond being certified in something like Apache NiFi, how is that technical training made relevant for how-we-do-things-here-at-UCSD?
  • 08:46:36 From  Ashish Pandit  to  Everyone:
        Different applications were deployed at different time, however for each application, we had to deploy necessary business processes along with applications
  • 08:47:59 From  Ashish Pandit  to  Everyone:
        That means some of integrations had to be done again when the dependencies also moved to cloud
  • 08:49:38 From  jeff kennedy  to  Everyone:
        ^^"Pattern Catalog" that sounds very excellent --- is Hohpe and Woolf (https://www.enterpriseintegrationpatterns.com/) still relevant and applicable to this kind of iPaaS implementation?
  • 08:50:49 From  Louis King  to  Everyone:
        This is fantastic. Thank you for sharing!!! Unfortunately, I have to run to my next task. Cheers all.
  • 08:51:10 From  Ashish Pandit  to  Everyone:
        @Jeff we had getting started training for each of our platforms.
  • 08:55:39 From  Rupert Berk  to  Everyone:
        How did you assess the success of the adoption along the way? e.g., relaxation of resistance, positivity, etc.


...and also J.J. du Chateau

  • No labels