Enterprise Transformation

Overview
Transformation seems to be a bit of buzz word these days. I have seen an increase in bids that involve or are centred around transformation. There is much written about transformation that is available on the web and most of it is in the same vein, namely that IT is an enabler and that integration is costly and that SOA provides some way to reduce this cost and so increase the agility of the underlying IT assets. What I want to do is provide more detail on why this is so.

Enterprise Transformation and IT
So what is transformation in an enterprise and IT context.

Transformation at an enterprise level is about process, people and organisational structure. IT is only an enabler, its role is to automate where possible and assist where full automation is not possible.

For transformation to succeed it must have a business context. When we transform we know where we start from and where we need to go to. Transformation is better achieved and returns greater value if it ties return on investment along the way and becomes a programme of many projects that implement the transformation such that it is aligned to business imperatives. If there are no business imperatives that can be articulated then there is no reason to transform.

Enterprises engage on transformational programmes of change because they want to improve their own efficiency and because they wish to re-align their business with, what they see as, future market conditions. Of course the market changes and so the ability to continually adapt to change becomes ever more important to the place an enterprise needs to go. Equally an enterprise notion of efficiency also changes over time. Some processes that previously would be in-house become commodities and can be outsourced. But to achieve this the enterprise needs a framework in which the processes and the IT landscape sit that can support major adaptation.

The people in this transformation, as they have always been, are very flexible. Transformation can be painful but in the grand scheme of things people adapt and perform in line with the business imperatives that drive the transformation. The inhibitor to transformation is more often than not IT. Computer systems and software are not good at adapting to new situations and this is the bigger challenge to any transformation.

At an enterprise level, transformation change requires re-alignment of process, people, organisational structure and supporting IT to business imperatives. It isn’t just about IT, it isn’t just about people, it isn’t just about process or organisational structure. It is about business imperatives, business context and the way in which business goals can be achieved. Processes are simply a way of ensuring that all of the moving parts (people and IT) do what they need to do at the right time. People and organisational structure is about authority and roles to achieve business goals. IT is simply a way to automate and assist people through encoding of some or all of the processes to ensure greater efficiency. Given it is all about business goals and involves all of these moving parts it should come as little surprise that this is what Enterprise Architects do. They don’t do technology, they do transformation.

I've worked on process modelling since the late 1980's. First with Sema Groupe and then with Object Design for IBM on Fidelio (the code name for Flowmark which is now part of Websphere). It because apparent then that business processes would be very important to enterprises as IT became more prevalent in our society. The downside was always the integration of components and not the process topology. Designing a process as a model is the easy bit but enacting it over disparate resources is always the more costly exercise. Those of us that worked on process modelling back in those days knew that integration and reducing its footprint in the equation would always be the holy grail. If we could make the cost of integration low enough and the time taken to integrate short enough then IT would no longer be the impediment.

The role of the Enterprise Architect
Good enterprise architects have an understanding of the technology drivers that enable transformation to be effective and at the same time have an understanding of organisational structure and roles that need to be in place to enact transformation. They don’t have all of the answers but they think at a similar level to a CXO – which is why they often face off to them. They facilitate the reshaping of an organisation, an enterprise if you will, with the CXO driving and the enterprise architect providing grounded forward thinking advice and guidance on how transformation can be supported by IT in an holistic way commensurate with the business goals.

The role of Models, SOA, BPM and Business Rules
Having a good understanding of IT and IT trends in the future is one of the key skills that good enterprise architects bring to the table. The advent of SOA, the resurgence of BPM and the newer resurgence in Business Rules make transformational change much easier to achieve and much easier to drive. SOA cuts the cost of integration to more manageable levels through the use of standards and standards compliant tooling. BPM provides a framework for process encoding that provides the structural clarity of how an enterprise will work (across the IT and people divide). And Business Rules provide the controls for steering the enterprise ship as it sails towards it’s archipelago of business goals.

But of course none of this is any good unless we can capture where we are and where we need to go to. Having a profound understanding of an AS-IS landscape – by which I mean the process, people, organisation structure and IT – is a base for transformation. Such an understanding needs to minimise ambiguity and maximise clarity. Good models become essential. Good models that can be tested become highly valuable and good models that can be reasoned over become a differentiator.

Having that AS-IS state allows the CXO team to better understand where they are and so construct similar models that describe where they want to go.

The journey to a TO-BE landscape cannot always be determined in advance, it is a journey. To be able to flex and adapt the enterprise without being hide-bound by IT enables the CXO to try things out rapidly. In much the same way as we use agile methods to develop solutions in the face of inexact requirements and in much the same way we might use CMMI to drive iterative improvements we can apply the same techniques to the enterprise as a whole and so continually adapt it to improve efficiency and meet business goals.

Where to start
The first step of this journey is to move towards service enabling the enterprise. Capturing the key processes, automating where we can picking low hanging fruit to turn an AS-IS landscape into a more agile AS-IS landscape. Picking the low hanging fruit can often help to pay for the enablement over time. When enough enablement has been done the transformational journey can begin in earnest because at that point enough of the enterprise is flexible and agile enough to be flexed.

A danger in picking low hanging fruit is to silo enterprise transformation thinking. Looking at one process is never sufficient as it does not engender any synergy. So a single process view does little to help transformation. Rather a more global approach is needed. Capturing the AS-IS and then transforming to a TO-BE state over time requires a global model approach which is neutral to the technology and crosses process boundaries. Testable architecture concepts help to capture a global model by documenting an AS-IS (and enabling a journey to a TO-BE state) to be written formally as a collaboration in which processes may collaborate at the top, middle or bottom of the process graphs. This helps to rationalise the IT real-estate and encourages synergy.

Conclusions
Consider the humble Ford car manufacturing plant and the American football team. In the case of the former they can re-purpose a plant to manufacture on car type or another in 24 hours. They have delivered adaptability for their business. In the case of the later they coach has a play book and a set of behaviours (the players). The goal is to win the game and the objective is to make a first down each time or stop the other team or take a field goal. The coach matches behaviours to plays at each stage of the game demonstrating adaptability.

Thus for me the key to enterprise transformation is to free the enterprise from the moribund pace of change of IT through service enablement, focussing on early ROI to justify the enablement and with a longer term vision of CXO’s to have a flexible and adaptable enterprise for the future. This is why global models are important (and so testable architecture given first through CDL tools). This is why SOA is important. This is why BPM is important and this is why Business Rules are important. They all help in enabling adaptability at differing levels of a enterprise, from the top, in the middle and at the bottom.

And finally, the guardians of technology enablement are not the vendors – they have little insight as to how transformations are performed – it rests with the systems integrators leading the industrialisation of IT.


References:

IT for Enterprise Agility

SOA and Large Scale and Complex Enterprise Transformation

BPM is Not the Same as BPR

Building the Agile Enterprise