Introduction

In 2021 we have been tasked to have a look at how PEGA clusters have been set-up. We will not share too much information on this blog, but one detail on how everything was organized is that we had shared clusters. This was introducing some engineering challenges when implementing new features and everything is about speed and adding value. This is where we have started on our exploration journey: how to optimize the automation of the platform. 

1. Starting from scratch

Our team consisted of several colleagues with automation knowledge and some enthusiastic engineers that wanted to make a difference. We have outlined the concepts of what we wanted to achieve to have an clear focus with everyone on our outcomes. As we wanted to have speed, we started small with an so called Proof Of Concept to show what we could offer and how it would work.

We started our automation journey by embracing concepts as Infrastructure as Code (repeatable human understandable steps) of deploying platform features into our platform. After making a lot of errors and learning ‘the hard way’ we managed to set-up an product that was ready to be shown, but we encountered the next problem: architecture choices.

2. Architectural guidelines

From the area we were organized in different focus clusters, resulting in also similar named application clusters, which might make sense from an business perspective. We thought, from the IT point of view, it did definitely not really help us to offer speed to individual teams. Sharing clusters and fully functioning development and test environments caused blocking issues in different teams sharing the same clusters.

For that reason we have cooperated heavily with our smart internal architects around us to battle on the so called Target Operating Model. We really needed a lot of conversations to come up with our defined strategy among business, architect and it stakeholders and we called the platform: Rabowings.

The focus at that time was to give all the teams the full autonomy on the environments so that they could control their own application lifecycle as how they want it.

3. Full autonomy for the teams

Although our Proof of Concept was really well received by our internal stakeholders ( the teams that were going to be onboarded to the platform ) we also faced ‘fear of the unknown’. For that reason we had to take one step back and also share our insights and ideation on this process a lot with other stakeholders. We have decided to do some marketing roadshow and ask for teams that wanted to step forward sparking our collaborative journey.

In the end we knew that an actual customer would also improve the speed of adaption among other stakeholders instead of us preaching the product seemed good to be used. 

By sharing our story but most importantly, by listening to the concerns of our stakeholders and actively working on them, we gained trust and started implementing the platform. As I came to know recently via an friend of mine: we have two ears and only one mouth and that is for a reason. Listen carefully and think before speaking.

4. Reducing our CO2 footprint

Because of the way this platform was set-up, we were able to also win Finanical Ops (FinOps) contests within the CITO domain related to the amount of money we could save by reducing unnecessary spent in resources. To explain what we mean by this is that we have really defined the amount of resources we needed to run the business on and to give the teams the required environments for testing the pipelines.

By switching off all the development, test and acceptance environments overnight we have reduced major costs, leading to an lower CO2 footprint in the world too. This was the result of really well collaborated effort from our Morphiq engineers and the onsite engineering team with smart colleagues. Kudos to everyone involved.

5. What were the most important ingredients in this Journey?

Reflecting on this project, we think there were a few principles that made this project a success: 

1. A Scalable Strategy and Reusable Framework

We developed the platform in such a way we could scale out to many teams, with low infrastructure costs, making incremental changes (long term focused).

2. Involving Real Users Early and Often

The input of our teams that were already using our platform or were about to use our platform helped us in designing the solution.

3. Leaving your comfort zone

Leaving an comfort zone may feel hard for human beings, but it was required to ignite this engineering journey by challenging the status quo and having a lot of conversations on it.

4. Building flight hours

During our engineering journey we have faced a lot of uncertainties for which we did not have all the solutions in place. But by having the right constructive mindset and open and respectful communication we dove into the right topics, investigating and making decisions on what the right way forward should be growing the platform.

6. Conclusion

Customers and engineers worked together hand in hand by shaping the platform as how it is today. By this co-creation approach we have built an really stable and fully (really completely) automated platform with an awesome experience compared to our earlier situation.

On behalf of Yoram and me an huge shoutout to the team involved as without all of you we would have not been able to deliver this journey. All teams can deliver their software everytime they want to check-in code on their development, test, acceptance and production environments while reducing CO2 footprint of our platform continuously. Awesome.
We all transformed today into tomorrow. Thanks!