Leveraging Enterprise Architecture in Enterprise Risk Management
Nov21

Leveraging Enterprise Architecture in Enterprise Risk Management

Enterprise risk management (ERM) is one area that I believe EAs could positively contribute to. Several years back, a manager in charge of ERM approached me enquiring how EA could benefit his department. He knew what EA was and was keen to see if he could benefit from it. His primary challenge was assessing impact of risk across the enterprise; his team was handicapped, as they did not have traceability capability. In this article, I explain how EA helped him achieve his objectives. Organizations deal with different types of risks that, if not attended to, could have adverse impact on organization performance and outcomes. Generally speaking, “risk” is the potential of undesirable outcome resulting from a given action or omission (foreseen or unforeseen). On a different note, “risk management” (RM) is the identification, assessment, and prioritization of risks followed by appropriate actions to minimize, monitor, and control the risk impact. The intention of this blog is not to explore risk management as such but rather explain how enterprise architecture (EA) could benefit risk management. Those of you seeking more details about risk management can explore other external sources. While I do not dispute that RM is not unique to EA, it is important we appreciate that EA has great potential to contribute to GRC (governance, risk and compliance) by feeding into the enterprise risks management (ERM) process. The problem with traditional RM efforts like program and project (risk management) that are usually independent, narrowly focused and functionally driven is that they work in silo and fail to integrate at enterprise level leading to fragmented view of risks each with its own classification, criteria, and measure. Ultimately, most critical risks with major business impact never make it at the enterprise level though the resulting consequences do. So what is the rationale behind leveraging EA in ERM? As we all know, EA involves blueprinting an enterprise by connecting the business, information, application, and technology layers. Usually, we achieve this iteratively through an architecture development method like TOGAF. Whenever we create (or update) and link each of these architectural layers, we get the opportunity to assess impact of change on subsequent layers. The presence of this unique traceability creates a window of opportunity for ERM. If we extend the concept further, it could help organizations identify and assess impact of risk on these architectural layers (I like to view this as enterprise assets). Why do I say so? One of the toughest challenge in ERM is modeling risk and its impact on enterprise assets. Techniques like fault tree and event tree analysis have been used to model risks before but unfortunately, they are ineffective when...

Read More
Impact of Disruptive Forces on Enterprise Architecture
Nov15

Impact of Disruptive Forces on Enterprise Architecture

Traditionally, the focus of Enterprise Architecture (EA) has always been a combination of both business and technology architectures. In the near future, this focus will gradually shift to business design or as many of us term it business transformation. This shift entails providing existing architectural as well as new advisory services to the enterprise. EAs will not only limit their advisory services to traditional enterprise architecture domains (business, information, application, technology) but rather will engage further in driving change along strategy, market, product / services and capabilities. Below are some of the key trends we are witnessing right now: Disruptive forces like social media and mobility have major impact on enterprises Unlike before, changes to business operating models is more frequent now The shelf-life of business architecture models and artifacts is shrinking fast Understanding capabilities is central to managing impact of disruptions Unlike before, enterprise architects will increasingly focus on business design A new architecture role focusing on business design is slowly emerging Disruptive forces like social, mobility, big data, cloud, gamification etc. typically have the following characteristics: they bring along innovation, they open up new markets, and finally expose new value networks. These combined characteristics of disruptive forces eventually displace earlier offerings and technology from the existing market place. Typically, we should view disruption as a force that rips through an existing market by creating a new market altogether. Apparently, most disruptive forces tend to be “digital” or “technical” in nature mainly because they accelerate disruption by providing new and faster access channels that empower consumers and improve market penetration. In the early days, we used to believe “differentiation” alone creates a competitive advantage for enterprises. While competitive advantage may have been good enough in those early days, it is no longer adequate for enterprise that wish to dominate a market place by creating uncontested markets and making competition irrelevant. Unfortunately, differentiation on its own does not cause “disruption”. In essence, you would need a combination of both differentiation and low cost to emerge as a dominating force. In fact, to be successful, you would need to sustain the state of dominance. If you explore most existing EA practices, you will notice the focus has been blueprinting enterprise at people, process and technology layers. Unfortunately, disruption does not only occur in this layer. Typically, disruption occurs at a much higher or contextual layer where we define business operating models or as most of us term it target operating model (TOM). Very few EAs have attempted to include in their scope business motivation (strategy) and business value (value chains and networks) layers.  The absence of these layers in their...

Read More
Grave Mistakes Enterprise Architects Should Avoid
Nov09

Grave Mistakes Enterprise Architects Should Avoid

However much we try to deny it, it seems the good old days for EA are almost over! If you doubt, then try looking around for an EA practice that isn’t struggling for survival; I bet a handful if none at all! Just before the recent recession, EA practices thrived very well; the concept was well understood, everyone was singing the praise; almost all mature organizations had established the practice; its practitioners were in demand;  the practice almost never got questioned; its promises were convincing; it seemed to have been well integrated into organizations; few decisions would be taken without its engagement; funding its charter was never a problem; it seemed to have had an iron fist control over most project decisions; and most of all, business was utterly convinced this was the missing link between strategy and execution.. At the same time, some critics were increasingly raising the alarm by questioning the actual returns on investments (ROI).. they were not convinced with the promises it had in stock; they questioned whether these promises were realistic and achievable; some argued the practice was just another hype created by smart marketers? Well, I will leave you to decide… All said however, the real acid test needs to be overcome; EA practices must reap the promised value like standardization, rationalization, transformation, reuse, cost-savings, profitability, rejuvenation etc. Unfortunately only a handful will survive this test; as a ripple effect, unless major pitfalls are avoided, I predict more and more EA practices will soon be closing down… But why and whom should we blame for this? Well, I believe the answer lies within the execution of the practice and the maturity of its practitioners… or is it? Without much renunciation, most of us have learnt a great deal of lessons after the recent slump. I have dedicated this blog to highlight some of the grave mistakes EAs should avoid. Executing without Scope: Executing your EA practice without a clear scope is akin to delivering unwanted products and services. Often than not, this leads to delivery of numerous piece-meal outcomes that seldom contribute to measurable results and fail to add value to business. Apparently, you are likely to be in this situation if you are struggling to gain stakeholder buy-in. Although EA is a platform with many possibilities, it is always good practice to define a clear scope that articulates your EA accountabilities and provides clarity on the expected EA contributions. Before embarking in the journey, take time to define and communicate your EA charter. Communicating without Buy-In: Many EA practitioners think awareness sessions are adequate to gain stakeholder buy-in and commitment. Awareness sessions...

Read More
Leveraging Target Operating Model to Define Future Business Blueprint
Oct15

Leveraging Target Operating Model to Define Future Business Blueprint

As I was grooming my business architecture skills several years ago, I realized the importance of the “Target Operating Model” (TOM) when defining the Future Business Blueprint. Occasionally, I come across architects who fail to recognize TOM as the bridge between Business Strategy and Future Business Blueprint. Most of them consider TOM and Future Business Blueprint to be the same thing; they are similar but different. Although Business Strategy communicates “what” the future vision is, it stops short of articulating “how” the future of the organization would look like. To some extent, organizations “translate” Business Strategy into Operational Plan which details the annual activities and initiatives to be executed. But how do organizations “illustrate” the future vision without diving into details? Well, this is where the “Target Operating Model” (TOM) comes in. A Target Operating Model (TOM) is a conceptual representation of an organization’s desired end state that describes the “functional structure” and “working style” required to fulfill the future vision. It illustrates the organization’s vision using a simple model that describes how it plans to deliver services to stakeholders i.e. it shows how an organization creates, markets and delivers value to customers, employees, shareholders and partners. In essence, a simple or basic TOM would consist of vital business functions, key business stakeholders, core business offerings, primary business locations, and key business interactions. Okay, we know what TOM is, but how does it benefit us? Well, TOM finds application is several areas but organizations mainly use it to achieve the following outcomes: Communicate future vision Inform future business blueprints Identify operational gaps Assess impact of changes Determine future capabilities Establish business priorities Market business transformation Inform organization structure design Inform annual operational plans Justify proposed investments Since TOM is shaped by an organization’s vision and mission, it is usually developed during the last phase of the strategic planning process. The responsibility for developing the TOM is usually with the leadership team which depending on circumstance may opt to hire external consultants or engage an in-house team comprising strategists and architects to deliver it. Apparently, the challenge is not in defining the TOM but its actual realization which obviously requires time and patience as it is often constrained by an organization’s capacity, capability and appetite for transitional changes. To support this lengthy process and govern the smooth transformation towards the TOM, guiding principles (strategic and design) should be defined; these principles inform the decision-making process when prioritizing, selecting, funding, aligning, and optimizing transitional changes. Perhaps this is the point where architects lock in and start leveraging TOM to define the future business blueprint (capabilities, processes, functions, services, etc.). So how...

Read More
Key Considerations for an Effective Enterprise Architecture Approach
Oct10

Key Considerations for an Effective Enterprise Architecture Approach

Several years ago while I was explaining the value of EA to an executive, I was asked a thought-provoking question that is still an interesting subject of debate amongst architects. I was asked whether an EA practice should start with the current state and then analyze future state or focus on the future state and then analyze the impact on the current state. He was of the opinion that since his organization already had a target operating model (TOM) and was considering EA as a means for driving the transformation, it would make more sense to focus on elaborating the future-state. This is a key concern for many other organizations that seek to create immediate value out of their EA initiatives. Yes, it is true both of these or combinations of both approaches are valid but what you choose should help you achieve objectives and produce required outcomes. The bottom-line here is that there is never going to be a one-size-fit-all approach as we deal with different circumstances all the time. So what considerations should you give before selecting one of these approaches? In my opinion, some of the factors that should be considered when selecting your approach include the following: Primary goals or purpose for setting up EA practice Clarity of the organization strategy and vision Key organizational challenges to be addressed Nature of initiatives that benefit from EA Organization culture, maturity and readiness Availability of sufficient current-state information Current State First The ability to quickly and effectively structure and document the elusive current state is a key selling point for EA. Organizations face difficulties understanding impact of change to business operations and so it is always advisable to focus initial effort on documenting and communicating the current state.  Whenever changes are proposed, emphasis is placed on performing impact analysis in order to enhance decision-support. Having such a capability is definitely something that every organization craves for and as such most EA adopters welcome the idea primarily because change is inevitable and costly to organizations. However, achieving this level of maturity is only possible if careful consideration is given to documenting important current state areas prone to frequent changes. Likewise, the presence of current state on its own isn’t good enough if proper impact analysis tools are lacking. So if you position your EA practice this way, then starting with current state may be the best approach to consider. Future State First Successful implementation of change must be driven by objectivity which could be lacking if you only rely on the current state. Your organization needs to have a proper vision before initiating value-driven change. If you do...

Read More