Tuesday, 1 September 2015

Going Digital & Agile Architecture

Recently, I've been reworking & tightening up some earlier ideas and putting them in a ‘Going Digital’ context. I’m posting them on LinkedIn to reach a slightly different audience.  
Here are the posts so far:

During the process, I’ve been reading/re-reading some great related articles that discuss agile architecture and the need recognise the business as a complex adaptive system. Here are the links with some favourite quotes:

Is Agile killing EA #1?  By Charles Betz "the EA team needs to match the cadence of the Agile teams. This is a central challenge".

Is Agile killing EA #2?  By Jason Bloomberg.

" ...if some company’s EA means nothing more than a lot of paperwork that gets in the way of basic goals like working software that keeps customers happy, then we can only hope Agile drives a nail into that coffin. On the other hand, sometimes the paperwork is a good thing. Only an overly dogmatic reading of the Agile Manifesto would lead one to conclude that we don’t need no stinkin’ documentation".

“Frameworks are cocaine for executives – they give them a huge rush, and then they move to the next framework”.

Enterprise Architecture Finally Crosses the Chasm by Jason Bloomberg including an interview with Adrian Cockcroft formally the Cloud Architect at Netflix. 

“The goal of architecture was to create the right emergent behaviours”.
"..it makes more sense for them to pay most attention to the real-world  ‘wiggliness’ of organisation: the hidden, messy and informal dynamics of everyday human interaction in which they and everyone else are continuously immersed".

With the 'Going Digital' series, my aim is talk about real-world experiences and emerging techniques for doing "agile architecture', or business change design, or whatever it gets called in the future. All I know is that it isn't framework-centric and that many who carry the title Enterprise Architect will have trouble giving up their particular drug of choice! I’m interested to hear what others are doing; what’s working for you - and what doesn’t.

I guess like many of have lived with the 'EA' label, I'm tending to avoid the term, so as not to confuse what I do with the framework-centric, heavy modelling, and 'certified' practices stuff.

Has anyone seen a good job description? :) 

Update Feb 27th, 2017: To see where these thoughts now are going, please take a look at the Found In Design un-book and  the Horses and Unicorns story.


  1. Nigel,

    It seems to me that EA has 'missed' one of the fundamental points that the frameworks started out trying to highlight, that there are different perspectives, in particular static and dynamic. Typically frameworks focus on a snapshot in time, to document either some as-is or desired state. Sure there are dynamic views but they are described at a point in time. As a result the underlying architecture of the Enterprise, the one you manage change around, gets lost in the detail of documenting the 'design' of those points in time.

    For 'EA' to be successful it needs to support the business in charting a course over time, it needs to identify the things that remain relatively stable as well as the target states. The things that are anticipated to remain stable act as pivot points around which change can be managed. Also, importantly, the mechanisms for managing change or transition need to form part of the architecture.

    Examples of what remains relatively stable are the basic 'nouns' of the business and what it does with them (at the highest level) whereas physical processes / workflows change as technology changes. One thing we know for sure is technology will continue to change and evolve, unless a new technology completely displaces a business. Hence defining your architecture around a technology is not a good idea.

    As an aside, but may be an illustration, is this whole notion of Going Digital. I thought Going Digital started in 1951 with LEO, the very first digital business computer. Now if Lyons Tea Houses had employed an'EA'...

    Ultimately, 'EA' needs to step back from the one time project oriented view of the world to one of enabling "Managed Evolution". Is this Agile Architecture?



    P.S. Shameless plug, I discuss some of the principles around using the business / enterprise architecture for managing change in http://www.springer.com/en/book/9783319145709

    1. Adrian, as usual we agree.

      Please don't see my 'Going Digital' tag line as anything other than a journalistic-style attention grabber!! I‘m certainly not promoting it as the centre-of-gravity for architecture! Sometime we just have to use popular parlance to reach different audiences - with the 'Going Digital' series on LinkedIn, the stats tell me I'm reaching a few C-levels and not just Enterprise Architects! Hooray!!

      You’re the only bloke I know who manages to do ‘vanity publishing’ without writing your own book! - That’s what you get for using my blog for a shameless plug! :-D

  2. I'm giving the topic of roles and job descriptions some thought at the moment. Too many are specified in abstract terms that are completely divorced from the real world, such as this one for a Head of Business Architecture in the UK Home Office that I just spotted on LinkedIn
    It seems to be a very IT-oriented role for a Business Architect. There's no sense of how this surprisingly large group is going to improve the performance of HO

  3. This is cropping up for me almost daily at the moment (link for more on this below). I am still a fan of frameworks and methods and they can be used with an agile twist. I think the problem is few architects think about impact and value. The only architecture that really counts is the one that ends up being implemented (probably more accurate to say "emerges"). The rest is just disposable paperwork.