3 Ways Enterprise Architects Can Bridge the Socio-Technical Gap
09 August 2023
Request your demo of the Sigrid® | Software Assurance Platform:
01 December 2022
6 min read
Organizations benefit from consistency. And yet, there is a cycle of disruption that many of us seem to be accustomed to because we see it happening over and over again, in many industries and in many countries, yet, we do not act upon it. This cycle seems to be almost culturally agnostic, at least when looking at the European playing field.
Let’s call this the Cycle of Organizational Memory Leakage.
When it comes to IT projects and building applications we, unfortunately, see it all too often. An organization defines an ambition and determines it to be special in a certain sense, which needs a customized supporting IT application/infrastructure.
Nothing wrong so far. When thought through and selected well, this is a valid approach.
Then comes the hard work, making this ambition a reality. Development teams are either hired or outsourced, designs are built and implemented, and the often years-long process of developing software starts. Implicit knowledge in the organization is gathered and turned into valuable organizational memory in the application to be and in the heads of those building it.
Then success comes! The first versions come out, and some tweaking is needed but, the application supports the business in growth and making a difference. Updates are made, additions requested, and finally, a stable version is available for the company to build its business upon.
With the building finished, the project comes to an end.
And maintenance is a very different animal. So the application is handed over to new custodians. Teams are scaled-down, and often pioneers of the application move on to new exciting challenges.
Over time, however, it becomes apparent that the new setup is still expensive. There are quite a few internal developers still involved that could do other things too. The contract with the vendor might seem to have just a few too many hours, whereas this should be feasible with a lower support contract.
The balance shifts. Changes are made to reduce costs and in the end, only a shadow remains of those who were involved in the creation of the application that made all the difference. The custodian prepares the business cases and gets the approvals. And as these make sense, the downscaling happens incrementally over a few cycles. Often, it takes only months, not even a year, for the heroes of the project who made all the difference to be scattered to various organizations in the industry.
This is often where one of two things always happens. (1) There is a new vision, a new ambition based on a changing market (approach) and this requires a whole new setup, or (2) things start to fall apart and need to be patched.
Sound familiar? So who do you call?
The custodian of your software. The same person you have allowed to improve your position by removing ballast from the organization. Ballast with high costs and unclear benefits at that time. But this is the time that you realize that this ballast was also your organizational memory. Because ingrained in the people was the knowledge of how the business worked, how it was translated to this new supporting application and this is exactly what you need for the next cycle.
With the current state of the market, this is an approach and a cycle that companies cannot permit any longer. Innovations and disruptions in the industry are following each other at a rapidly increasing pace, and the people you need to stay at the forefront of what is happening in the market are getting to be very scarce.
It strikes us as odd that most organizations try to deal with this trend by looking outward: scouring the market. Whereas your first action should be to take a good hard look at the people you have and the projects you are running. Who will support your business in the years to come? Who are the current heroes of success? Who represents the organizational memory that you will want to keep in the years to come?
Consistently successful companies can retain and nurture their organizational memory and make a repeatable difference. Enabling them to not only combat the disruptions thrown their way but to ride the waves of change and grab hold of the opportunities that these present. The question we have to answer is, how are these companies nurturing their organizational memory and how can we learn from it?
From our experience, we can elicit four (4) key behaviors that successful companies employ.
If software engineering is key to your organization and is a differentiating factor you should be aware of the above. Don’t forget, it starts with intent. You do not need to make radical changes within the week. Making the intent clear on what you want to achieve with the above behaviors is the first step in getting iterative change. And the great thing is: we are used to this. Years of Scrum and Agile working have prepared us with a skill set that we can apply even at the fringes of software engineering.
So first up: who will be your organizational memory for the years to be?
We'll keep you posted on the latest news, events, and publications.