Reflection: Organising the ABB framework (2) - the two biggest mistakes of all…

…no!

So far, everything I’ve talked about has been “Information Technology” – the automation of Business Processes and digitisation of Business Information.  But how did we know what processes to automate, and which data to digitise?  And how best to do so?

I believe there are two factors still missing – one “horizontal” and one “vertical”

(A) We need a Business centric focus in our Enterprise Architecture!

I’m delighted that, in the last several years, the answer has increasingly become “Business Architecture”:  not just “Business Process Modelling” and “Data Modelling” (which I’d generally refer to as Business Systems Design), but the proper identification of Business level ABBs – with the emphasis squarely and unashamedly on Architecture.  And what do I mean “business level”? - thinking about the business without thought for its implementation in IT.  Things like standard roles in a business, standard activities, or standard ways of representing information.  Even “standard locations” and “standard organisational structures” are powerful, business level building blocks.

But, I am sad to say that in so many organisations Business Architecture (BA) is a distinct and separately organised notion from IT Architecture (ITA), “sitting on top of” and “completely disjoint from” each other.  How can this be sensible?  Surely both are equally critical to the Enterprise’s Architecture!  Only when I can join up the idea of a business’s standard activities (BA) to the corresponding applications (IS Architecture) and underlying infrastructure services (Technology Architecture) can I be sure I’m on the right track.  In some places, it is said “Enterprise Architecture supports Business Architecture” – yugh!  There needs to be a seamless train of thought through the layers, up and down between BA, ISA and TA.

Seamless train of thought, up and down…?  Hold on...

(B) We need to encourage a top to bottom train of thought

(As well as bottom to top!)

There are some Architecture Frameworks that choose to split the IS Architecture layer into two layers, creating a four layer horizontal framework – Business Architecture, Application Architecture, Data Architecture, and Technical(sic) Architecture.  But how do you then join the dots?  

·         If I was an Application Architect, would I not be interested in the vertical dimension “of function” more than anything else?  Understanding activities, then automation of those activities, and then the supporting services needed to keep them going?  

·         If I was a Data (or Information) Architect, would I not be interested most in the entities and data items my enterprise needs, then considering how best to digitise them together with the data management mechanisms I’d need to maintain and protect them?

·         If I was an Organisational Architect, I think my most pressing need would be to understand the roles my enterprise needs, and how to organise them into business units and so on – as well as recognising how some roles might be automated, as well as the human-machine relationship my people will have with IT as they perform their roles.

All of this points, for me, to there being a second vertical dimension to my ABB Framework, cutting down through the levels considering the high cohesion there needs to be between BA, ISA and TA in three areas:  Application Architecture (top to bottom), Information Architecture (top to bottom) and a People centric Architecture.. top to bottom.

Not "layers" - vertical slices of AA, IA and OA through the layers of BA, ISA and TA.

(Later, when I return to those two final shortcomings of the Lego® analogy, I’ll add a couple more vertical slices through this two dimensional framework.)