The Skeptical Architect – May 2013

Business architecture focuses on the opportunity and capabilities of the organization. They are the driving forces behind a business’ strategy to do a merger, an acquisition, a divestiture, drive IT alignment, improve business processes or engage in an outsourcing activity. Certainly, various architectures are contextually implicit within the business and that of an anticipated strategy. Thus, the families of architectures (Enterprise IT Architecture, Business Architecture, and Strategic Business Architecture) that we discussed in our February column are part of the anticipated strategy and should be made “explicit.”

In Price Waterhouse Cooper’s (PwCs) 16th Annual CEO Global Survey,1 the CEOs who participated in the survey cited the following areas of concern: seek growth in U.S. markets, see consolidation and acquisition key activities, anticipate wide fluctuations in economic conditions due to governmental actions, build more resilient businesses to mitigate various risk scenarios, navigate the uncertain tax and regulatory actions, continue to reduce costs at an operational level, address the talent shortage that is anticipated for future, understand the customer’s needs better for growth, invest in more secure natural and energy resources, utilizing social media ethically to build better customer relationships, and mitigating cyber-security attacks on networks.

Certainly, the goal is to understand the business change, the impact on the strategic transformation effort. With that intent, each alternative will entail the development of initiatives, requirements, and projects that eventually result in the desired business results. Implicit in each alternative strategy declarations are assumptions and risks that should be “explicitly” assessed as a part of the analysis. So, understanding how risk is a part of any discussion of strategy in terms of the organization’s capabilities, its business continuity, and the yield are very relevant to delivering results.

You need to connect the PwC survey results with an architecture framework to leverage the survey value. Given the concerns expressed in the PwC survey, we can relate it to Zachman’s2 Enterprise Ontology, specifically, the “Why” column addresses the motivational types that the executives use in the development of a strategy. In doing so, the executives and management have to address “explicit” risk factors and those associated with the other “implicit” architectures in the organization, such as building more resilient businesses to mitigate various risk scenarios or continuing to reduce costs at an operational level. Why? They must rank the various alternatives before deciding on which of the strategy alternatives would be most effective and efficient. And with each alternative, the different architectural families are used to bring about the execution of the strategy with its associated risks.

Wikipedia3 provides a description of strategic management and its history. It describes strategic management as “a field that deals with the major intended and emergent initiatives taken by general managers (executives) on behalf of owners, involving utilization of resources to enhance the performance of firms in their external environments. It entails specifying the organization’s mission, vision and objectives, developing policies and plans, often in terms of (initiatives), projects and programs, which are designed to achieve these objectives, and then allocating resources to implement the policies and plans, (initiatives), projects and programs. A balanced scorecard is often used to evaluate the overall performance of the business and its progress towards objectives.” Of the many reasons for not meeting strategic objectives, two in particular stand out:

• Failure to manage change
• Inability to coordinate elements across the organization

These two reasons can be resolved using architecture analytics. Both of these reasons are related to a lack of clear understanding of the relationships that exist which will be affected in the organization change. These changes are brought about by the implementation of the strategy, tactics and operations upon each other. An explicit and articulated business-focused architecture contains the basic models to assess the impact of changes in either direction, top down or bottom up.

Focus on Architecture and RiskManaging change and coordinating elements specifically to business risk. Business risks are documented in the business-focused architecture. What types of risk are we talking about? There are a number of categories of risk, for example:

• Financing risks – (capital availability, liquidity, investors, funding, etc.)
• Information Technology – (technology platform, security, design, obsolescence, etc.)
• Managerial risks – (adaptable, consistency, decision-making, communication, etc.)
• Market risks – (pricing, demand, substitutes, availability, quality, competition, etc.)
• Operational risks – (reliability, capacity, inventory, process, measurement, etc.)
• Product risks – (acceptance, support, technology, quality, etc.) 
• Staffing risks – (expertise, competence, turnover, re-training, outsourcing, labor, etc.)
• Systems – (compatibility, integration, infrastructure, stability, implementation, etc.)

Risk information is usually captured by connecting the risk factor to a process (operational), an initiative (tactical) or an objective (strategic). Capturing risks factors as part of the architecture (with their underlying assumptions) allows the analyst to produce an assessment across the three architecture families of models. Further, risk information can be attached to any subject area of concern (a structural component) of the enterprise providing a cascading assessment of impact from strategy to operations and back.

So, how can you address Risk as part of Architecture?

An architecture analyst working with a risk analyst can take a series of actions to mitigate risk. Here is how they can do that:

1. Focus on the intent of the strategy alternatives. Relating objectives to strategic level risk is the first step in assessing risk remediation. Knowing that the goal and intent of the strategy, makes it easier to focus the analysis required.
2. Select and use existing descriptions and relationships among the key focus areas, such as: products, organizations, processes, locations and other business components associated with the strategy to build the various models.
3. Gather the material for the impact analysis by developing those architecture artifacts that are relevant and specific to the business situation.
4. Assign probabilities of impact and risk [i.e., using a scaling of low (1) to high (5)]
5. Produce relationship matrices of the descriptive content. 
6. Use impact and inference techniques to assess the potential risk scenarios.
7. Complete the initial impact assessment by including a run analysis of the related model inferences to complete an impact assessment.
8. Use the 4-Box graphical representation of the risk verses degree-of-business impact. 
9. Profile (a one page assessment) of the results for management’s understanding and decision-making. The profile should focus on the high-risk / high-impact ranking.
10. When this assessment is complete, similar steps are following to include the tactical and operational risk levels.

Here’s how use architecture to understand risk impact!

Remember the goal is to understand business change and risk associated with the impact on various areas of the business. The business analyst using architecture-based framework can help to mitigate risk by assessing impact of risk as it cascades through the various architectures. By making explicit the risks associated with the strategic, tactical, and operational alternatives, it provides executives with an enhanced perspective of how architecture can come to the rescue in assessing organizational risk.

End Notes:

1. See download reference at http://www.pwc.com/us/en/ceo-survey-us/downloads.jhtml
2. John A. Zachman, “The Zachman Framework for Enterprise Architecture: The Enterprise Ontology”, see http://www.zachman.com/
3. See Strategic Management, http://en.wikipedia.org/wiki/Strategic_management