Agile Enterprise Architecture

#enterprisearchitecture #agile #strategy

Agile (source: Merriam-Webster):

1. Marked by ready ability to move with quick easy grace
2. Having a quick resourceful and adaptable character

Strategy vs. Agility

Lately, there has been a fair amount of discussion around making Enterprise Architecture (EA) agile in the organization. Several motivators have been described to justify the reason for implementing an agile version of EA. These motivators include, but are not limited to:

• The imperative need of an organization to constantly reinvent itself in the marketplace driven by intense competition, and to gain and sustain its competitive edge in the marketplace
• Rapidly changing business models that are largely triggered by shifting customer behaviors, customer preferences, and customer churn
• Changes in the technology landscape and the rise of software solutions that can play a significant role in the very survival of an organization

The role of EA traditionally has been one of a strategic endeavor to help the organization anticipate large-scale change that can impact the organization’s revenue and profit margin, to plan for, and implement new (or modified) business & technology capabilities that can address?the change effectively.

The struggle here is in reconciling the strategic nature of EA with the agile needs that the organization impinges upon EA as a practice. Strategy, by definition, is meant to define a business vision followed by a set of goals, objectives and roadmaps that chart out the organization’s path?towards realizing the vision in the medium- to long-term time horizon. Strategies necessarily do take time to develop and need to be vetted thoroughly with the organization’s principal stakeholders, internal and external, before being accepted across the organization (and its partners).

Per the above definition for agile, we would expect an agile EA practice to respond to and quickly meet organizational needs as and when they arise, and do so gracefully, cost–effectively, and most importantly, NOT working against the larger strategic goals of the enterprise! And yes, one would expect agile EA to be innovative as well, to be resourceful and adaptable in character. A pretty tall order for any practice that operates at the enterprise level, one must concede!

So perhaps a more nuanced view of agility is called for when it comes to EA, primarily in order to alleviate the friction caused by seemingly opposing forces of tension between strategy and agility.?This is essential towards determining how EA can be made agile in organizations (especially the larger ones where agility is arguably an even greater challenge), and while preserving the strategic value of EA.

There are at least two aspects of EA that one can apply the lens of agility on: the Operational aspect, and the Decisioning aspect.

The Operational aspect is about running the EA practice in an organization and as such will include concerns related to the organizational structure of EA, roles and responsibilities, EA governance processes, and integration with downstream solution architecture and delivery teams (e.g. DevOps).

The Decisioning aspect pertains to the value proposition of EA i.e., what actionable?insights?can the organization expect EA to deliver that can in turn help the organization make sound strategic decisions? Clearly, the value needs to be delivered on an ongoing basis, and must adapt to changing business needs. Agility is definitely a key requirement here.

Operational Agility

From an Operational perspective, we are generally used to thinking of a centralized EA function that has the task of interfacing with the business and IT partners as part of its day-to-day activities. Instead, in an agile mode, the EA function may be thought of more as a Hub-and-Spoke model (see figure below) where the Hub is the central EA body, but it interfaces with one or more satellite EA bodies (Spokes). The Spokes are embedded in the various business units (or business domains or lines-of-businesses within a larger corporation), and are designed to operate in a pseudo-autonomous manner. One may also think of this as a federated EA organization where the federation is held together by a central authority. Indeed, this concept is not exactly new –TOGAF has a similar concept called Architecture Partitioning that essentially targets the same objective, and describes an approach to define the partitions (or groupings). Business domains, business units or lines of business may all be seen as examples of partitions in this context.

In a model such as this one, the Hub may be responsible for defining & managing EA technology standards and best practices, enterprise-level reference architectures for data, platforms and technologies, high-level EA patterns, principles and metrics. All of these are disseminated to the individual Spokes for use within the business units.

The Spoke on the other hand can define and manage business value streams, business processes, business capabilities, business services, data, metrics, and other similar elements that are specific to the business unit (or business domain or line of business) that it is embedded in. In the article by Jason Bloomberg, Adrian Cockcroft who was formerly the Cloud Architect at Netflix, talks about the desire of organizations to make their OODA (observe, orient, decide, and act) loops for product development faster. This objective of OODA is realized within each Spoke based on the local requirements of the business unit, while (re)using certain relevant enterprise-level EA capabilities, standards, etc. locally. The Spokes may even make decisions related to technology platforms and applications where necessary and relevant to the business units. Such decisions may be later reconciled with the standards maintained and published by the Hub.

While the Hub may have adopted a certain industry-standard EA framework or methodology to do EA, the Spokes have the freedom to customize the EA methodology to suit their specific needs, but at the same time preserving the overall integrity of the methodology. This will necessarily be a shared responsibility between the Hub and the Spokes. Both the Hub and the Spokes are staffed with enterprise architects who may be rotated periodically across the Hub and the different Spokes. Also, where it makes sense, a single Spoke may represent a combination of two or more business units (or business domains or lines of business).

The crucial point here is that the Spoke need not approach the Hub to get a review and approval of every new or modified EA element. Instead, reconciliation of EA elements between the Spoke and the Hub may be deferred to a later point in time – perhaps as part of the organization’s annual (or bi-annual) EA release schedule, and consequently an updated view of the enterprise is published in the enterprise EA repository. Finally, the Spoke is meant to be a self-contained EA unit of operation that closely works with the subset of DevOps that is assigned to a given business unit and is tasked with realizing and deploying the architectures as software solutions. This collaboration, by the way, is very important towards creating a seamless and agile path from enterprise strategy to architecture to execution.

The Hub-and-Spoke model banks on the idea that not all business units or lines of business need to operate at the same level of agility. Sales/marketing, customer assurance, customer experience, service delivery, partner management and other such customer- or partner-facing functions need to be more agile and sensitive to emerging business needs than say HR, finance, etc. This permits the Spokes to operate at a pace that is most desirable for each business unit rather than being dictated to by a central Hub.

Towards addressing synergies and dependencies across Spokes, clear lines of communication and collaboration across the Hub and the Spokes is obviously essential to make the model work.

The Hub-and-Spoke model for EA essentially eliminates the prospect of the centralized EA function becoming a bottleneck and instead promotes agility within the respective business units. The ‘just in time’ and ‘just enough’ mantras for architecture delivery may now be realized in the Spoke per local needs, rather than by the Hub for the organization as a whole.

Decisioning Agility

As mentioned earlier, Decisioning pertains to the outcome of the EA practice i.e., delivering the value proposition to the customers of EA in the organization. In order to make well-informed strategic decisions, the business relies on, among other factors, timely actionable intelligence provided by the individual business units or lines of business. These inputs will be aggregated at the enterprise level, and in turn help achieve the organizational KPIs (Key Performance Indicators).

Clearly, Decisioning agility heavily depends on EA analytics, which is best left to EA tools and repositories that have the necessary capabilities. Manual intervention here is almost always fraught with error and is simply not scalable to meet changing or growing business needs. Sophisticated EA tools and dashboards can vastly alleviate the workload of enterprise architects i.e., help them stay focused on compiling / updating the enterprise asset portfolio (as part of the collaboration between the Hub and the Spokes), determining current and future use cases for analytics- / data-driven decision-making, and essentially designing the EA intelligence, while the EA toolset does the work of providing the EA intelligence. This is again a key parameter towards making EA agile from the value proposition perspective.

A couple of screenshots below illustrate sample dashboard views that were generated off the Alfabet repository, an advanced EA repository and tool from Software AG. The view was developed using data provided by Visual Enterprise Architecture, an EA consulting firm based in Darien, CT.

The first graphic shows how a set of Applications and Application Functions provide operational, tactical and strategic business support to a set of business processes.?Operational applications are shown in BLUE, Tactical Near-Term applications are shown in YELLOW, and Strategic applications shown in LIGHT-BLUE.

The second graphic below shows how applications are consolidated or retired via a Migration diagram. This is obviously a useful view to help perform the Application Portfolio Management (APM) function.

In Conclusion...

At the end of the day, it is fair to say that each organization will need to determine for itself to what degree EA needs to be agile to meet the challenges in the marketplace that the organization operates in. Agility is a relative term – popular EA methodologies such as TOGAF provide several opportunities for customization to meet specific organizational needs that demand agility. Furthermore, present-day and emerging EA toolsets / repositories provide out-of-the-box capabilities to effectively complement the EA methodologies and help deliver the value of EA in an agile manner.

And last, but not the least, balancing the inherent strategic nature of EA with the agile needs of the organization will be a major challenge for organizations to effectively tackle?in the months and years to come.