For innovation to be valuable to an enterprise, it must have real tangible business impacts and be well positioned within the organization. Linking it to the underlying enterprise architecture (EA) demonstrates how ideas have evolved. Enterprise architecture needs to be able to address real innovation. If the architecture changes, what effect does this have on innovation and its related strategies? Innovation management and enterprise architecture go hand in hand. Although each can be successful in their own right, it’s when they are used in conjunction with each other that the full benefits are realized.
To help establish the linkages between enterprise architecture and the innovation management process better, my recent Executive Report presents an integrated process view to connect EA and innovation management. The integrated process view comprises three distinct views: (1) the innovation management process at the top, (2) the innovation funnel in the middle, and (3) the EA role at the bottom.
In this Advisor, I describe in detail some of the tools and techniques that enterprises can use and adopt in the innovation management process. With the use of these tools and techniques, the innovation team is able to move through the process with additional ease and insights. There are, however, several consistent challenges that exist within enterprises that connect to the phases of the innovation management process. The collaboration between the innovation team and the enterprise architect can help mitigate many of these challenges.
Capability Roadmaps
In most enterprises, capability roadmaps are strategic, planned documents that outline an organization’s long-term view or its core capabilities. Generally, a capability roadmap is a five-year projection of the strategic capabilities, albeit many enterprises are moving toward 12- and 18-month views that drive an organization’s growth, competitive edge, and market share.
Capability roadmaps are also the foundation of strategic investment plans and enterprise architectures. As such, preventing the redundancy of capability roadmaps is a top priority, and managing capability roadmaps is a vital corporate competency.
For the innovation team, this document is critical to understanding the timing and impact of the ideas that come through the innovation funnel. Ensuring that the ideas are supported throughout the innovation management process is one element of success, but ensuring that the scaling process is timed appropriately and introduced into the capability roadmap to show its interdependence with other capabilities either being implemented or transformed is just as critical.
For illustration purposes and because most enterprises have a digital business strategy, Figure 1 highlights a couple of examples from the Corporate Executive Board’s Capability Roadmap Builder service.
Figure 1 — Examples of capability roadmaps.
Existing Capability Overview
The existing capability overview can be a useful tool to determine how capabilities complement each other and the value stream that exists when capabilities are coupled together. In Figure 2, we look at a standard gas and oil organization. Using this view in the innovation management process, the architect can now begin to describe at this level, and subsequently deeper levels, what the capabilities of the organization currently look like and how the introduction of new capabilities or the replacement of capabilities can impact the enterprise.
Figure 2 — An example of capabilities in an oil and gas company.
Once the target state has been defined, the architects can build a case with business leaders and execution teams that connects the intended or desired target state with the planning/definition part of program development.
In this example, the organization has laid out its capabilities across two axes. The first being the type of capability, its position within the organization, and its relation to corporate, operations, development, and acquisition functions. It also defines an axis to segregate capabilities related to its value chain, with some in the upstream part such as the ability to extract oil from the ground separated from the step of prospecting for new oil for extraction.
Second, an area has been defined having to do with manufacturing and refining processes, and lastly with marketing, sales, and trading capabilities. From this departure point, an architect can now determine which of these capabilities is going to be impacted by any potential change introduced by the innovation team, and double-click on them to understand what business processes, systems, and technology capabilities need transformation. With many organizations that undergo multiple transformations at the same time, the architects can also determine any interdependencies across these capabilities and take into account any issues and risks, making the likelihood of success that much greater. Once the target state has been defined, the architects can build a case with business leaders and execution teams that connects the intended or desired target state with the planning/definition part of program development.
Reference Models
To allow architects the opportunity to document the target state of the enterprise, it is important for them to maintain an up-to-date reference model that shows the current state of the enterprise and where transformation is already underway. In other words, a reference model connects the enterprise architecture. In traditional EA groups, this reference model is updated on a recurring basis — both in areas of transformation and where no transformation is occurring — and leads to wasted architecture resources and stale documents that are never used. Instead, EA should focus on updating the reference model in only those areas where transformation occurs and makes progressive updates over time. A reference model is an abstract framework or domain-specific ontology consisting of an interlinked set of clearly defined concepts produced to encourage clear communication.
A reference model can further represent the component parts of any consistent idea, from business functions to system components, as long as it represents a complete set. This frame of reference can then be used to communicate ideas clearly among members of the same community. They are often illustrated as a set of concepts with some indication of the relationships between concepts.
Detailed Existing Capability Catalog
A detailed existing capability catalog is an organized and curated collection of any and all business, operations, and IT-related capabilities and services that can be performed by, for, or within an enterprise. The capability catalog acts as a knowledge management tool for the employees and consultants of an enterprise, allowing them to route their requests for and about services and services-related topics to the subject matter experts who own, are accountable for, and operate them. Each capability or service within such a catalog is usually repeatable and has controlled inputs, processes, and outputs.
A capability catalog also allows the innovation team, leadership, and management (e.g., the COO) to compartmentalize the enterprise into highly structured and more efficient operational units; hence, the descriptive phrase "a capability-oriented enterprise.”
Figure 3 is an example of such a capability catalog. It builds on Figure 2 and shows a more detailed catalog view of an oil and gas enterprise.
Figure 3 — Example of a detailed existing capability catalog.
Here, the high-level capabilities are broken into more specific capabilities and services that currently exist in the enterprise. Having this view allows the innovation team and enterprise architect to position any new ideas and to determine if the current idea is cannibalizing any existing capabilities.
Target Architecture (Business Model Canvas)
Typically, the target architecture is a master plan for the enterprise similar to the master plan found in the process of city planning. In that context, the architecture is intended to lay out the overall “city” plan based on and in the context of the enterprise. The context is intended to influence the business mission and vision in the business strategic plan. For innovation teams, it is important to understand the overall target architecture and, specifically for the innovation process, to develop lightweight architectures that show the implemented idea. The target architecture can function as the high-level plan for the relationship between the business and the operating model, the relationship between the business and information (the data architecture), and the relationship between the business and technologies (the technology architecture). Although it is high level, the target architecture translates the business’s strategic plan into architecture planning, which is vital to the enterprise’s overall direction. One example of how innovation teams and other enterprise teams document a target architecture in a practical and realistic way is through the Business Model Canvas. In Figure 4, the key elements of the Business Model Canvas are displayed awaiting the innovation team to complete it.
Figure 4 — Target architecture (Business Model Canvas).
The target architecture is, however, not the complete and logical architecture design blueprint some may think of it as. To remain influential, useful, and informative, the innovation team must look for high-level master plans rather than a detailed solution. Target architecture is not equal to enterprise architecture. Rather, EA is the effort to see the whole by preserving enterprise knowledge, learning from the experience of others, and enabling agility and planning for the future. Target architecture is part of EA in regards to planning for the future. Target architecture, as the master plan, serves as the overall framework for the idea implementation. It is not possible to achieve the entire target architecture in a great leap. It can only be accomplished through a divide-and-conquer approach to each segment in which the solution architecture can be designed into a manageable chunk. The priority and sequence of the segments in the target architecture plan are based on business performance, on the need to address weak spots, and on the new direction of the enterprise’s business strategy.
[For more from the author on this topic, see “Enabling Enterprise Innovation Management Through Enterprise Architecture."]
