Sunday, October 12, 2014

Six keys to EA success


I recently read the six hereries for EA (www,eight2late.wordpress.com/2014/10/08/six-heresies-for-enterprise-architecture/). My thoughts follow

Distinguish between planning and design - The "self-referential" problems of EA extend past the frameworks to the practice and practitioners. This is because most of the have a background in engineering rather than planning (or architecture for that matter). By in large engineers create designs for engineers i.e. design practice to an extent is intrinsically self-referential. Plans are created for a broader audience.

Only consumption of a plan leads to value - The reason EA "rarely leads to anything of genuine business value" - is because too attention is paid to how the information can be consumed, acted on, etc - and the failure to realises the artefacts are not where the value lies.

Accretional rather than agile - What is required is an accretional approach. That is to say an approach where knowledge accrets. This is incremental, but has a different ethos to agile as applied in SW engineering i.e. where knowledge is transactional, transitory and related to a specific individual or outcome.

Virtuous feedback cycles - Planning assumptions and decision need constant testing and refinement. EA at present is too much like riding a bike, in a business city, with your eyes closed. You know where you want to get to and think you want know the direction. You close your eyes and take off. What you need to do is constantly assess knew information and adjust. The only way to get knew information is to apply the information you have, and this way have it tested and corrected. (see: www.enterprisesto.blogspot.com/2010/05/virtuous-circles-of-strategy.html)

Problem finding rather than problem solving - is great advice, but it is challenge for many who have a legacy as engineers or designers and secretly yearn to return to the comforting and satisfying realm of design i.e. solving problems.

Understand the social implications - is good advice, because the most of the impediments to EA are organisation and structural. (see www.ea-in-anz.blogspot.com/2008/07/focus-on-ea-is-inversing-proportional.html)

Thursday, October 2, 2014

Demand and Requirements Management for Business Transformation


Demand and Requirements Management for Business Transformation


  • the information relating to things in light blue stuff, at the top, are basically recorded in business architectures and asset portfolios solutions (i.e. they are canonical enterprise wide source)
  • most of the money is spent on the green stuff - with the hope that it affects positively the light blue stuff
  • sadly there is usually a disconnect between the light blue green 
    • what purports to be the connections are created by lots of "consultants", "business analysts", etc. who create a plethora of persuasive, convenient, documents and presentations (essentially disconnected from the facts). 
    • this disconnect militates against the real world value of business architectures and asset portfolios (which is why they are often rightly seen as ivory tower or academic exercises).
    • that is to say that strangely in in most organisatons there is no source of record (canonical, complete or connected) for the darker blue boxes? 
  • for most business the orange stuff is a necessary evil yet
    • the approach to requirements is driven from engineer needs in the bottom right hand corner (on essentially a waterfall model)
  • in an agile approach, which the only thing that can work, the information flows both ways
    • (which is why the blue arrows go both ways i.e. as you define requirements in the context of existing views of capabilities and systems (i.e. business operational procedures, business assets etc.)
    • you will discover things that are missing or need to be updated - which is good. That is because when you data you find issues with it and you improve it (this is what makes it non-ivory tower). 
    • If you don't use the data in the business architectures and asset portfolios to actually make the changes happen who really cares about it - other than a few planners or startegists (when in reality it needs to be at the heart of business transformation)