Align IT and Business in an Agile Manner

Agile Software Development

Subscribe to Agile Software Development: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Agile Software Development: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Agile Development Authors: Elizabeth White, Jason Bloomberg, Plutora Blog, Liz McMillan, AppNeta Blog

Related Topics: Cloud Computing, Agile Software Development, Change Leadership Journal, CIO, SOA Best Practices Digest, Microservices Journal

Agile Development: Blog Post

Architecting Change | @CloudExpo #Cloud #Agile #DigitalTransformation

There’s more to architecting change than managing change

Architecting Change as a Core Competency

In a recent article for Forbes I wrote that enterprise architects (EAs) should be less agents of change as architects of change. In response, several EAs commented that what they had been doing all along looked quite a bit like architecting change. After all, dealing with change has always been a top priority for enterprise architecture.

There's more to architecting change than managing change, however. In order to deal with disruptive business environments - as well as introducing disruption intentionally to shake up the competition - organizations must become better at dealing with change generally.

In other words, change itself must become a core competency.

Furthermore, the EA should play a central role in this pursuit of greater business agility, as there are many different types of change that require different approaches. Taking a difficult, multifaceted problem and breaking it up into its core pieces in order to apply appropriate solutions, after all, is a core strength of the EA.

For those EAs out there who are questioning what it means to architect change - as well as anybody else struggling to achieve greater agility in the face of ubiquitous disruption - let's break down this complex notion.

Starting Point: How Organizations Traditionally Deal with Change
Change, of course, is difficult, and given a choice, people would simply rather not do it. As a result, organizations only change when they have to - when the pain of not changing is even greater than the pain inherent in the change itself.

Change, therefore, addresses a pain point or generally solves a problem (or set of problems) - and once we've solved those problems, then we're done managing the change. As a result, traditional change management follows this pattern: unfreeze/change/refreeze. The current status quo is causing issues, so undergo some kind of change process to a new state, which becomes the new status quo.

This current state to future state thinking is central to traditional enterprise architecture frameworks, and has also given rise to the entire change management industry. In fact, if you ask executives how their organizations deal with change, more likely than not they'll point to their change management organization.

Beyond Change Management
As I've written about before, this present state to future state approach to change has serious issues, as understanding the present state is problematic and the future state is downright fictional. That being said, there are certain kinds of change that do lend themselves to present state/future state thinking.

For example, let's say your organization is moving its headquarters to a different location. In this kind of situation, the present state (starting off in the old location) and future state (ending up in the new location) are straightforward, and the goal of the change management exercise is to deal with all the challenges in between.

The bigger picture here, however, is the fact that such straightforward changes are more the exception than the rule - and organizations facing broad-based disruption need better tools than traditional change management for dealing with such disruption.

Six Types of Change
The unfreeze/change/freeze approach only works with change that has well-defined, reasonably stable present and future states. Let's call this type of change finite change.

We may also have to deal with linear change (or perhaps more accurately geometric change). If our company is growing at a steady clip, then an important key performance indicator is the compound annual growth rate (CAGR) of the organization's important metrics, like profitability. Managing growth, therefore, is an example of managing linear change. Linear change is as familiar as finite change, but has no end state.

The third type of change is cyclical change. Business cycles, for example, drive cyclical change, as the economy gets better and then worse, only to repeat itself. Another important cause of cyclical change is the product maturity cycle familiar from value chain mapping: products go from innovations to a ramp-up phase to the mature, high-profitability phase, until such time as the next innovation invariably comes along to supplant them.

Fourth is discontinuous change. Some unusual event suddenly disrupts the status quo. Common causes of discontinuous changes include natural disasters, terrorist attacks, or the death of a key executive. Disaster recovery planning is a typical approach for dealing with this kind of change.

Fifth on our list is accelerating change. Any sort of change tied to Moore's Law, for example, is accelerating change. Because such innovations, whether they be processing power, memory or storage cost per unit, or even the battery power required to run a device follow exponential curves, they often catch people by surprise when they reach a significant inflection point.

Accelerating change may be difficult for people to get their heads around, but nevertheless it is effectively predictable. How many gigabytes of storage will we get for a dollar in 2025? Work the math properly, and you'll come up with a reasonable guess.

So far, so good - the five types of change on our list so far are relatively familiar. You may not have thought to list them separately, but once we do, it's clear we've already come up with straightforward, effective approaches for dealing with each type of change - at least, until we get to #6.

Dealing with Chaotic Change
I call #6 on our list chaotic change - chaotic in the butterfly-in-a-forest sense that a small change in initial conditions can have a dramatic, unpredictable effect down the road.

Chaotic change is the type of change I've been talking about at Intellyx all along. If the disruptions in our business environment are unpredictable, and more importantly, have unpredictable effects, then none of our approaches for dealing with the first five types of change will help us manage such chaotic change.

Fundamentally, there are no recipes for dealing with chaotic change. Instead, we must up our game. We must help our organizations become more agile - better able to deal with change overall. Not any particular change as traditional change management would prefer, but change as a core competency.

If you've been following my writing at Intellyx, you'll recognize the two fundamental tools I recommend for dealing with chaotic change: inherently flexible software and self-organization at scale (download our new Agile Digital Transformation Roadmap poster for more detail).

On the technology side: the key to inherently flexible software is to separate the underlying software platform from application-building capability - functionality that is only now beginning to mature in today's low-code and no-code platforms.

On the human side: self-organization at scale takes the organizational best practices from the DevOps world and extends them across the organization. Self-organization at the small-team level is relatively straightforward. Extending it across an enterprise is much more difficult.

The Intellyx Take
Perhaps the most important lesson from this Cortex that EAs should take to heart is that there are many different types of change, and not all of them are chaotic. In fact, the approaches I recommend for dealing with chaotic change would be overkill for dealing with the other types of change - too risky and expensive as compared to traditional, well-understood change management approaches.

Executives considering the deeply transformative nature of self-organization at scale, therefore, can breathe a small sigh of relief. Because the enterprise faces different types of change in different areas and at different times, chances are you don't have to implement self-organization across every corner of the organization.

However, in today's increasingly digital world that sigh of relief is likely to be brief, as chaotic change is all around us, and it's only getting worse. While it's true that this sixth type of change is the most difficult to deal with, given how prevalent it is, you should already be well on the way to implementing best practice approaches for dealing with it. The very survival of your company is at stake.

Copyright © Intellyx LLC. Intellyx publishes the Agile Digital Transformation Roadmap poster, advises companies on their digital transformation initiatives, and helps vendors communicate their agility stories. As of the time of writing, none of the organizations mentioned in this article are Intellyx customers. Image credit: Karen Roe.

More Stories By Jason Bloomberg

Jason Bloomberg is the leading expert on architecting agility for the enterprise. As president of Intellyx, Mr. Bloomberg brings his years of thought leadership in the areas of Cloud Computing, Enterprise Architecture, and Service-Oriented Architecture to a global clientele of business executives, architects, software vendors, and Cloud service providers looking to achieve technology-enabled business agility across their organizations and for their customers. His latest book, The Agile Architecture Revolution (John Wiley & Sons, 2013), sets the stage for Mr. Bloomberg’s groundbreaking Agile Architecture vision.

Mr. Bloomberg is perhaps best known for his twelve years at ZapThink, where he created and delivered the Licensed ZapThink Architect (LZA) SOA course and associated credential, certifying over 1,700 professionals worldwide. He is one of the original Managing Partners of ZapThink LLC, the leading SOA advisory and analysis firm, which was acquired by Dovel Technologies in 2011. He now runs the successor to the LZA program, the Bloomberg Agile Architecture Course, around the world.

Mr. Bloomberg is a frequent conference speaker and prolific writer. He has published over 500 articles, spoken at over 300 conferences, Webinars, and other events, and has been quoted in the press over 1,400 times as the leading expert on agile approaches to architecture in the enterprise.

Mr. Bloomberg’s previous book, Service Orient or Be Doomed! How Service Orientation Will Change Your Business (John Wiley & Sons, 2006, coauthored with Ron Schmelzer), is recognized as the leading business book on Service Orientation. He also co-authored the books XML and Web Services Unleashed (SAMS Publishing, 2002), and Web Page Scripting Techniques (Hayden Books, 1996).

Prior to ZapThink, Mr. Bloomberg built a diverse background in eBusiness technology management and industry analysis, including serving as a senior analyst in IDC’s eBusiness Advisory group, as well as holding eBusiness management positions at USWeb/CKS (later marchFIRST) and WaveBend Solutions (now Hitachi Consulting).