PLOT – Story for successful Change

Let me start with a small disclaimer -  In this post I am not going to lecture around what is
change and incident management. Rather one of the effective ways  to plan for a change.
There exists many such tools and flows to effectively carry out a change , however - this is
just one amongst those.

Well , we all know that change is common, natural and inevitable for an organization to grow,

both from a technology standpoint and org structure.  Here, I will try to cover various aspects

of the technological / IT production changes and not the latter. 

According to a report from McKinsey,  70% percent of change programs fail to achieve their
goals.

But why? Its is said that , the reason for such failures is due to employee resistance and lack of management support.

I would say - it is primarily because - “Changing human behaviour is hard”

Successful change management requires frequent and clear communication between an
organization and its people, and most importantly - convincing ourselves and others that the
change candidate is compelling, motivational and realistic!  i.e. every change initiative needs
a convincing narrative. 

American systems scientist  Peter Senge says:  “People don’t resist change, they resist
being changed”. 

I think we all agree that -  any / all change initiatives must be backed by a process,
so as to ensure it is well organised , and repeatable. 

Mnemonics

A bit off-topic , but I think we all would agree that - to remember anything , mnemonics helps us in a great way.  

Remember BODMAS -  The order of mathematical operations? :D

OR - the phrase "My Very Excellent Mother Just Served Us Nine Pizzas" - to remember the planets, sadly Pluto is gone though.. but anyway!

Here comes another one -    PLOT.

What is PLOT ?

Ain't plot is such a familiar word when it comes to movies .. exposition , climax , action etc. etc.

In this case , PLOT is an abbreviation in the areas of effective change management , and it stands for Plan, Lead , Operate and Track.

Fine , how is it helpful?

While there exists numerous processes and flow charts to effectively carry out a change ,
one of them is  PLOT - a method designed and documented by Bain & Company -
one of the most prestigious and global management consulting companies headquartered
in the US. 

This PLOT flow helps us to convince and align ourselves to an end-to-end change
management process , keeping transparency, compliance , various guiding principles ,
communications points and many such things which is very instrumental to execute a
change effectively.

Below is my adaptation with some small tweaks , however if you google it , you can easily
get their original document with more elaboration. 

Step 1: Plan it well.

Step 2: Lead the change

Step 3 : Operate ( Execution phase)

Step 4 : Track it well.

Every organization has its own change management flow , but I am sure this PLOT can be a good chip in that flow for sure.

For. ex. 

During the execution phase many things may go wrong depending on how deep or broad
the change is. It is very important to understand that - “when on principle:  It’s understandable,
memorable, and repeatable , and eventually drives empathy!”

Closing thoughts ..

No matter where you are in the system life cycle, the system will change!
The desire to change will persist throughout the life cycle.
But,  the underlying services should be always stable, reliable, and predictable.

Above images are screenshots from one of my previous presentation, which I know,
is of not the best quality , hence attaching the original PPT herewith.

Download PPT Link

Please dont hesitate to share your thoughts in the comments section..

Happy holiday season and Happy new year 2020!

Until next time ..

Debajit Kataki

The time you spend with yourself!

That walk from your boss’s cabin to your desk … same distance which is sometimes very short, with a relieved and refreshing mind,  and sometimes very long, rattled and engrossed.

Not all conversations go well and often we find it very hard to tackle.  The conversation you just had with your boss or anybody for that matter, could either be exposing your limitations and surface opportunity areas or  sometimes it can also be very re-energising or trigger a sense of renewal.

What we go through in situations like these are – ‘reflections’ and depending on how we take it, these moments could produce varied sentiments.

“We do NOT learn from experience, we learn from reflecting on experience.” — John Dewey

Reflections are nothing but, looking into a mirror and describing what you see. It is a way of assessing yourself, your ways of working which helps you to develop your skills and review their effectiveness!

Self-reflection is a very powerful free tool which gives us perspective and helps us to understand ourselves better.

Trust me – it’s not easy to start at this 😃, as it does not come naturally to majority of us, and in-fact even I am still trying to be regular at this and hence the post -  where I am trying to share my own experience.

I have found it very productive that - when we create some lonely time for ourselves and do some regular self-introspection, it’s actually a game changer!

But how and where to start:

Most of our perennial learning comes NOT from doing, BUT from thinking about what we do, and why we do.

Often, we go through our day-to-day life without spending too much time “processing” our experiences. This processing is very important and fuels creativity.

Questioning in a positive way, what you do and why you do it and then subsequently pondering over ,  whether there is a better, or more efficient way of doing it in the future.

The Real Question:

Just think about this - can I sit quietly for about 5-10 mins daily and reflect on - “If I were to re-live today again, what 3 things would I change to make today better?” Yes! That’s where we need to  start. And as I said – it’s not easy!

When we participate in new experiences, experiences that are outside of our comfort zone or outside of our routine, there is often a lot of learning that can take place.

If we really wish to be a person of indomitable spirit, we must cultivate ‘habits’, good habits of-course! 😃

One of them is certainly creating ‘time-alone’ for yourself.  It’s a time of solitude, where you spend time with yourself.

Our brain is constantly processing and unravelling. Most of the time it’s about our ‘delivery responsibility’ in this busy and competitive world. A cup of tea alone, a walk in the park, writing daily diaries or blogs, or even a quiet five minutes at the end of the day could make all the difference where we may ask Q’s to ourselves, like -

·  Did I use my time wisely today?

·  Could I be a person other can respect?

·  Did I make a positive impact today?

·  Did I respect myself and valued my strengths today? ….

Such introspective Q’s can be really helpful and can potentially provoke us to think - whether I am progressing steadily in the line of my end vision, or just ‘being busy’.

Peter Drucker says:  

“Follow effective action with quiet reflection. From the quiet reflection, will come even more effective action.”  

In my personal experience, I have found that -

·  Solitude allows you to reboot your brain and unwind!

·  It’s always healthy to disconnect, unplug discover yourself, and find your own voice!

·  You will have better ways of solving problems and may get unexpected flashes of creative insight.

So, I urge, go ahead and schedule some ‘time alone’ for you, where its only your and with you.

And please do comment, if you have ever experienced the effectiveness of doing such self-reflection, and if my own reflections about ‘self-reflection’ is reflecting right :)?

Happy Reading! 

-Deba ... ( Debajit Kataki)

Database CICD

DevOps is all about inclusiveness.  In one of my earlier posts,  I shared why this is important!

I don’t think many organisations or application teams practices CICD or even version their SQL codes as a best practice while dealing with Database changes. 

As we go to AWS or any other cloud platform, the code deployments will be completely CICD driven, i.e. code releases will be at the developer's will. Hence, the complementing DB changes should be part of the pipeline / release candidate itself, and we should NOT look at the DB changes and code changes as two separate entities -  to get the full benefit of CICD in our quest for  'Speed-As-Habit'.

The database SQL's, unlike other software components is not often versioned. Thus, Continuous Integration (CI)  & Delivery ( CD )  for databases has taken a back seat to automated deployments, leaving database automation  play a catch up game.

If you have a full-fledged release program mgt. team managing and co-ordinating these changes manually, I think you really need to anticipate the world ahead. 

Consider these AWS or any other cloud scenarios:

•       AWS application deployments will be completely CICD driven.  

•       AWS way of doing deployments expects everything in an automated fashion Code/ IaC etc. 

•       Manual /synchronisation between DB and App teams will be very painstaking as - CI for code will be at the developers will and hence the releases (mostly!)

•       Hence, the SQL queries should also be part of the release / deployment automation. 

Introducing Versioning of SQL:

Version or source-controlling database changes is the first step in introducing databases to the DevOps / CICD  process. If your database changes and application code are in source control ( e.g. GitHub ), you can have a working build anytime, because you will always have a version to roll back to, and you will also have audit trail. 

There are many branching strategies you may adopt to suit your development process while introducing a new SQL repo,  which is part of your same development  stream.

This is the foundation to bring a transparent audit / approval / feedback mechanism in a true DevOps culture.

Proposing a new process:

A process somewhat similar to the below can ensure that - the database changes which is versioned in GitHub,  will get reviewed by the DBA’s even before the branch merge. The depicted automation ensures that the CI gets triggered only when the merge happens.  This not only helps in early review but also brings the real skin of our DBA’s in the game and ensures that the accountability and ownership get fairly distributed across the right stake-holders. 

As a best practice you can create a pool of 2 engineers each from DBA's and Developers to facilitate  the code review and subsequent PR approvals. 

Introducing CICD:

Below could be a ‘Big-Picture’ ,  binding all the components together.

Introducing Flyway DB:

FlywayDB is an Apache v2 licensed open-source tool that makes database migrations easy. You can think of Flyway as version control for your database.It integrates wonderfully with Maven.  It supports a very wide range of databases.  In the above diagram you can see that Spinnaker triggers triggers the FlywayDB instance to manage the changes. 

I highly recommend you read more about this tool in the below link –

https://flywaydb.org/getstarted/how

  

Now when subsequent changes comes , this is how FlywayDB ensures that the changes are safe.

The only overhead is that - FlywayDB maintains a small Schema version table with each of your databases. 

This may be a quick small approach towards integrating database changes as part of your DevOps process, which can accelerate the delivery of database changes and promote agility across the entire code-release cycle. I am sure based on the tools and your own IT landscape,  this might vary slightly. 

Happy to get your thoughts around this and discuss further. 

However one thing is for sure  - failure to include database changes as part of the DevOps /CICD practice will certainly slow down your release cycle!