Architecture also drives change

So far, everything I've said about architecture has been in the context of design, with ABBs and reference architectures providing guidance (hopefully best practice guidance!) to teams of solution designers.

And, if we're thinking about an enterprise's architecture, the fact that these designers are using a common set of ABBs and RAs should then give everyone greater confidence that their enterprise's Infomation Systems (IS) will work together, using a well engineered underlying technology infrastructure.

But how did the enterprise know what systems needed to be designed?  What new applications are needed? Infrastructure replacing? Old systems switching off?  The trite answer was in an earlier post - Business Architecture!

But in and of itself, BA is not "the requirement" to which ISA is "the solution". Architecture (ABBs and RAs, whether they be BA ABBs or ISA RAs) describe a landscape, they are not a (or the) journey over that landscape.  So what journeys (investments) should we make across that landscape?

Enter the well defined but often dreadfully misunderstood notion of Enterprise Architecture.  Not an enterprise's architecture (that's of course part of it), but "Enterprise Architecture" (EA).  EA is about two fundamentally different but heavily interlocked things - more powerfully described as its two value propositions (VPs); each of which is aimed at a different set of stakeholders.

BTW, I am sure it's a failure to embrace both of these VPs, understanding whay each set of stakeholders need from there enterprise's EA that is so often the root cause of EAs failure to deliver what, in every other industry is seen as the blindingly obvious.

 

VP #1: Doing things right

This is everything I have discussed so far, applied at the scale of an enterprise. It's about ABBs and RAs being used to guide and then govern (govern? Not said anything about that yet!) solution designs created by "semi-autonomous" programmes... Hold on, what on earth is "semi-autonymous"?  In any corporate enterprise, at any given moment, there will be several or even many separate programmes, all largely oblivious of each other and focused on "their" new or replacement IT or business system. "Of course my system will fit in! It's really well designed!!". Yeh, right, it might be a good design, but is it compatible with the wider enterprise?  Only of it uses the enterprises ABBs and RAs!

I characterise this VP as "Downstream EA", because its value proposition kicks in at or after a change programme has been funded and "real design" begins.  Its primary stakeholders - those who should exploit this VP of EA, are Programme Sponsors and Solution Designers.

 

VP #2: Doing the right things

This is EA's "Upstream" value proposition, of value to those trying to work out which programmes to fund (generally refered to as EA's "Transition Planning" capability) - i.e Business and IT Strategists and Consultants.  Critically, they use (the same!) ABB Framework and other EA artifacts to assess which building blocks are critical to the enterprise's future, which ones should be done away with or outsourced, and which ones are needed "to keep the lights on".  And, equally, what are the strategic or tactical implementations of those ABBs, and which implementations should be removed or replaced.

So "Upstream EA" is about working out where the enterprise needs to spend its IT investment budget next year - analysing the gaps and planning for transition from the "as is" business and IT estate to an aspirational "to be" state.

Of course, as well as understanding the benefits of various Transition Initiatives, there is a need to understand the costs - which generally needs some form of outline design performing before the initiative can be costed, approved and hopefully become a planned programme.  I trust you will not be surprised to hear me call this "Enterprise Scale Solution Design"... design probably done by Enterprise Architects in the role of solution designers.  It is NOT, as many would suggest, "an Enterprise Architecture"!!!

This VP's primary stake holders (although they probably don't know it) are not just Strategists and Consultants - as with the downstream VP, "those that do" need to be sponsored to ensure their work is valued:  in this case it's not a Programme Executive - he or she has a selfish focus on their Solution Design,  It is the enterprise's CxOs: the executives responsible for ensuring the enterprise as a whole is successful, and that no one all-powerful  business unit or business line get's its own way.

"Although they... don't know it"?  Eh?  Can you imagine the board of a high tech eeroengine company not knowing their enterprise has a sound understanding of the architecture and design of three spool, high bypass ratio turbofans, and that deviation from that might be a good idea in isolation ,but scarily risky for the enterprise as a whole? So how can the board of a financial institution "not care" about the current and future architecture of their banking systems?  It beats me, but it's true...

Finally, I am happy to acknowledge that the blended term "Enterprise Architecture - helping enterprises do the right things right" was created while I was employed by IBM, and is therefore their copyright.