Agile v Business Architecture?

I was developing some training modules in AGILE the other week and happened to take a call from an old colleague who leads a technical innovation organisation. We discussed what I was working on and he remarked

“What is a business architect person doing working in AGILE, I thought Business Architecture was all about old school waterfall”.

To be honest I was a bit shocked as I hadn’t really thought about business architecture being slated for being non AGILE, but on reflection I can see why some people might think that. Holistic up front design with baselining and updating and documentation – umm potential inventory and over processing waste there – so I can see his point.

To add to this, I keep reading posts saying that Enterprise Architecture (EA) is dead or dying and I suppose this could be another symptom of this thinking; there was an article yesterday that companies were laying off business analysts due to the move to AGILE too. So is good business design practice in tension with AGILE approaches?

Probably if we approach design and business modelling in a 100% way then the challenge is valid, but in contrast if you don’t know the overall destination and communicate then you are just making things up as you go along. This potentially creates a fragmented mess.

Enterprise Architecture (EA) approaches, I’m talking Enterprise I.T. Architecture here, with their methods like TOGAF and software tools used for modelling seem to demand holistic work. They are intense approaches, requiring full descriptions showing how everything connects up to everything – across the enterprise. Tools themselves take on a life of their own absorbing more and more effort with some individuals entirely evolving their career around one tool or another and I cannot see an AGILE purist warming to this.

Like a lot of things in life the decision or approach is not binary, the truth lies somewhere in the middle. People prefer to be binary because it is easier on the head to join one club or the other. It is a lot easier from an architectural point of view to use traditional stages of design, build and implementation. Most of the project management best practices work well with this approach and it is highly comfortable. However, this approach is lengthy, costly and to cap it all, by the time you get to implementation these days the world has moved on; you potentially have the wrong solution because your speed to change is so poor.

Where does the somewhere in the middle leave us? The aim needs to be a compromise between doing too much up front wasteful design work, against allowing the organisation to morph to chaos and complexity through a series of self-governing iterations.

Many organisations have recognised this and put programme governance in as part of their AGILE framework, in lean terms this is “essential non value added” activity i.e. stuff you would prefer not to do but is necessary. The use of investment backlogs prioritise programme level items, which in turn get broken down into: feature/capability,epics and finally story backlogs. These items get dropped into SCRUM or Kanban teams. The AGILE purist will perhaps shudder in horror at this potential corporate overhead, but we did say we need a compromise.

Business architecture itself needs to compromise as many of us historically have preached central top down architectural control. On reflection modelling should be about modelling to the goals and needs of stakeholders, not to the needs of the profession doing the work. We need to provide enough design to inform rapid and frequent delivery of value. Through using layers and appropriate models; we need to be prepared to stop and only do work when the business pulls that work rather than pushing the work with our innate desire to draw and record everything.

Our tool vendors need to help us here and give us tools that allow flexible meta-modal design based on configurable themes, layered approaches and partial modelling rather than methodology driven bottom up paradigms.

Ironically one of the earlier AGILE approaches DSDM, which is a lot less common today than it used to be in the late nineties, had a “business study” as an initial phase prior to its functional, build and deployment iterations so this thinking based on compromise isn’t new. If you remember the old “Cheese and Pizza Diagram then you will know what I mean.

Like it or not, I think we are moving into a new phase in business architecture as AGILE gains further traction, and we need to respond in a constructive way if we are not to “throw the baby out with the bath water”.

4 thoughts on “Agile v Business Architecture?”

  1. I know this web site offers quality depending content and other material, is
    there any other site which gives these information in quality?

  2. What’s up i am kavin, its my first occasion to commenting anywhere, when i read this piece of writing i
    thought i could also create comment due to this sensible post.

Leave a Reply

Your email address will not be published. Required fields are marked *