Does agility need an old-fashioned, solid, foundation?

Something that was playing in the back of my head this weekend was this concept of Agility.

It’s not a new concept, nor revolutionary, but in thinking about the length of time it often takes to initiate access to (let alone the implementation of) a system or the ability to react to multiple organisational changes brought about by corrections, profit based downsizing, divisional right-sizing, right-shoring or the ever increasing challenge to do more with less … well, suffice to say, the concept of “agile responsiveness” comes up a fair bit.

Once,  economies of scale was all we ever talked about. No matter what it came down to, if we could leverage economies of scale, reduce our ROIC, improve our margins – then it was a simple formula for a stable competitive advantage. When in doubt, stick to a single core competency and scale!

All of that was well and good, and big companies dominated the market. They had huge cost advantages and could lock down distribution channels, suppliers, and other sources of strength … albeit, there was one side effect, being so large and cumbersome, they were slow to react to customer demands and, especially, to market changes.

When a tad more than ten percent of the G1000 from the turn of this century are no longer in existence, and the blame is placed on a string of disruptions that have altered the landscape, one wonders what level of agility is required.

Technological and digital disruptions are no longer the things that affect “traditional” industries.  From watching the Internet become pervasive acquiring mobile devices that connect everywhere, embracing information workers who are always on and utilise their own tools to do corporate work at all times and to embracing cloud-based services and applications to make it all happen – the disruption curve is something all businesses are now forced to ride.

So, corporations are forced to break away from the assumption of [sustainable] competitive advantage and embrace [constantly] adaptable differentiation. We call this developing “an agility advantage”.  Thus, the capability or quality that allows an enterprise to rapidly change, embrace and adapt in response to changes in the technology and market as a matter of routine is what this is all about.

How can an organization anticipate, adapt and respond to whatever complexity the global economy, competition and changing technologies present?

From my view, how do we consulting architects help build a programme of solution[s] to assist an enterprise develop the flexibility to embrace change and thrive in a world where the rules change every day?

There’s a lot of aspects that a corporation needs to modify to be agile. We know that a high degree of organizational agility is required. But do the processes need to change or will the technology be the factor that will initiate the ability react successfully?

It’s a classic “chicken or the egg’ problem – except that the lizard hasn’t yet evolved the feathers …

Without going too far, the problems we can face walking into a client can be seen in almost every organisation. Any  monolithic international corporate entity is one that is likely to suffer from fractured federation (i.e. multiple regions, multiple entities, multiple disciplines). There are inefficiencies in communication and collaboration where sometimes the thumb isn’t even aware of what the index finger is doing to let alone what the other hand is up to.

There are internal [priority & performance] conflicts that are often based on divisional fiscal boundaries and there is an overall marketplace disruption that has the overall entity looking to become a leaner, meaner, and all together keener market force able to negotiate the rapids, the plunges, the tidal waves and the rocks of the bay of enterprise all whilst standing aboard a piece of driftwood that can still support the QE2s shareholder ballroom.

Great, let’s do it! What do we need?

On the one side, we need to be able to react. We need the ability to react like a surfer and twist with the wave – a task far easier accomplished in a small enterprise like a startup, but when your a 2 tonne elephant on a frigate, it takes time (and possibly a tug boat) to make the turn.

So, what happens when you have an Ark? Noah might be in command, but the animals aren’t likely to work together without some sort of certainty over preservation.

So, here we are, an ark, animals wary of each other, a need to avoid the rock reef and a land of opportunity on the other side. Now what?

Believe it or not, this is not unique. I have seen this same scenario in a dozen or so clients. Heck, I’ve seen the same scenario in a dozen workplaces prior to joining an outsourcer. The question still remains the same though: What can an Architect provide to assist the organisation to be more agile?

Twenty years on, I still am not 100% certain there is a single answer to the dilemma. However, as we are often asked to come in and consult from a purely technological perspective, and, frankly, that’s not enough. Yet, we must still offer our advice, and some form of solution.

It is easy to say that a corporation needs to “optimise processes”. Yet, anyone who has ever undertaken a BPM or Organisational Change exercise can attest to the issues involved around such an easily flippant remark.  The complexities can be varied, and sometimes whilst an eWorkflow solution seems like it could provide efficiencies, it may indeed highlight the organisational problems – which often kills such programmes before they are even begun.

So, again, what can we influence? Technologically, we can make impacts on a number of areas. Assuming that the desire and sponsorship is there of course.

Many customers  have an IT geography that matches the aforementioned chaos of the organisation. In a word – islands. This takes the form of multiple applications that oft sit alone upon a stack of isolated platforms and storage and with little or no interaction, let alone data based connectivity, with other application systems.

Whilst on the infrastructure side of the coin, offering standardisations in platforms (be that legacy or cloud-based models) it is only a very small part of the story. Doing so improves the cost and operational base, but does little to address  the real issue – an application island with an information silo.

Organisational change may not be part of the engagement you are on, but there has to be an understanding we bring that is beyond the scope of just being there to change the offering. We need to be walking in with a view of offering insights and challenges to problems they didn’t even know they had. To educate and promote the value in removing or reducing silos.

The integration and automation of fundamental knowledge-sharing processes is key to the base foundations of assisting an organisation become agile. Such integration enables an Architect to utilise IT to advance an organisation by allowing the ability for improved insights and collaboration. Technological advancements to removing the barriers – maybe not of the conflicting departmental goals and priorities – but of the risk aversion that a removal of silo-based information myopia would induce.

Simple technological elements like moving from point-to-point integration through to reusable service and into an Enterprise SOA can liberate the information silos and enable new initiatives to flourish. This can not only improve information access but improve the collaboration inside and outside the enterprise, assisting to better align departmental goals and performance. From an EA perspective, it better feeds into an overall strategic programme.

So, there are two questions I still do not have an answer for:

1. Can a monolithic enterprise truly be agile if they do not build up a baseline foundation to enable it? Without a road mappedprogramme of works to remove information silos? Without an enterprise edict that actively dissuades the building of even more silos inresponse to every rock in the surf?
2. How does one convince a client (be they internal or external) to spend money on initiatives to build the underlying foundations? Especially if (as is oft the case) the works involved (e.g. discovery, dependency matrixes, data cleansing and SOA meta modelling) may not see returns within the quarter or even fiscal year?

If I could answer those questions, then maybe, just maybe, I could answer a whole lot more … including the far more common one IT departments are now asking, like “how do I stem the flow of shadow IT departments?”

So, that’s just one view of the many random thoughts that rattle around the inside of my head.