Change as a Core Competency

The Problem

Organizations must adapt to a world influenced by new digital trends that require we break the shackles of large projects and organizational step changes but move to a more evolutionary and smoother model of delivery. However, my argument is that this must done in a controlled manner, if the long term health of the organizations overall IT ecosystem is to be maintained. It is also important to accept that we can no longer ignore the impact of the broader end user ecosystem on any strategy. Our consumers are on the whole owners and users of complex technologies and as such exert considerable influence on any technical strategy. We are rapidly moving away from the era of isolated IT systems and into an integrated, connected environment.

An example of this can be found in what I describe as the four phase of financial services from a channel perspective:

How well can an organization control its own destiny?

Figure 1

The first phase involved just head office banking, customers had no option but to go to the head office to do business. Banks introduced branches so that customers had somewhere local to go for banking services. The overall experience was controlled entirely by the bank. The introduction of the internet and subsequently mobile banking increased the reach of the bank but introduced a level of variability, banks no longer controlled all of the user experience and integration into alternate services e.g. new payment capabilities started to erode control. The introduction of more open architectures such as Open Banking or PSD2 is specifically intended to further break the control of the banks and introduce more variability into the ecosystem. Its this level of variability that we need to understand in the delivery of IT systems, and forms the basis of our transformation requirements.

Moving an entire business into a state of continuous change is a large and complex undertaking. In this article I am not going to describe this process in detail (more on this in a later article) but more focus on the skills our new Enterprise Architect must have order to help facilitate such a journey. I am only going to give an overview of the new areas; I’ll leave the detail for a later post.

In addition, I want to revisit the interchange that must now take place between the Enterprise Architect and our new role, that of the Enterprise Engineer.

So first, let us look at what our new Enterprise Architect must deal with.

For many years’ economists, social scientists and ecologists have been adapting Complex Adaptive Systems theories, linked with social and economic theories to describe ecosystems (natural or economic) their dynamics and evolution.

I assert that, understanding, and to some extent modelling, an integrated social, economic and technical ecosystem generally falls into the world of Complex Adaptive Systems, which were first described in 1986 and have been refined and developed ever since.

We will investigate these further to see what we can learn from such practices. So it’s the tools and techniques that underpin the study of CAS that will provide the basis for our view of how an Enterprise Architect can better understand business and IT change.

Critical Enterprise Change Attributes

The hypothesis is that businesses must be set for continuous change. The key challenge for any organization therefore, is to create an environment that conserves the ability to adapt to change, to be able to respond in a flexible way to uncertainty and surprises to be able to exploit opportunities that present themselves.

As an Enterprise Architect we must create this dialogue through focusing less on documenting the static elements of architecture (we no longer have the time, luxury or requirement) and switch to understanding the dynamics of change and systems evolution. These are critical dimensions of CAS systems and how they are understood.

The properties we need to choose are not those chosen to describe the existing state of a system and its behaviours but rather the ones chosen to identify the properties and processes that shape the future – Panarchy, C.S. Holling and L. Gunderson 2002.

I am going to adopt a framework, based on that described in the text referenced above, as the basis of the study of change.  I will augment this in a later discussion, but for now this will provide a sound starting point for our discussion.

1. Potential

This sets the limits to what is possible, determines the number of potential options that can set the future.

Potential is an interesting dimension to consider as an Enterprise Architect, we are trying to answer the question of how far I can take the current architecture, both business and technology. The how far concerns the ecosystem or systems the organization is connected to. It also raises the question of how open or closed an organizations ecosystem needs to be in reality to be able to effectively interact with consumers and suppliers. Most digital scenarios require connections to open ecosystems and here we will find a mix of classic product and more modern platform architectures. So why is this important? There have been a number of notable business failures in the last few years due in part to those organizations failure to understand both the evolving nature of the ecosystem they were connected to or just not have the ability to connect at all i.e. their strategy was based on a closed ecosystem model which failed to adapt quickly enough when significant disruptors, in the form of new competitors or changes in the competitive landscape.

2. Connectedness

This really looks at the degree of coupling between an organization and its chosen ecosystems, its importance is because it defines a level of control and influence an organization has over the external world and any associated risks between the internal and external processes/capabilities an organization has. In effect this determines the degree to which a system can control its own destiny, as opposed to being caught by the whims of external variability.

If we revisit figure 1 we can see that financial institutions ran an effect closed ecosystem (head office and branches) for many years. The advent of the internet did, like many industries, open the ecosystem. but only to the extent that the consumer’s device influenced the choice of technologies and to some extent the interactions required. In many cases digital has ruthlessly exposed deficiencies in internal process to consumers and many organizations are having to redefine themselves end to end.

However, the advent of PSD2 and Open Banking is creating an ecosystem shock that transitions the consumer space firmly into an open ecosystem model. This disruption, driven by regulation in the case of financial services, has increased the level of variability in the ecosystem and many organizations now find themselves dealing with high degrees of uncertainty with respect to how these business models will evolve. This is highlighted by the move of many Fintechs into the financial services ecosystem.

So in effective defining connectedness helps in understanding how proactive or reactive and organization can be with respect to its external world(s) and how ecosystems shocks (like new regulations) are transmitted into the organization.

There are a number of addition measures that come under the connectedness umbrella, a significant one is technology diversity Vs technology standards, I will discuss this alongside systems evolution in a future article.

Remember connectedness is an end to end property so Internal connectedness must be considered as well.

3. Resilience

The structure of the ecosystem that organizations participate in is defined by the collective capabilities of those organizations that contribute to it. So organizations must define their place or role within the ecosystem through the capabilities that they deploy. This requires that they can scope the ecosystem that they interact with, not impossible to do but some care is necessary to identify the relevant boundaries of the ecosystem.

Understanding resilience is important in assessing how well any given organization is positioned within an ecosystem and how well both the organization and the ecosystem can respond to disruptive events:

• Ecosystem Resilience — the existence of a function, the presence of a function that contributes to the definition of the ecosystem. This represents the realization of a given organizations business model with respect to what is in ecosystem.
• Engineering resilience — the efficiency of a function, how well a function survives a particular disruptive event. This is effectively how strong is the function against the competition within the ecosystem or how well a commonly used capability can survive ecosystem shocks.

Innovation and commodity as defined by Cusamano, and referenced in my first article, fall into the category of capabilities influenced or modelled as part of our ecosystem resilience assessments.

The Enterprise Architect now has crucial elements of a toolset that enables them to understand the dimensions of Business and IT transformation, now the dialogue must be between the Enterprise Architect and the Enterprise Engineer. For this we need to translate what we have learnt into a common reference point that bridges Enterprise Architect and Enterprise Engineer. Fundamentally the Enterprise Architect must set the boundaries of freedom for Enterprise Engineer.

Enterprise Architects dialogue with the Enterprise Engineer

So the Enterprise Architect will set a sandbox in which the Enterprise Engineer can operate the attributes of the sandbox are set by the three principles the EA will use to instrument the ecosystem of interest.

If an agile project needs to be established to fix a lack of Potential, it typically has the greatest degrees of freedom to operate. There is unlikely to be any legacy drag from the existing portfolio and freedom re technology choices. Speed is frequently of the essence so any agile project should be free to choose technology, sourcing and hosting options.

Connectedness presents a different set of issues, typically for an agile project technology choices or even standards may already be defined by the ecosystem e.g. RESTful API’s. There are deep process issues associated with vulnerabilities to ecosystem variability that must be addressed and as such MVP will have to be tightly scoped. Existing technologies already deployed by the organization usually have to be respected so technology scope and hosting options may be limited.

Resilience effectively brings into focus the Innovation Vs Commodity debate. Thus “Engineering Resilience” is all about improving the business position in terms of being “best in market” for a given capability. It also, through its Innovation lens presents a similar set of options to the agile developers as a lack of Potential, it is though generally associated with a smaller functional gap than a lack of potential and a well-structured ecosystem that may limit options. However, the general overall degrees of freedom for an agile project will typically apply.

 

Change Agent	Degree of Freedom for an agile project
Potential	Highest levels of freedom for an Agile Project.
Engineering Resilience	Very close in how open the technology and hosting choices are for an Agile based project.
Connectedness	Significant levels of constraints typically apply to Agile based projects.
Engineering Resilience	Lowest Levels of freedom for an Agile Project.

 

I find that this approach allows the Enterprise Architect to understand how concerned they should be about the scope and technology choices any agile project should be allowed without impacting on the overall change strategy for an organization.

This is but one element of the new skills required of the Enterprise Architect if organizations are going to switch to a more agile model of delivery. There are two other key capabilities that must be looked at, these are:

Change Cycles in Adaptive systems

The dynamics of change in complex systems is neither continuous, gradual or chaotic but in fact it is episodic.  These types of behaviors are clearly recognizable in the technology timelines and are relatively common e.g. Docker and Containerization.   Thus the study of these change cycles is governed by the need to understand the frequency of these episodic changes and what properties we need to monitor in order to best understand them.

Systems Evolution

If we are to move to a finer grained component view of our IT ecosystem we must look to evolve mot necessarily wholesale replace elements of our systems. An understanding of how we may achieve this for both our internal and externally connected systems is a vital skill. There are many, somewhat conflicting views on this, many based on a based on a somewhat Darwinian view of evolution; this is being challenged by ecologists today where emerging views suggest a different set of dynamics for successful evolution. The emerging premise is that successful species do not compete, but either shun competition or engage in complex partnerships (symbiotic). I shall review the relevance of this in understanding how our complex social/technical/economic systems can change.

I will look at both of these in future articles.