In my previous post, I asserted that many companies are not good at managing risks and I’ll stand by that statement. They’re not good at identifying them, poor at pinpointing dependencies, don’t understand the interactions that create or exacerbate risks and fail to actively quantify and evaluate the effectiveness of their risk management programs. I believe that a number of disciplines should be applied to help address these issues.
Let’s talk about Enterprise Architecture. No! Don’t run away. We’ll keep it at a layman’s level and try to avoid the need to employ an electron microscope to voluminous diagrams of elements of your company’s structure in order to make any sense of it.
What is Enterprise Architecture?
When you design a house, you compose it out of a set of components—rooms, walls, hallways, the façade, plumbing and HVAC systems and so on. When you design or document an enterprise you use a palette consisting of, among other things, (a) the products and services the company sells, (b) the Capabilities the company requires to produce what it sells and (c) the people, processes, assets and technology that enable the capabilities.
Our EA model should also incorporate elements of Business Architecture. Business Architecture describes how elements of the Enterprise Architecture, mainly capabilities, are composed into Value Chains that ultimately result in value to the company’s customers in the form of products and services. A typical Value Chain might be (a) design product, (b) design production and assembly line, (c) procure materials or parts, (d) make or assemble product, (e) sell product and (f) receive payment.
By following the Value Chain, you can identify the processes, systems that support them and the people that perform them, the assets, such as the plant building and equipment, required to progress through the chain. So, you can take a vertical slice through your company to see what EA elements relate to each of your products or services.
A complication—what if some of your Capabilities or the people, processes, assets and technology that enable them are shared across multiple Value Chains? Then, any changes you might consider making have to be evaluated for potential impact to all of the Value Chains that rely on them.
One last complication—some of your products or services might be crucially important to your company’s strategic goals or its sustainability, while others are less so. It is probably also the case that some of your Capabilities are proprietary, things that you are uniquely good at and which anchor your company’s value, while others are fairly generic and might, perhaps, be outsourced to good effect.
Implications for Risk Management
If you are contemplating new or updated products or services or considering making changes to your enterprise, you will need to evaluate the risks associated with these things. If you have sufficiently comprehensive Enterprise and Business Architecture models, you can trace how all of the components of your enterprise that may be effected connect and depend on each other. If you have a portfolio model of your products and services, you can identify which of them contribute most to your profitability and growth and which, therefore, are most important.
These artifacts, taken together, will position you to identify, prioritize, assess and design treatments for the risks or opportunities that are most likely to impact your plans. It will position you to emphasize surveillance efforts on what might appear to be relatively unimportant risks but which in fact relate to crucial products services or capabilities or which have multiple integration points and dependencies that could create outsized impacts simply as a result of complexity.
Here’s a quick case study. Earlier in my career, I worked on a substantial systems development project for a Financial Services company that was specialized in an area of the markets that was somewhat out of style at a time in which the markets were booming. The company had been losing assets under management and had lost some large clients from poor investment performance but also because service agents had not been able to see the full scope of their holdings and had failed to handle the clients’ needs with sufficient care. In order to address their strategic weakness, which was primarily related to product mix, they elected, instead, to replace the systems supporting their service center staff.
The project was a disaster for a variety of technical reasons. The solution destroyed the efficiency of the service center and was never able to support the more complicated products that the company was hoping to add. The CEO was pushed into retirement, the head of IT was fired and the venerable company was ultimately sold to a large bank.
It’s not entirely the case that a comprehensive EA model would have prevented this; however, it illustrates how interconnected and shared EA components can amplify risks. The service center did have a problem in handling clients with complicated portfolios but that was not what was holding the company back; it was the product mix that failed to provide clients access to the types of investments that were hot at the time. By failing to identify what was really driving the situation, the company failed to recognize and mitigate risks and it resulted, ultimately, in a forced divestiture.
The lesson here is that companies should apply EA and BA disciplines to enable comprehensive risk management.