On a crowded loop station this morning I notice a regular looking middle-class man in his late thirties, standing to the side of the crowd on the station platform, tentatively reaching into the yellow recycle bin to retrieve a mint condition daily newspaper, probably discarded by a fellow traveler minutes earlier. No regular scavenger, his down-turned eyes and the furtiveness of his stance convey a sense of the stigma that society holds for what should be a perfectly rational and sensible act — reusing something that is at hand rather than buying his own.
Software is the fabric of the information age. It is eating the machine age. In the end it might even eat itself! Software is so successful, so pervasive, so adaptable that code, and the ability to code, are devaluing. Software is the commodity of our age and software development the occupation of the new working class.
Enterprise Architects should just get over being precious about software… and architecture, enterprise architecture, strategic planning etc.
Architecture is a metaphor that had relevance when software could be funded and managed like other capital investments. Software — unlike concrete, the fabric of capital investments — never ‘sets’. It is mostly open and freely shared. Software to do just about anything is a few clicks away for everyone with an internet connection.
Software never goes to the presses, to be set in hot metal, to be printed on paper, for all time. When software made large capital investments, Architects were needed to do the ‘town planning’, quality assurance and gate-keeping. Because software was an expensive, proprietary commodity.
Software written today is not quite the same as the software of the big capital projects era. It manipulates components, in frameworks, on platforms, and is just disciplined, structured writing. Like poets, we try hard to write less of it, not more. We no longer measure our worth by ‘Lines of Code per Day’. And if we throw bits away from time to time, we dont fret. Like all good writers, we should be prepared to ‘Kill our Darlings’.
Now that software is a commodity — open, and everywhere, people formerly known as ‘Architects’ (Enterprise or other kinds) have a new role.
Enterprise Architects should support Agilists to deliver services at a rapid rate. The Agilists will accumulate a bit of technical debt in the process. But relentless business demand and change will preserve the Agile capability. Paying down the kind of technical debt that matters will happen.
Enterprise Architects should work out how to influence the demand side (The Business) to drive Agile delivery capabilities to deliver outcomes for clients and customers first. Then indirect customer benefits second (such as business efficiency).
Technical debt minimization is important but it is not Enterprise Architecture’s raison d’être .
My mower broke last time I used it. Payback for all the times I have mistreated it, yanked its handle, tilted it on 2 wheels over a gutter, or banged it roughly into a tree stump. The chassis rusted out where the handle attaches, so much so that the handle on the left side pulled off, taking with it a nicely rectangular chunk of rusted mower. So I did what any self respecting man would do. I left it in the shed and ignored it.
‘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).
For a method that purports to tackle real-world problems, practical examples of systems thinking in action are elusive. Refreshing, then, to read a special edition of the Cornell Policy Review on systems thinking, which presents accounts of the systems thinking craft in a readable and digestible form. In the interests of better policy, Cornell Institute for Public Affairs Fellow Harrison Speck makes some headway in understanding the question of why child protection case workers in Texas do not always stay long in their jobs (paper and video).
Systems thinking is on to something. There’s something there. It harbors truths that conventional business and organisational perspectives miss. It is easy to get this impression from the volumes of social media, literature and management debate it continues to sustain after three decades. But systems thinking as a discipline or body of knowledge does not make it easy to get to those insights and truths. Ways to penetrate the systems thinking morass are neither obvious or accessible.
Even with the best and most complete of models and frameworks, the practice of Enterprise Architecture (EA) in organisations isn’t always effective. Analysis does not always explain everything that happens, and changes that Enterprise Architects (EAs) make do not always deliver the expected benefits. When EA does not deliver value as expected, or when it cannot be represented as a transparent cause and effect relationship, some EA defenders draw our attention to long delays in the enterprise’s adoption of information technology. In light of this, EA should be thought of as an investment against things that might otherwise go wrong — kind of like a ‘flu shot for 2025. Other apologists blame flaws in the EA frameworks and methods used, or in the way that they are used.