Christmas is coming, again. Last year, Australians reportedly spent $A32B at an average of $A1,200 per person during the silly season. Nearly twenty million of these gifts with a value of around $A1B were unwanted and were sold, re-gifted, stored or dumped. For myself, a distinctive marker of post-consumerism came when a ten year-old family member declared a few weeks out from Christmas that he didn’t know what to ask for this year because he couldn’t think of anything he particularly wanted. It seems that between Christmas, birthdays, special days and rewards for good behavior the number of buying opportunities outstrips some family member’s needs or even desires. So it seems we are now living in an age of post-consumerism, even for ten year-olds. We are beyond some western models of growth, in uncharted territory.
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).
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.
Political, social and economic problems amenable to the application of ‘systems thinking‘ are all around us. Take the Australian Prime Minister’s latest solution to the seemingly insoluble ‘boat people’ dilemma. ‘Boat people’ are refugees fleeing central or south east Asia who make their way to Indonesia, purchase passage from a ‘people smuggler’ to Australia on a leaky boat, only to find that the tub starts to take water somewhere near Christmas Island. What typically plays out next is a media-driven frenzy of political posturing and talk-back vitriol, while the Australian Navy scoops up the survivors and deposits them in a remote detention centre.
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.