When I posted my previous blog on Aligning ArchiMate to BPMN one of the comments I received read “Agile or die, this is the only fact of today business environment” – and this got me to thinking about Agility in EA.
To be honest, lets start by saying I agree with the comment – and that he gave me no reason to believe the person who posted the comment was misunderstanding anything I said.
But there are those who do…. There’s a stigma sometimes attached to Enterprise Architecture, and architecture as a whole. It’s sometimes seen as slow, synonymous to waterfall, unable to change, and an overhead in general. I will talk about the value of architecture in a separate blog, but suffice to say, architecture doesn’t have to be that way.
Agility in TOGAF
Its fair to say that TOGAF appears to be, or can be fairly document heavy depending on the choices you make in implementing it. A first point to make about TOGAF would be it is a framework that is intended to be tailored to specific needs, and does fit in well with a waterfall development technique; That said it can also provide a good backbone for something more agile.
Everything TOGAF asks for in terms of deliverables within the framework has its purpose. If you take any of those things away you leave a gap or a risk. It’s a comprehensive framework built by many smart people. As a framework it addresses many concerns from different stakeholders.
To be practical you need to think about how to adjust TOGAF. I have sat in a few meetings where we have discussed those different architecture deliverable’s and how we could adapt a Scaled Agile Framework (SAFe) model to work along side TOGAF, giving the strength of TOGAF and the agility of SAFe. It is possible to do so but it requires careful planning & implementation of processes. Processes that are well defined, with good key performance indicators can be very agile.
I firmly believe that good architecture is a key to success in agile ways of working. Agile doesn’t mean we do not do architecture, but it may mean that we do it differently.
If you look at my blog Planning Work With ArchiMate you will see that its possible to use the ArchiMate language to define small building blocks, and then fit them together – each block expressing its own value and interfaces to the world. Although when we use methodologies like SAFe we need to consider the value of each individual work package, we also need to take a longer term strategic perspective. The approach I took in that blog facilitates agile projects as well as waterfall ones.
Change is a constant and enterprise architecture needs to facilitate it; which is another reason why languages such as ArchiMate and BPMN working together in an architecture repository support this.
I will speak at some point about ISO 42010 (I have a video blog planned), the standard for architecture design; how it fits in nicely with ArchiMate as a standard, and how it enables us to design architecture that supports our goals in a focused fashion. Such standards are essential if you are practicing architecture on a large scale. Each piece on a chess board has its purpose, and rules it must follow – each move must be part of a strategy.
It’s a matter of balance. We only want to do enough architecture to provide value; ISO 42010 provides the groundwork for this – when it describes views and view points – and the ArchiMate Language implements those concepts nicely. It takes skilled leadership with skilled architects in order to get this balance right in practice.
It’s essential we have an architecture strategy, and a good set of architecture practices to facilitate an agile way of working. You can’t be agile unless everyone knows what they are doing, how they are doing it and when they are doing it. Knowing why they are doing it can also be helpful. If you don’t have an architecture discipline then in fact architecture can become significantly less agile. To be agile we need competency and discipline; and we need to have an architecture practice, practice practice…. This doesn’t mean the solution is to do more architecture – more it means that we need to do the right architecture.
Summing it up…
Implementing without architecture design exposes all kinds of risks; it may seem that you implement projects faster, but then what you save in project development time, hits you when you get to an operational phase.
If architecture is not facilitating an agile way of working, then that architecture practice probably has a need to change, not to be abandoned. It’s important to have talented architects to lead us and define process that adapts to change. We need to consider process development and architecture with an agile mindset and should be considering how we can deliver continuous value over time as well as how we can do that efficiently. We need to build a layer of motivation architecture that hooks into our Implementation architecture.
To the guy that said “Agile or die, this is the only fact of today business environment”… I couldn’t agree with you more; but I would like to add trying to adapt to change without clear architecture, leaves you at the mercy of the skills and communication of the individuals, and the bigger an organisation you are, the more risky that becomes. So think of it this way:
Agile Architecture or die.