Continuous EA: adopting the architectural multiverse

While we’re moving into a multi-cloud, multiplatform, hybrid world, where business and IT deployment options are multiplied, keeping architectures reliable is becoming a prime challenge. Traditionally, Enterprise Architecture (EA) aims to fulfill business strategy by providing a purposeful IT against predictable cost. It also is long term, complex and laborious.

Various forces turned today’s EA more complex. Particularly the (automated) delivery of Cloud services has seen a proliferation of repositories, with hundreds of small projects replacing a handful of monoliths, a desire for more automation to realize the full potential of Continuous Delivery (CD) in multiple environments and the emergence of highlighting functions.

Frequent automated service drops, tweaking an organization’s IT capability, do not go down well with a usually contemplative and measured EA. In the past, EA was to set the pace of IT change, providing guidelines, technology choices and an overall change strategy. Those days are gone. The increased rate of change requires EA to re-invent itself if it is to stay on top of events and remain purposeful in the kaleidoscopic world the Cloud, and specifically CD, offers.

Multiverse

Firstly, to enable EA again to define and legitimize IT choices, it is to adopt the increased rate of change by absorbing the versatility of Cloud deployments. This starts with accepting that there is no longer one blueprint architecture. Instead, there are similar and concurrent architectures or parallel versions of the truth. EA will no longer manage one single continuum, but in fact a multiverse of candidate architectures.

As a result, this brand of continuous and evolutionary EA will also inevitably reduce the level of detail of process diagrams, functional landscapes and other EA artifacts. Instead, EA is to provide a trajectory to a clear goal, defined by high level requirements expressed in terms of e.g. finance, timeliness, quality, availability, security, performance and usability. The actual fulfillment is responsibility of the development teams, post-recording the tested and accepted change in a fresh architecture, next to its previous version.

Change rate

While business change is a constant, it is the actual rate of change that allows continuous EA to focus resources. Business functions like sales, service, compliance or assurance are typically driving most changes and will therefore merit priority in an architectural multiverse. For functions with more predictable change cycles, scheduled architecture change projects will continue to be needed, delivering into that multiverse on a set point in time.

Finally, and most challenging, EA should scrap the idea that change is one-directionally trickling down from business strategy to IT services. The quickly expanding portfolio of Cloud services can actually enrich significantly the business ask or its strategy. However, as most DevOps examples demonstrate, this bi-directional communication can be a cultural challenge, and will, like all organizational changes, take time and a large degree of evangelization.

In a way, continuous architecture shifts EA’s main objective from capturing a company’s momentary truth towards identifying its ambitions and presenting multiple IT options to fulfill them. It slices up the traditional architectural blueprint in parallel, almost similar, versions, allowing business to instantly changing gears to timely reach markets and customers.