Enterprise Architects should just get over being precious about software

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 .

Advertisements

Why is the perfectly sensible reuse and repurposing of everyday things stigmatised?

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.

Commuters on a train, 1955, before smartphones (Getty images).

Continue reading

Review: Turning Over Turnover: Thinking Systemically about Worker Retention in Texas’ Child Protective Services

Child protection

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).

Continue reading

How do you penetrate the Systems Thinking morass?

morass

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.

Continue reading

The ‘Systems-Thinking’ Enterprise Architect

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.

Continue reading

‘Nounification’ catches up with Systems Thinking

It seems that certain verbs are becoming nouns, for no particular reason that I can see based in grammar, semantics or the logic of language.  This appears to be a recent phenomena, and in a few cases, nounification has propelled these lucky  innocuous verbs into the noun stratosphere.  The first is the innocent little doer-word ‘reveal’.

reveal1
rɪˈviːl/
verb
1.
make (previously unknown or secret information) known to others.

Continue reading

Slipping the noose on IT project benefits

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.

Continue reading