Have you ever thought about how often the “trends” changes in your organisation? It is fascinating just how fast many organisations jump aboard the newest management hype, be it methods, technologies or organisational frameworks with the promise of solving all the problems we have struggled with for decades.
Not long ago everyone needed an Enterprise Service Bus and an Integration Competency Center making standards for Service Oriented Architecture, a few years later that was all outdated and everyone needed Micro Services, API’s and Data Streaming. Scrum became scaled in one way or another, Lean became the Lean Start-up and merged somehow with the Design Thinkers and Service Designers, while Big Data and Data Warehousing turned into Data Lakes and Data Streaming. Now everyone needs an Artificial Intelligence Capability and perhaps a Robotics Centre of Excellence if they are into quick fixes.
The “old” organisational units that have finally started to get effective on their ways of working and delivery suddenly see themselves fighting for funding and their staff. Who wants automation when they can get artificial intelligence? Who wants heavy service buses and canonical data formats when they can just find everything in the data lake? Who wants to build agile teams and release trains when they can get ChangeLabs, Speed-boats or Moon Shots?
Don’t get us wrong here, these methods, technologies and ways of working can be great in their own rights, and powerful enablers with the proper implementation for the specific organisation. In our point we all too often experience wasted resources, confusion and complexity resulting from wishful thinking without any activation of the organizational memory, without understanding root causes to the existing problems and without proper business implementation.
The same phenomena appear when organisations send of their employees for 2 – 5 days courses in TOGAF, SAFe or some other learn-it-by-the-book certification scheme. The training usually has no or little relation to the organisation’s history, its culture and context. Therefore, the gap from the text book theory and to the reality seems insurmountable for the employees, when they are back at the desk. The result being that the training does not lead to any real change.
Do we ever learn? One would think these large organisations have an unbeatable resistance to mayflies and quackery and know all about proper business implementation. But no. Some of these companies have more than 30 years of added complexity with thousands of systems and almost as many technologies, functions, roles and development- and initiative-models. And still they believe that they can buy a box of magic to make it all go away.
The three of us (the authors) have often found ourselves discussing this “short term memory loss circus” and the tragic consequences it has for the organisations we have been working in and for the people that spend their lives in the ring.
Out of these talks we gradually became more aware of why we reacted as we did. The reason is that we have in various roles and organisations experienced an alternative practice of business development based on a set of values or beliefs that we share. And hence we began actively to explore those beliefs.
This led to the formulation of architecture beliefs which are not yet another technique, process, framework aka silver bullet. Rather it is our beliefs about patterns of actions that in general leads to effective architecture practices. Here we begin explaining these beliefs and how we found that they helped us in our architecture work. In this post we describe the background and the context, while subsequent posts will describe each belief and how it relates to real experiences in the circus ring.
So, let us return to the problems we observed. A typical problem is that several organisational units or projects work on the same or similar business opportunity or problem in their own bubbles. This leads to wasted investments and likely increased total cost of ownership. In the large and medium sized companies we have experienced, the organisation is often complex and lead times on changes in the organisation is long. To overcome some of this, change initiatives (aka transformation programmes) are initiated using agile, lean, design thinking, service design, API enablement, value streams, etc. However, the approach is often to buy a box of magic, and the doers often don’t even understand the methodology they are working with (like the “agile project”, huh?!). These seldom succeed or lead to the expected change, before yet another idea, approach or technology comes along.
For example, a large company decides to implement agile ways of working and does a multi-year agile process implementation for IT teams. The change is done as a transformation project. While it does have an impact for some teams, it mainly focused on agile processes for existing IT teams and thus roles in the rest of the organisation were not included. Lacking the business people in the transformation resulted in a biased approach that could only improve a smaller part of the larger system. The perception was that “this agile thing is for making IT more effective”, so focus was on IT processes missing out on the root cause to be found on the collaboration across IT and business organisations. Additionally, after some years the impact got lost as the teams slowly return to their old ways of working due to thinking about the transformation as a project with a start and end date.
There are likely many reasons to the problems we described – for example how change is funded, how ownership is managed, how KPIs and incentives are defined etc. However, our focus is on how architecture can play an important role in easing some of the pain. We see a need among architects, and those who lead architects, for reminding ourselves that what we can help with is to create a rooted, genuine and sustainable business change. Rather than becoming advisers on the newest trends, we need to take the outset in understanding our business, and we need to build trustful relations based on a purpose-driven architecture practice.
Contrasts this with much of today’s architecture efforts being organised and prioritised in central architecture disciplines as for example business-, solution-, enterprise- information- or technology architecture. These are then anchored in ivory tower architecture principles, gate passing models and “force feeding” industry standards on enterprise level towards business who at best ends up seeing it as an IT initiative. Many of them try to stay under the radar to avoid architecture “help”. This is not evil will or incompetent people, on the contrary – these people are often very intelligent and dedicated. They are front-runners who make a real difference for their users, but the sustainability and scalability is being sacrisfied and the organisation as a whole is growing further into a fragmented and complex state. Our experience is that the management who buy into this approach is guided by an ineffective view of the world.
Our purpose with the beliefs is to provide an alternative world view that for us has been the basis for establishing effective and sustainable architecture practices, each of them different to their context. But the common denominator is that they are all Purpose-Driven.
You can read about the first six beliefs here:
1. Best architectures emerge from interdependent collaboration in cross-functional teams
2. Best architectures are developed iteratively and just enough to guide decisions
4. Best architectures are based on learning from past change initiatives and mistakes
Business culture, you actually touch on the subject business culture here, and it is something that is not addressed in depth by methods and organizational frameworks.
The way a corporation regards its IT department varies wildly, but whether it views IT as an expensive burden that always says no or as something else wont change the fact that business culture and proactive individuals can profoundly impact the IT department in unexpected ways.
Take for example the multitude of smaller “IT departments non-grata” that seems to pop-up in business units as they try to quickfix a problem or optimize a workflow. This is not ill will as you say, but often a result of a proactive individuals, that wants to improve KPI.
Or the business unit that decides to invest in apache hadoop and hive without consulting the IT department first either due to them expecting a slow response or a no, due to different budgets.
The end result in either case, but mainly the last, is that the IT department will end up supporting a technology that was bought by business unit and might be an equivalent to an already existing owned technology.
Hi René
Yes, business culture is definitely a key factor and some of the other beliefs Kalyan, Mogens and I have discussing touches also on business culture in various aspects.
Belief is also about how you think and let the thinking guide your action, which is in my view is the main point.
Thus our 10 beliefs I think can help to create an empathetic, agile and collaborative business culture.