IT Transformation & Enterprise Architecture. What's the Connection?

I recently came across a post by John Palinkas from Castlepointe, Why IT Transformations Fail. This post summarises that to successfully transform IT you need to:

-Have a clear shared vision of the change that is continuously communicated to everyone.
-Ensure understanding and acceptance of the reasons for the change by everyone.
-Create and implement metrics linked to the desired business results.
-Be quick and nimble with interim deliverables that are 80% right

Interestingly or maybe not so surprisingly these behaviours would apply to any transformation project. Additionally I think these behaviours are directly in line with Enterprise Architecture objectives. "So what?" you ask. In many organisations on their Enterprise Architecture journey, the IT shop is seen as imposing Enterprise Architecture upon the business. At a very high level there is some acceptance that IT is needed to enable the business outcomes and an architecture is required to better manage the IT assets. But what this actually means and how to engage across the organisation is a bit of a mystery.

It is expected that the IT shop will get a handle on the technical architecture to drive it from what may have been an piecemeal organic architecture to one which will enable greater flexibility in supporting the business. So there is also acceptance that IT will model the business to demonstrate relationships between IT assets and the business outcomes.

But as you move into information, application and business architecture more and more people across the organisation have needs and opinions. Additionally, the organisation may have continuous improvement processes and EA should work hand in hand with these change programs not as a parallel stream. EA tools and methods may be used in conjunction with the transformation/continuous improvement methods and tools to assist in developing and communicating the shared vision and how activities in the transformation move the organisation towards the vision. The architecture will also assist in defining metrics, which may be more meaningful as they may look across the organisation and pull out previously unknown interdependencies.

Supporting the the last point is probably the most critical and yet for many the most difficult. The architecture team needs to be nimble to keep up with the 80% solutions and the refining their architectures as the transformation progresses. If this is not happening the architecture will quickly be seen as out-dated or simply an after the fact documentation process or even worse an impediment to the transformation, stalling the deliverables because the development of the architecture artefacts is slower than the transformation cycles.

So back to IT transformation and EA, what's the connection? EA practices may be used to support IT transformation. Not just IT transformation in the sense of what IT assets are required to support the outcomes of the transformation, but to work hand in hand with the transformation program and develop dynamic easy to understand artefacts that communicate the vision, tie the vision to the stakeholders view point to give them an understanding of how they impact the vision, interdependencies, identify metrics and the transformation steps.

To me it seems the separation of EA and continuous improvement/transformation programs is counter-productive. As I wrote in a previous post, I believe that EA should facilitate change, not just change in IT assets but business change, otherwise EA will become another stove pipe.