Category: Topic 7 – Evaluating Emerging Technologies

In ENTR 810 Emerging Trends, Technology, and Corporate Innovation, we examined several tools that can be used to by EA to evaluate emerging technologies as well as help manage the risk/reward trade-offs that come with technology innovation. Below is a summary of these tools and how they can be applied to the practice of EA (Coughlan, 2018).

The hype cycle and S-curves help to provide context on the technology lifecycle in two primary dimensions: the relative cost or effort (i.e. time & money) of the technology, and its efficacy for solving real-life problems or use cases; however, each model uses slightly different dimensions. The S-curve measures two dimensions: ‘Effort’ on the X-axis (i.e. time & money) and ‘Technical Performance’ on the Y-axis. The S-shaped curve that results describes how at the beginning of a technologies life there is there is a great deal of investment with relatively little performance improvement until some tipping point in which the performance increases dramatically. Finally, at the end of a technologies life, the performance improvements become less distinguishable and then plateaus. Graphically, this curve takes the shape of a flattened “S”, hence the term “S-curve”. As is often the case, a parallel S-curve is developing for the technology that will eventually overtake the obsolete technology. For example, the PC was largely replaced by the laptop, which is now being overtaken by the tablet. These could be modeled by three separate S-curves with each one higher and to the right of the previous.

The hype cycle also provides a picture of the technology lifecycle, but in slightly different dimensions with ‘Time’ on the X-axis, and ‘Expectations’ on the Y-axis. This is referred to as the ‘hype cycle’ because the emphasis is on the expectations of technical performance in the marketplace. It has four primary stages: Innovation Trigger, Trough of Disillusionment, Slope of Enlightenment, and Plateau of Productivity. Whereas the S-curve is more focused on the maturity of the given product in terms of positioning in the marketplace, the hype cycle helps decision makers assess the benefits of a new technology in the context of their specific industry given their tolerance for risk.
Both of these measures help to provide context for a particular technology in terms of the potential risk and reward. From an investor’s perspective the higher the risk the greater the reward, so the investor is keen to select technology investments that are early in the S-curve. For the technology company looking to innovate in the market, they need to understand the technology life-cycle and the implications it has on the valuation and target market. Finally, from a technology management perspective, understanding where a technology is in the hype cycle comes to bear in the decision making and timing around the adoption. Take for instance the introduction of the iPhone, early on the iPhone differentiated itself in some key features (e.g. touchscreen), but failed to provide some features we now consider to be essential (e.g. GPS).

A best practice for Enterprise Architecture (EA) is to approach innovation from a technology management perspective. Part of my job is to manage the roadmap of technology adoption. Understanding where a technology is in the hype cycle comes to bear in the decision making and timing around the adoption and helps to prioritize R&D investment. The key to adding value as an EA is the ability to understand and anticipate what problems the organization is going to have in the next 2-5 years. Like Wayne Gretzky has been quoted as saying, “A great hockey player plays where the puck is going to be” (BrainyQuote, n.d.). By using tools such as the Gartner hype-cycle analysis, we can develop an understanding of what technologies to prioritize for investment (i.e.time & money) so that when the need arises we have a complete/partial solution, that is ready to incorporate into the operating environment.

Coughlan, C. (2018, September 17). ENTR 810 Emerging Trends, Technology, and Corporate Innovation.

Wayne Gretzky Quotes. (n.d.). Retrieved from https://www.brainyquote.com/authors/wayne_gretzky

The business capabilities provide a common language for an organization. As a central focus for communication and collaboration across many business units, business capabilities views offer stakeholders a common understanding of the business gaps that need to addresses. Once a shared understanding of the business is established it can be used for planning and executing business/IT transformation efforts, and help to mitigate some of the resistance encountered when undertaking the development of the Enterprise Architecture.

In Developing Enterprise Architecture via Business Capabilities (Vaessler, 2015), the author outlines the principles that provide business capability modeling such a unique and powerful approach to collaboration and contributing to a shared understanding of the business:

1. Business Capabilities define WHAT a business does, not HOW a business does something.
2. Business Capabilities are nouns, not verbs (e.g. investment management).
3. Business Capabilities are defined in business terms, not technical terms.
4. Business Capabilities are stable, not volatile.
5. Capabilities are not redundant.
6. There can be only one Business Capability Architecture view for a business.
7. Business Capabilities map to but are not the same as, a LOB, business unit, business process, or value stream.
8. Business Capabilities have relationships to IT deployments and future-state IT architecture.
9. Automated capabilities are still business capabilities — not IT capabilities.
10. Capabilities are of most value when incorporated into a larger view of an enterprise’s ecosystem.

One way to apply this approach is to (step 1) use the business capabilities view to build a reference architecture of the target-state or Business Capability Architecture (BCA), and then working backward to identify which capabilities should be prioritized to achieve the goals of the transformation effort and a timeline of roadmap for achieving the target-state (step 2). Finally, if the business capabilities view and the roadmap help define the WHAT and the WHEN, the next step (step 3) is a conceptual or high-level view of the HOW which forms the architectural view of the organization or EA.

In the example provided by the author, to achieve this next step, the architecture team employed TOGAF’s concept of Architecture Building Blocks (See TOGAF 9.1 Section 37.2). Similar to business capabilities, ABBs are solution agnostics, and for that reason are helpful to remain focused on the problems to be solved (i.e. requirements) (Vaessler, 2015):

• They can represent the fundamental functionality of an area of technology
• They capture and represent architectural requirements
• They can interoperate and possess relationships with other ABBs
• They can map to business capabilities
• Their higher level of abstraction means that they aren’t required to define or reference any specific technology or IT product(s).
• They can be further decomposed into individual Solution Building Blocks (SBBs) once more is known

In this final step, a business capability (e.g. Customer Information Management) could be linked to the ABBs that comprise the architectural requirements and a blueprint of the future. In my experience the process described above is often skipped by going directly to a solution without a fundamental understanding of requirements and their implication for the success of the project; however, those EA groups that can do this successfully will win the support of stakeholders and contribute far more to the business outcomes with which they are concerned.