So, we're been talking about adding agility to Enterprise Architecture (lets call its AgileEA). But the problem is this; how can this be achieved without simply taking the current practices and making them more agile? Or to put it another way, does the current way we think about and execute EA (a la TOGAF-esque) simply need an agile veneer? Making the modelling a little more "white-boardy"; using stories rather than principles and enterprise requirement; managing a program through Kanban rather than using the TOGAF ADM.
Well?
No!
I think we have a fundamental set of problems that come from the "big frameworks" we try to implement. These problems represent a gap between contemporary organisational structures and traditional EA frameworks. Given that frameworks, like TOGAF, have come from top-down government-centric (military) environments it is probably not a surprise that they might not be suitable for all industries. There is also, I'm sure, a wealth of empirical evidence that must increasing the noise levels about the lack of EA success. From an agile and methodological perspective, EA frameworks are the waterfall equivalents in software engineering. That is probably enough to consider "refactoring". But maybe there is something more about EA practices; about the fundamental structure of EA, that could be more worrying.
Let’s consider some of the possible problematisations; why should EA have the vision of a "thousand plateaus" while it can't even attain one!
No process works in the particular. Frameworks are designed as a "view from nowhere" which is impossible; more likely it is a view from some organisational context that in no way reflects our context; why then do we follow them so slavishly?
Arcane and obtuse. Disciplines close down though complicated and uninterpretable language that lets no outsider in and EA is full of it; this closing down results in a mystical envelope that can not be understood except by the priests but must be followed.
The Idea of the End State. EA simplifies the temporal aspects of the organisation to 3 points, current near future, and end state; this is a conceptual model that can never hold up no matter how hard we plan or control.
Stone Tablets. EA is a stone tablet generating discipline; they are already out of date once carved; they are hard to pass around; if they are not an end in themselves, what then should have been created; this is the Irony Tower that that is now part of EA language.
Conspicuous Consumption. Weight of documentation is privileged over the execution of the plan; whilst some descriptions are likely to be necessary, action should be privileged over description.
Endless catchup. The cyclic idea of the TOGAF ADM is a symptom of its problems; by the time migration is complete a new alignment is necessary; this appears to be a built-in failure mode.
The Mismatch of the technical event horizon. Technology change does not move at the pace of EA alignment programs; this is not to say that change must be blindly followed, rather that the EA standardisation needs to work in advance of technology evolution, but isn't able to.
Documentation verses Experience; the act of documentation is one of recording/describing, not one of discovery; the discovery having already been achieved before the first mark is made.
The Myth of the Model. An organisation can not be modelled; rather any model must be an imperfect representation based on what it must leave out and the defects in its notation; that is not to say we shouldn't model (for this is what the entire IT discipline sets down) rather that we should model to mirror reality or to constantly repeat ourselves in different notations, but rather to aid in the conversation.
EA can not be rationalised; it is people-centric and therefore irrational.
If we are to deconstruct everything, what than can be rebuild upon? The answer is nothing of the same; it is not yet another set of structures that have their basis in simply a better mouse trap. The idea of enterprise planning of technology is a myth driven deep into the rationalising structures of our cultural business discourse; more so since that discourse is provided to us by knowledge and disciplines handed down from the Olympian Gods with MBAs and a stake in controlling capital. But control is illusory; indeed it is simply convenient to attribute success to a governing hand only after the fact.
So, what we might need is a new discourse, a new way of setting out the structures whilst reserving the right to change and destroy our edifice way before its doom is noticed. This is not to say that organisations should discard EA to following a new drum; rather that for those where its controlling influence is more of an irritation there might be another as-yet marginal set of practices that may work instead of walking to the foot the hills of Olympus.
Lets consider, then, what we might not be able to deny (at least not yet).
There will be technology change; and it will press into being possibilities.
There will be some combination of technologies and information processing that will be "said" to define the organisation.
Information systems and technologies that make sure an difference will not be able to be planned up front nor measured afterwards.
Best-Practice = Convention following.
Practices that embrace change offer possibilities not usually afforded.
Planning will result in a different outcome than organic change.
So, this is simply a preliminary indication of possible agileEA tendrils. A roughly worn critique of possible fissures in the current EA practices that might open up possibilities for a new discourse that we can call, temporarily at least, AgileEA. I think that should this deconstruction prove less than effective, we will be led to the conclusion that EA just simply needs to be made better; and in our industry "making better" is a process of executing control more thoroughly. This would be a shame.