2019-07-30 Tuesday - Restoring EA Value

Note:
The thoughts in this posting have long simmered in my mind, but were brought to the fore of my thinking today, by this question posed on LinkedIn.

"Why is it that, whilst Google searches for #digitaltransformation have increased in the UK over the last 5 years, Google searches for #enterprisearchitecture have trended in the opposite direction? Has EA become un or under-appreciated? Or its value not understood?"

Photo by Riccardo Annandale on Unsplash

For organizations of a sufficient size, Enterprise Architecture (EA) is an essential part of the IT organization - to ensure that cross-cutting concerns are given the appropriate attention. Teams which are focused on line-of-business, project, or application level  - do not have the latitude (or, luxury) to look left-and-right, nor too far ahead. That's why you need an EA team.

There is great value that EA can bring to organizations - to aid the business in seeking to Accelerate, Innovate, and Elevate

But, sadly, some EA organizations still labor under the baneful delusion (to: credibility, value, engagement)  that their primary mission is to perform centralized governance - and to be a gate keeper against change.  In their mind, they see themselves as a sort of priesthood - holders of arcane knowledge - with a self-appointed sacred role as "Keepers of the One True Way".

In my experience - far too many EA ceremonies and initiatives turn out to be wasteful exercises - that produce marginal value, or none whatsoever. But, in many organizations - for an employee to point out such a thing would be certain career suicide. That's one of the great joys of being a consultant - when teams bring me in, I can help deliver the hard messages, the unvarnished truth, to help effect change with the leadership team...when such news might otherwise create problems for the careers of long-term employees.

Those problematic EA organizations have lost touch with the way that cloud architecture and software development has evolved, and the speed with which business needs to move - and have neglected to incorporate the principles of Agile into Enterprise Architecture as the foundation of their guiding principles.

To restore any sense of value-add, I would submit that Enterprise Architecture must be completely re-imagined.

The fundamental shift that needs to occur is to flip the orientation from reactive engagement (EA waiting to be engaged by the line-of-business on a per project basis) - to one of proactive engagement (EA being the initiator and leader of examination, investigation, research, and recommendations). And, importantly, EA must be empowered with the financial resources to initiate necessary projects.

If your EA initiatives are only funded on a line-of-business project basis - then, you are in a self-defeating cycle of EA failure mode - because you are just a passenger (and you are lucky to be even that) coming along for the ride, with no real power to anticipate and effect change.Which reminds me of a quote I saw posted last year (todo: find source and provide link):

"To be fair, I've seen a few EA teams over the years, that if they had spent their time cleaning the toilets .... they would have made a greater contribution to the organisation."

If an  EA organization were to pivot their mission focus - to providing the business with just three core outcomes/benefits - there is much good that would accrue from that.

In order of priority:

1) Speed. Focus the EA team's efforts on the analysis and re-architecture aspects needed to continually seek ways to accelerate the ability of the business to deliver new and better products/services/features - faster, with greater quality.

2) Efficiency. Focus the EA team's efforts on the analysis and re-architecture aspects needed to eliminate costs and waste - by focusing on the EA level of analysis to help the business streamline systems, interfaces, and processes (with judicious application of automation, and where appropriate - simplifying even the manual processes). This includes involving EA in examining and reviewing the actual DevOps performance of systems - to identify where-and-how waste and inefficiency is occurring - that may be a consequence of enterprise-spanning decisions/considerations.

3) Security. Focus the EA team's efforts on the analysis and re-architecture aspects to ensure that the security of the business is sound - and continually being improved (that includes facilities, network, infrastructure, systems, applications, components, third-party services, tools, data, interfaces, people, processes, and processing). 

When the results of this shift in mission focus are reflected in tangible results for the bottom line of the business, and customer acquisition/retention/satisfaction - then, EA will have a welcome seat at the table (instead of the often seen late-stage invitation to engage EA - as a mere formality, and after-thought).

Indeed, EA will be seen by the business as a true peer and ally - seen as a partner always demonstrating their awareness of the needs and priorities of the business - and deemed a valuable partner in the collaboration.

Over time, an organization's EA team will naturally elaborate beyond just these three - but having this intense focus during the "replanting" of the core EA mission - is necessary to achieve results.

If your EA organization is struggling to demonstrate its value/impact - let's talk - I can be an effective change agent to help you pivot.



2019-08-26:

I happened upon three recent YouTube videos (#1, #2, #3) by Tom Graves, #3 in particular includes a statement in the description - that immediately struck me as problematic - and illustrative of why I believe so many organizations have lost confidence in Enterprise Architecture as a practice - and why heavy-weight frameworks/methodologies such as TOGAF are quickly abandoned by EA teams:

"Enterprise-architecture principles and practice should apply in the same way everywhere, whatever the context or content, whatever the scope or scale"

Perhaps it is just an issue of semantics. But, I think "practice" should be replaced with "concerns". However, after watching video #3 again - I am convinced that Tom's word choice is quite intentional.

This was my reply to Tom's post on LinkedIn today:

"Tom, With all due respect...A minor semantic suggestion: replacing 'practice' with 'concerns' would seem to be more appropriate. Insisting on replicating the same practices, regardless of scale/scope - seems too rigid - and seems to ignore the practical realities of the available economics at different scale/scope."

"Insisting on the creation of all the diagrams/views/artifacts - that are mentioned in the video - regardless of scale/scope - is precisely the reason I think that many business stakeholders have lost faith/trust in EA as a practice - for the failure to adapt to the agile mindset. All of the concerns must be addressed - but insisting on rote repetition of the same practices, regardless of scale/scope, smells like cargo cult science."

2020-05-18:

Much of what is described in this article - is what you should NOT do.