On Stupidity – Outcome Driven Application Architecture

Link: http://www.etc-architect.com/?p=125

From ETC-Architect » Architect Global | Data Architect, Global | Software Architect, Global

I do not know if you still remember 2011 and 2012 when the same analysts that are today preaching on Digitalisation, where going on about Outcome Driven Application Architecture. If it may has slipped your mind let me remind you on the key concept of deliverables in all fields of architecture that need to be measurable, operational, actionable, enabling and favourite diagnostic. Now this movement was a great time for all those that were selling frameworks and other tools focused in that area. 

The problems that some have pointed out in start of that hype were also the same ones that are slowly now killing it. The Outcome Driven Application Architecture for most architects with a good memory started with the SMART methodology that finally got itself into virtually all frameworks.

So where are the flaws? The first is around measurability of architecture. Most initiatives usually started on the AMM which in a customised version of the CMMI for architects that builds on the assumption that architecture is an industrialised process. This key assumption however is the main point of failure as a lot architecture is art. The second problem is that of actionable architecture that drives architecture on a clearly defined roadmap or stakeholder requirement and most will have spotted the stupidity in the words “clearly defined”. Again a wonderful assumption that however has very little in common with reality.

The diagnostic deliverables were those that I personally believed in. These include models, requirements and analysis tools that are designed to enable IT and business leaders to understand the impact of different decisions made in response to business disruption or business opportunity. The flaw in this thinking is much harder to spot and you will only be able able to spot if you know about the inability of hard system thinking in most cooperate settings. I have discussed in some detail in my podcasts where used 10 episodes to explain this. You can find the episodes in the archive.

The final two deliverable are operational and enabling. The main flaw in the operational part is the assumption that architects are disciplined workers that will always keep to the same process disregards of changing circumstances. The enabling deliverable however tops it as it assumes the architect to know more than all the people around him and makes him into a know it all of God like dimension. Some argued that the architect will ONLY have to know all the processes embedded in the organisational matrix making him a kind of chief operation officer (COO), which did not go well as the COO main job is that of personal leadership and the architecture abstraction level is what it says; an abstraction level that will as such only be part of the enablement.

Related Post