In the previous article (Enabling Agile Enterprise Risk Management: Artifacts and Disciplines,) I identified the artifacts necessary to enable you to transform your enterprise at speed.  In this article, I will discuss the disciplines required to avoid creating Technical Debt by transforming and not just changing.

Artifacts Document WHAT

The artifacts that document the state of your organization include your Enterprise and Business Architecture (EA and BA) models, your Business Process Management (BPM) models and your Risk Register. 

To recap from the previous article, the EA model provides a schema of the constituent components of your company.  An EA model sufficient in detail to support AERM is composed of the following entities:

• Market Segments
• Products and Services
• Value Chains
• Capabilities
• Enablers
  • People
  • Processes
  • Physical and non-physical Assets (such as intellectual property)
  • Technology/Systems
    • Components (including infrastructure)
    • Information Assets (also referred to as business objects)

Two important elements of the EA model not covered in the previous article are an Ontology (a hierarchical classification scheme) and a Pattern Library.  The Ontology is used in the same way as a reference table in a relational database to ensure that objects in the models and the pattern library are labeled consistently, allowing them to be found reliably.  The Pattern Library is a place to store any type of informative or reusable artifact, such as design documents, proposals, presentations, training materials and so on.  Objects in the Pattern Library should be classified with entries from the Ontology, just as objects in the models are.  These two things are intrinsic to Knowledge Management (KM) and asset and component reuse.  And, reuse is fundamental to avoiding Technical Debt.

If a business unit were in need of particular capability, its classification in the EA model should ensure that decision-makers can reliably identify whether it already exists somewhere in the company, identify where it’s used and determine whether it can be reused.  If it exists, the Pattern Library should contain content or assets classified the same way, such as design documents for it or even copies of components that enable it.  Simply speaking, if you don’t know what you have, where it is and what it’s good for, you can’t reuse it.

As an example, if you are opening a new line for an insurance carrier, you will need to pay out claims.  If you look in your Ontology, you find entries for Payments capabilities, a Payments parent with three subtypes, or children—Payroll, General Accounts Payable and Claims.  Given the classification, you can then search the EA repository to determine who else in the company is employing the Claims Payments capability and find related assets in the Pattern Library to investigate how well it might fit your needs.  Armed with this information, you will be able to make an informed decision about reusing it, one that benefits your business unit, any other business unit employing the Claims Payment capability and the company.

The first step in applying the EA, BA and BPM disciplines is to create and populate the current state models that embody them.  The second is to implement processes around them to keep them current as the enterprise evolves.  The final step is to embed them and the information they contain into the design and implementation processes associated with transformation.  The aspect of transformation to which these apply is WHAT.  WHAT is what capabilities you will build and enable, what your post-transformation organization will look like and what the processes you will revise will look like after you do it.

Disciplines Determine HOW

The disciplines that enable you to execute the process of transforming are Scenario Analysis, Roadmapping, Project Portfolio Management (PPM) and Program and Project Management (PgM/PM).

In Scenario Analysis alternative futures are evaluated and their likelihood informs the design for a target enterprise architecture that will best position the company to compete.  Roadmapping involves defining the route that will be pursued to achieve the architecture.  Invariably, the roadmap will have more initiatives than can be executed concurrently and Project Portfolio Management is applied to prioritize, select, approve, fund, staff and sequence those chosen for execution.  Finally Program and Project Management disciplines are applied to execute initiatives predictably and efficiently.  In essence, these disciplines are about HOW.  HOW is the path you will take to arrive at the future state that you have chosen.  It encompasses all aspects of prioritizing, selecting, scheduling and executing the elements of your transformation.

Where Agile Enterprise Risk Management Fits In

I will not impugn the job risk managers do by questioning their competence but I will observe that there is increasing peril in accumulating small issues that go unnoticed, especially when things are changing rapidly.  Clearly, the risk in a major overhaul of a company’s order entry system would be pretty front and center but, perhaps, the impact of system updates on the platform on which it runs might not be, especially if the updates were most relevant to another application that shares the platform.  An opportunity to enter a new line of business could depend on an automated or semi-automated process that supports an existing product line and could necessitate a major logic overhaul that creates risks for the existing business line and impacts the cost-benefit outcome of the project.

Understanding dependencies in the EA model hierarchy and identifying capabilities and enablers shared across Value Chains is critical to uncovering things that might otherwise fall through the cracks.  As is the case with all implementation or transformation projects, finding dependencies late in the game is high-risk and usually results in excessive and avoidable negative outcomes.  The earlier in the design or planning process an error or omission occurs and the later it’s found, the more costly it will be to correct.

From an artifact and discipline standpoint, up-to-date models are a must.  Out-of-date information is almost worse than no information as it can lead to false assumptions, inappropriate designs and misaligned plans.  Secondly, it is critical to understand where risks actually attach to objects in the models.  For example, many risks attach to enablers and not the capabilities they support, even though their impact might be perceived there.   So, the need to upgrade a capability may result in increased risk in an enabler and this risk can propagate to other capabilities that it also supports.

None of this is entirely new.  People have been changing and transforming businesses since there have been businesses and, most of the time, they are able to recognize and deal with the issues for which they must account.  What is new is the level of decentralized decision-making inherent in today’s digital businesses and the dispersion of computing resources, subscribed services and polyglot solutions that power them.  What is also new is the velocity with which business models change and new operating partnerships, with all of their attendant integration issues spring up.

It is incredibly easy to duplicate even large-scale solutions on elastic cloud infrastructures and create redundancy that may be quite difficult to corral and remediate.  If there is no central model repository, or no discipline about maintaining it, it’s also quite easy for the redundancy to go unrecognized until someone reconciles the cloud vendor’s bill and maybe not even then.

In the end, Agile Enterprise Risk Management is about maintaining a detailed understanding of your company’s anatomy from strategy down to your enablers, understanding how the pieces and parts interrelate and identifying which of them must be modified or evolved in order to achieve a transformation goal.  If you truly understand your organization’s anatomy, then you will be prepared to identify risks and comprehensively trace where changes might make their impact felt.

In a future post, I will document a design for a system and repository to do exactly that.

BIO:

Howard M. Wiener is Principal of Evolution Path Associates, Inc., a New York consultancy specializing in technology management and business strategy enablement.  Mr. Wiener holds an MS in Business Management from Carnegie-Mellon University and is a PMI-certified Project Management Professional.

He can be reached at:

howardmwiener@gmail.com
(914) 723-1406 Office
(914) 419-5956 Mobile
(347) 651-1406  Universal Number