Adapting Enterprise Architecture for Digital Transformations

July 2017

This is the digital era. This is about transforming behaviours and expectations with disruptive business models and technologies. These are challenging times for traditional enterprises as disruption starts from inside the organisation, to build the culture of agility and flexibility so that they can offend (or defend) the market place.

Adapting Agile methods is imperative to provision services fast and respond to continuous wants and needs of the business, hence the (r)evolving market place. While many argue the pros and cons of Agile (that I am following with interest), I will discuss how Enterprise Architecture (EA) should be adapted for organisations embracing Agile development and delivery.

What EA meant to do?

There may be many definitions for EA's mission, with varying activities based on its formation and maturity in a particular organisation, however its meaning should be universal; extract (describe & present) the building blocks of the organisation, by decomposing its business vision and strategy into a structured set of services and capabilities—i.e. the EA view of business, information systems and technology—, and govern changes for their coherent integration to the whole structure.

EA views should be described with the right level of detail, so that complexity of their low level decompositions are hidden—as those are worked by design & engineering teams anyway. The aim here should be to facilitate tactical and strategic decision making consistently, and promote reuse of building blocks by making them visible and understood by a variety of stakeholders across the organisation. EA also manages progress towards the target state by tracing strategy and vision of the enterprise, and aligning technology investments accordingly.

The EA Dictatorship

EA tends to be well organised and consistent as per its mission. In contrast, Agile tends to respond to change rapidly without elaborate analysis for consistency and coherency of the enterprise services portfolio. This is usually an accepted trade-off in the digital era where risk appetite is higher and strategy is volatile.

Agile might argue that EA slows delivery down with its elaborated modelling and description efforts for services and capabilities (i.e. architecture development). It is usually a debate if holistic (enterprise level) analysis and strategic thinking is a necessity (of value) in a dynamically changing environment. Agile might also suffer from heavy governance from EA, as they aim to make opportunistic decisions for rapid delivery of a product without much debate of its coherent integration to the portfolio of enterprise services. Eventually, EA struggles to catch up with the speed of activities and lack context due to its limited resources or limited cooperation from Agile teams.

This is a lose-lose situation as EA artefacts become obsolete quickly, therefore less valued by its consumers, while EA is still trying to govern work streams without quality baselines. Conflicts escalate into political fights and ultimately EA blocks or slows Agile down as much as its authority allows.

The Agile Chaos

Consistency and coherency is apparently ranked lower in the priority list of Agile. The focus is to deliver a product rapidly to solve an individual problem, and incrementally evolve the product as per feedback. Developing EA views are considered superfluous here due to rapid change of building blocks. As a result, EA's governance naturally lose its foundation without defined baselines. Agile usually seek autonomy here so that they can proceed freely (and rapidly) as discussed above. The result is the lack of EA views, therefore lack of visibility and understanding at the enterprise level.

Once Agile products pile up, inter-dependencies and coordination issues arise. Opportunistic decisions are no longer easy to make as foundational information is rarely presented in a structure. Key people move jobs and knowledge flows are likely interrupted. Eventually, products and teams are isolated in the large technology portfolio of the enterprise, causing well known problems of inconsistency, inefficiency, redundancy and cost.

The Solution

This is the exact reason for EA's existence; to connect work streams together, make services and capabilities visible and understood by stakeholders so that they can make better decisions. The problem is the potential overhead caused by this activity. EA is a strategic exercise and value realization may not be immediate.

Many suggest reducing EA governance and federating architecture responsibility to Agile teams as a quick resolution. This approach reduces EA oversight and allows Agile teams make decisions themselves as per architecture principles advised by EA. This should not necessarily conflict with EA's initial mission if it has been implemented correctly in the first place.

Efforts typically focus on fixing the EA governance process as the source of the problem however it is the lack of quality baselines (EA views) causing governance activities cumbersome and decision making difficult. It is crucial to continue creating EA views (architecture development) with the right level of detail and quality in parallel to Agile delivery efforts.

The relationship between EA with Agile must be well organised based on common interests so that teams collaborate efficiently and activities deliver real value. Here are some suggestions for EA to adapt its practice;
  • Have a concise Reference Model emphasizing headlines of reusable services and capabilities. The Reference Model forms the foundation for development of artefacts in a consistent structure, by delivering a taxonomy of concepts and a common vocabulary for services and capabilities. An example model I created for cyber security architecture can be seen here.
  • Enable building blocks (services & capabilities) developed thru reference implementations abstracted into EA views. This is in oppose to the traditional top-down mandate of EA directing projects for design decisions. Information flow is allowed bidirectionally here as Agile teams may bring SME knowledge, experience and innovation to the EA community and may influence strategy and vision of the enterprise (bottom-up).
  • Classify EA engagements, for the proposed changes to the portfolio, based on their impact, value (reusability), complexity, and risk introduced to the architecture of the enterprise. Tailor EA engagements (development and governance) as per the classification scheme, e.g., abstract EA views and reduce governance if value (reusability) is less.
  • Negotiate with key stakeholders (i.e. the process makers for Agile and others) for the level of detail to be captured within EA views. EA should avoid creating too much detail, as this conflicts its principles (e.g. abstract, hide complexity), and may cause redundant work that is already being carried out elsewhere. EA just need to capture information, abstract & present that in line with its Reference Model, and propogate across the organisation, either top-down or bottom-up.
  • Abstract even further if EA resources are exhausted, timelines are tight, or services are packaged and delivered by external partners that hide the technologies and processes involved. This implies federated responsibility with other teams as EA delegates creation of specilized views to individual work streams. Regardless, I tend to create architecture descriptions (EA views) even if they are highly abstracted.
  • Be Agile friendly by using its language and tools as appropriate, e.g, issue tracking or user story writing via Agile development tools.
This list may get longer as the practices mature. EA's mission is legitimate as much as Agile's and they need to find common ground for ultimate success of the digital transformation for the organisation. Practice developers just need to observe their missions and continuously look for pragmatic methods to collaborate with others, so that they can accomplish their mission.