Semprini

Everyone is far too willing to flash them about.

Where is the truth of an organisation? Many programmers would say that the truth is in the code as this is what is actually running the organisation. The code is in effect a realization of business demand and therefore the truth of what an organisation actually is can be found within.

I think that while somewhat accurate, it is a little 'ambulance at the bottom of the cliff' thinking and we should rather strive to be declarative in what the organisation is. Also, assuming we buy for commodity then the view is obscured and incomplete. The declaration of a business is best done via modelling as the related views can inform and align everyone from board to developers.

I must be getting too old for this shit dear reader, and my deteriorating brain must not be able to appreciate the magnificence that is modern corporate IT. Despite my galloping senility, I shall attempt to marshal my outdated thinking on why we often feel like hamsters in a wheel, destined to never actually get anywhere but with ever increasing demand to go faster.

One must occasionally rant. And when that cathartic wave has crashed and some of the built up cynicism washed away, hopefully the receding waters leave a perspective for a pragmatic path forward.

Enterprise architectures should represent the very best of what we can and should strive for, encourage the business and staff to reach higher and push us to see beyond the boundaries and limitations of the current landscape. I guess what it comes down to is that there's good IT and bad IT and we have become overwhelmed by a sales machine - both internal and external, which advertises one but actually delivers the other. Its not a matter of subscribing to the latest method, programme or ethos - it's about understanding the subtle idiosyncrasies and the sympathetic treatment of people, process and technology. Leaning into the complex problems, and sometimes having the courage and integrity to defend work which doesn't have an immediate payoff.

Having systems of record is a widely accepted architectural pattern used to provide clear delineation of responsibilities and guidance to end-to-end solution architectures.

It is an architectural pattern of it's time, suited to an IT landscape of large monolithic applications and was the dominant strategy since the 90s across almost all corporate IT. If this it your IT strategy, you have good governance and patterns for change and an integration architecture which is for keeping these monoliths in-sync then go forth and prosper - you will have mature IT and a reasonable cadence of change.

More likely however, is that significant data is created in what is considered systems of record, half migrated new systems of record plus micro-services and analytic / machine learning flows so the misalignment of systems of record to the business view has become more obvious and material.

There is not a good semantic fit between an applications view of data and the business view of data so lets stop pretending.