In Agile Enterprise Risk Management, Risk-Based Thinking, Multi-Disciplinary Management and Digital Transformation I focus on several topics around transformation. The overarching objective of transformation is business agility—the ability to identify opportunities and threats in your environment and react to them at speed. In the volatile environment in which we are now living, this is what will enable you to sustain your company. In fact, it’s the only thing that will.
One of the things I assert in the book is that one of the goals of your transformation is to develop and evolve your ability to transform. What . . . Why?
In the VUCA (Volatile, Uncertain, Complex and Ambiguous) world in which we are currently operating the rapid evolution of forces acting on your company, such as technology, are driving continual change to the degree that you will need to be prepared to evolve and transform again and again to keep pace. There is no single target end-state that you can reach that will allow you to take an extended breather. The chances are, you will have to change course, maybe more than once, while executing any substantial transformation you undertake.
I contend that you are now facing a need to perform two transformations in parallel—a Digital Transformation and adoption of Agile Enterprise Risk Management. I believe that the two are symbiotic—that both require common management disciplines, which must be implemented and exercised in a manner consistent with running a digital business, to be successful.
Your First Transformation
Your first transformation will be adoption, adoption of the architecture, technologies, disciplines and processes of being a digital business that exercises Agile ERM. These include (among others):
- An architecture that incorporates the six pillars of a digital company—a rationalized technology infrastructure, API management, a Digital Products and Services Factory, a Partner Development Platform, Business Intelligence and Analytics capabilities and a distributed governance model,
- Technology capabilities that make your digital architecture feasible—Cloud architecture and management, Continuous Integration/Continuous Deployment (CI/CD), Artificial Intelligence and Machine Learning, for example,
- A cloud migration for most of your core information systems and network infrastructure,
- Value-stream Product Management processes, exercised by integrated PM and technology teams with the authority to invent, innovate and evolve new businesses and products,
- Enterprise and Business Architecture, Business Process Management, Knowledge Management and
- Agile ERM, driven by the artifacts created as you exercise the disciplines you employed to effectuate your digital transformation.
As you put your digital pillars in place you should begin to realize the ability to create and evolve your business model at speed—new products and services, new features and functions, new joint offerings with partners. This is, of course, your goal. However, with speed comes the risk of creating a variety of forms of debt that can serve to gunk up your ability to transform, impair your agility and require time, effort and cost to remediate.
As an example, consider the CI/CD software development capability. If you do not have mature Agile and DevOps practices, this is something that you will have to develop. Certainly, you cannot expect to attain first-order skills from the outset, and you might well have to experiment with alternative mixes of people, training, enabling tools and process designs before you get it right. At the same time as you are evolving this capability, you may also be establishing and maturing your cloud presence, the target operating environment for the software you are developing. There will be fits and starts as you get all of this in sync and along the way, you will probably create work products that are implemented inconsistently with one-another, and which will ultimately prove to be inconsistent with your evolving standards as your practices mature.
So, you will create debt, in multiple forms—technical debt, organizational debt, process debt and others. What is debt in this context? It is a downstream cost that results from implementing something in the near term in a way that that creates inefficiencies and costs in the longer term. Thus, applications, whether new or existing, will require what should have been avoidable effort, cost and time to build, evolve or remediate.
It is, however, impossible to transform without creating some debt if you are to transform at all. Ultimately, it is a balancing act. You will have to make decisions about how to trade off agility vs. time, debt, cost, effort, quality and risk. You can race to get a new product to market, but you probably can’t ensure that you can implement it to an architectural standard that will obviate all technical debt over the life of what you’ve built. It’s just the nature of the beast now and will be forever.
Your Subsequent Transformations
You are now (or should be) scrambling to put your digital pillars in place. You are unavoidably creating debt as you go. Everything that contributes to the debt will accrue to the point that refactoring, redesigning or rebuilding things that aren’t reusable or that don’t fit architectural standards will be warranted. This will mean that you will have to expend resources that you would otherwise allocate to creating new products, services, features or functions for your customers to fixing things that you’ve already built, things that may be working (for the time being) but which could be better—more easily reused, more efficient or more cost-effective. Besides the obvious burden on your resources, this will impair your ability to execute transformation and change—the drivers of your business agility. You’re not just going to be changing the tires while you drive the car, you’re going to have to pave the road on which you’re driving at the same time.
The architecture and enablement you are putting in place while you are transforming and running your existing operations will become the starting point for subsequent transformations, and each will become the foundation for those that come after.
So, this creates some questions. Can you design your initial to-be state to facilitate your ability to transform as you move forward? If so, what are the design principles that you should follow and how much time and energy should you put into up-front design as you undertake your transformation? How can you measure agility anyway? How will you know if you have designed well?
I will tackle these questions in subsequent articles.