Is your Architecture Team Stopping Business Innovation?

Paul Ayers, Cloud Enterprise Architect Director, Oracle

Paul Ayers, Cloud Enterprise Architect Director, Oracle

One of the main roles of an architect is to protect the organisations technical eco-system. The main logic behind this important task is to reuse existing technical assets, reduce complexity as well as minimise any costly integration. This all makes perfect sense, of course, but it also comes with a dark side.

In today’s fast moving world, it is more than likely that your organisations current technical environment is not meeting the needs of the business. Now don’t get me wrong, it is extremely challenging to meet the evolving needs of any business. It is also made harder by the fact that the core of most computer systems organisations use today was actually designed decades ago.

The simple truth is that a large percentage of organisations that have been around for any period time are nursing legacy systems and old processes. As a general rule, the older the organisation the more likely it is that processes are problematic. Many government agencies live inside this camp. These systems were developed in a time, where organisational risks were different and the technology less flexible (which sometimes was a good thing!).

It is also highly likely that these processes are not only inefficient and costly but are difficult to change as well. The IT systems supporting these processes will usually mimic their complexity making them inflexible and expensive to change. To top it off, these systems are also usually mission critical for the organisation.

So if the role of an IT Architect is to re-use and ‘protect’ these IT systems, is this just perpetuating current state – a state that is clearly not facilitating business change?

In my job, I often see many opportunities for significant improvements for organisations but am blocked at the pass by well-meaning Architects. The commentary I get back is along the lines of: “we like what we see but it doesn’t fit with our architecture”. In many cases I can’t help but think whether that so-called ‘architecture’ is it leading the organisation down the road to irrelevance.

In a number of cases, this architecture is mapped out in a technical roadmap. These were all the rage a few years ago but I have noticed them becoming less visible in recent times. This maybe because things are changing so quickly that it’s difficult to keep the roadmap up-to-date or is it that the business is doing its own thing anyway regardless of what direction the IT group is rowing?

The simple truth is that a large percentage of organisations that have been around for any period time are nursing legacy systems and old processes

Where there is a technical roadmap laid out, it is well accepted that the role of an Enterprise Architect is to be the gatekeeper. However, what is a little less clear is whose role is it to continue to monitor it to ensure it is aligned with the business? Can the Architect remain objective and also oversight its alignment? I would suggest that goes against human nature as the Architect, who is living and breathing current state, will find it difficult to ‘see the wood over all the trees’! I suspect that there could also be a hint of self-interest in the Architect controlling the plan. Like us all, they need to be seen to be providing value or they would not have a job.

It is no secret that all IT groups are struggling to keep up with the shear rate of change as well as trying to manage all their other business as usual demands. Supporting enterprise class IT systems is hard enough but now they are also trying to support the business on their innovation agenda. We are seeing many cases where the business areas are just by-passing the IT teams in order to get things done.

Two-speed IT has been spouted as the way to best manage this issue. Two-speed IT also called bi-modal or pace-layered IT is a method of calving off a part of the IT team to just focus on innovation using agile approaches and experimentation. I have written my concerns about this approach in previous articles. My issue with it is mainly around the fragmentation of limited IT capability.

However, I keep asking myself what is the risk in trialling a small proof of concept to demonstrate the art of the possible especially in the Public Cloud where it is very quick and cheap to set something up. Would such an experiment really fragment IT, especially if the usual IT resources for building infrastructure were not even required?

I don’t think it would.

I am seeing a growing level of frustration in many organisations with the slow rate of business improvement. This is having a demotivating impact on all staff. By showcasing what can be achieved by the latest iterations of Cloud based software-as-a-service, for example, it may provide a renewed spark and get people excited about the future.

If you are from the business side, you may find this relatively new type of IT capability can present a threat to the IT group therefore will get some push back. Some of these threats are related to the loss of control. You see many traditional IT people struggle to come to terms with not having control anymore. This is not to say you should exclude IT from being involved in such activities. We have seen many examples of business people charging off without any understanding of the technical issues or ramifications of doing certain things so IT does need to be part of the team involved in any showcase.

You may also find that it becomes even more complicated to get a proof of concept activity going when an out-sourced IT provider is involved as vested interest can get in the way.

Overcoming these barriers is not easy and takes courage as well as leadership. However, I have seen a number of these ‘proof of concept’ exercises really pay-off and give organisations the mojo to embark on larger endeavours. The magic pudding is, however, selecting the right activity to showcase.