‘Shadow IT‘ is a term used to describe information systems and solutions built and used inside organisations without explicit organisational approval. Cloud services, mobility and ‘Bring Your Own Device’ are driving an explosion in Shadow IT. Shadow IT, like shadow finance and shadow economy suggests noncompliance and illegality. Unlike the black market, shadow technology notionally unleashes immediate benefits but harbours a latent potential to damage its host. Quantifying the risk, and getting sufficient attention to do something about it, is the issue.
Technology departments have tried to ‘reign in’ these rogues using the frameworks and processes of Enterprise Architecture, without much success. One reason for the partial failure is that Enterprise Architects have a propensity to focus on risk management, standards compliance and centralised governance. This narrow ‘old-school’ focus locks them to the core, not the edge of the business where innovation happens. Meanwhile, the business units, driven by digital demand and unaided by their IT counterparts, have initiated their own innovation platforms. That’s the line taken by Dean Gardiner from Dell Australia in his paper at the Australian Enterprise Architecture Conference (Sydney, October 2015).
Every business case for a new IT system must identify and argue for resulting benefits. Benefits management is a well-established competency for ensuring benefits are identified, quantified, tracked and realised. Realised benefits justify the initial investment. Victoria’s State Treasury, which funds some very large IT projects, including a number that have gone off the rails has started providing much-needed guidance on identifying and planning for anticipated system benefits. In light of continuing problems with large public sector IT projects (Queensland Health payroll system, Victoria’s licensing system) this is important capability-building.
Enterprise software vendors would have us believe that enterprises are flocking to The Cloud, meaning they are subscribing to remotely hosted utility systems and services rather than licensing and hosting them on premise. The oft-claimed benefits are efficiency (only pay for what you use), simplicity (no more on-premise software) and agility (the software utility can be configured at any time to release new capabilities).
Vitruvian canon, re-interpreted by Robert Venturi for the Functionalists (from ‘Learning from Las Vegas’).
I had the opportunity to attend the First Australian Enterprise Architecture Conference, 19th and 20th November 2013, at the iconic Melbourne Cricket Ground. The conference wrapped up with the traditional panel of luminaries. The session touched on some of the recurring themes and topics of the two days – enterprise architecture definitions, identity, what we are, what we do, what we don’t do, frameworks versus ontology, methods and pitfalls, value propositions and rationale.
As it happened, I got to ask the final question of the conference. The following is an improved, expanded and referenced version of the challenge I put to John Zachman and a number of EA practitioners and consultants.
Pallab Saha’s book on systemic perspectives for managing complexity with enterprise architecture is now officially published by IGI Global. I have written Chapter 13, ‘Enterprise Architecture’s Identity Crisis: New Approaches to Complexity for a Maturing Discipline’. The 18 month process was a reminder of the creation cycle times for this type of content. It seems that social media’s immediacy has done little to escalate the pace or compress the effort of producing a traditional academic work of 26 authors.
When I first started collecting thoughts and materials on what I began to understand as enterprise architecture’s ‘identity crisis’, I was reacting to my perception that IT-centric EA was increasingly facing a crisis of relevance. My experience of the unrealised promise of EA led me to think and discuss questions of theory, practice and purpose. ‘Identity crisis’ seemed an appropriate metaphor for the challenges facing enterprise architecture.
It is time we started talking about IT and business in terms of symbiosis, not alignment.
Symbiosis in nature’s design.
Over at Doug Newdick’s blog a discussion is running on the overuse of the word ‘alignment’ by enterprise architects. Chasing alignment, he says, simply ensures that what people are doing in the name of enterprise architecture does not undermine the higher level business objectives. While not violating business objectives is clearly non-negotiable, it should not be the main game for architects. If it is, the architecture will likely undershoot its potential by a significant distance.