The Evolution of Tech@Core

In the beginning (circa 1970s), business and tech were separated by formality. Tech was the keeper of dark “secrets,” and business people didn’t want to become involved. The business people might sit still for a few requirementsgathering interviews, but then didn’t want to be bothered with all the techie stuff. On the flip side, tech was new and exciting, and the tech people were content to retire to their cubbyholes to perform their magic. They were excited about the technology, but not so much about business issues. This was the era in which many basic business functions—accounting, payroll, inventory control—were first automated. Tech enjoyed success in this phase, in what was deemed a “supporting role,” in great part because tech was fairly simple and the business applications being developed had well-known specifications.

The second phase of this history is labeled the “collaboration” phase. As business requirements grew and became more complex, tech became more complex as well. In turn, communications between business and tech needed to improve. During this period, formality in terms of sequential (or waterfall) development life cycles was introduced. This gave rise to the role of systems analysts (who later evolved to become business analysts), who tried to develop a more collaborative relationship with business application users. The systems analysts had more business process knowledge and involved business users during the requirements phase, but the business people still shied away from understanding the technology. Tech to them was still a big black box.

As technology evolved that enabled more business connectivity (online and then early Internet-based applications), tech/business boundaries began to blur and the third era of tech-led differentiation began. This era led to early tech disruptions, such as occurred in the financial industry with the rise of online brokerage firms like Charles Schwab. Tech began to move from the back office (accounting) to the front office (customer interaction). The technology was more complex and the application requirements more nebulous, leading to the need for closer collaboration between tech and business and better understanding of each other’s knowledge arenas.

But as business people became more tech savvy, their new knowledge made things both better and worse. Matters became better as business people began to understand how tech could make a real impact, but became worse because their tech knowledge was typically shallow. Frustrated by the slow pace of tech development, some business people began to create their own “shadow IT”—that is, they built their own applications using spreadsheets and other user-oriented tools on their personal computers, hired consultants directly without IT involvement, or purchased a SaaS application with their credit cards. They increasingly made ill-informed comments: “I can build a spreadsheet application in a week. Why does it take IT 9 months?” And they were serious. The fact that these spreadsheet apps often addressed only a single person’s needs, didn’t scale, weren’t maintainable, and created a security risk never crossed the users’ minds—their knowledge was shallow.

However, many of these apps delivered real value. From IT’s perspective, this problem was exacerbated by legacy system technical debt (still an issue) that had been building for years and acted (and continues to act) as an anchor on software development. In addition, the ballooning need for interactive systems split many IT organizations into legacy system and interactive system groups. Because the interactive technology was more complex and the requirements even fuzzier, development processes (waterfall versus agile) in the two IT factions evolved in different ways, causing increasing friction.

The fourth era, labeled Tech@Core, moves toward greater integration of the business and IT arenas. Among the factors that differentiate Tech@Core from the preceding phases are the following:

• Leaders³ understand the critical nature of tech to their business and are increasingly tech savvy (many are younger and never worked in the pre-Internet world).

  3. We will use the term leader for all types of leaders: executives, managers, and teams for both business and technical arms of the organization.

• Leaders depend on technology to create innovative customer journeys.

• Customer value replaces cost as the primary performance measure (fitness function).

• Speed and adaptability replace cost and efficiency as technology drivers.

• Tech knowledge and experience are continuously evolving.

• Leaders promote fast, frequent experimentation and learning, while maintaining the discipline to select and evaluate the right experiments.

• Reducing cycle time maximizes the value from learning.

ThoughtWorks’ 2017 report on courageous executives supports the first bullet point: “Courageous executives know grasping the ins and outs of technology matters: 54% have developed a deep understanding of technology and a remarkable 57% have written code.”⁴

4. Guo, Xiao. “The Next Big Disruption: Courageous Executives.” ThoughtWorks,July 20, 2017. https://www.thoughtworks.com/insights/blog/next-big-disruptioncourageous-executives.

The notion of “technology as the core of business strategy” is spreading to the next frontier. Businesses whose products are easily digitized (finance, media, telecommunications) and businesses that were about distribution and intermediaries (travel agencies and e-commerce) are already there. Now it is the turn of businesses that consider manufacturing to be a core competency (automotive), industries where knowledge has traditionally been the core capability (medicine, pharma, legal, research), and industries that are highly regulated (taxi, government, utilities).

Figure 2-1 suggests that the transition from tech in a supporting role to Tech@Core followed a linear progression. That’s not really the case. While large, long-term businesses will have portions of their technology assets in each of these categories, their overall approach to tech is the key. The term “core” is not used lightly here. It goes beyond technology being important or critical to your business to indicate that technology is your business. Unless this attitude truly permeates your business, whether your organization is a pure tech company like Google or one that manufactures garden plows, your chances of surviving the digital revolution are slim. But the evolutionary phases are also cumulative. Larger, long-running enterprises will likely have systems, people, processes, tools, and technologies in the latter three of these phases.

The second question asked at the beginning of this chapter was “Why is Tech@Core relevant to EDGE?” At its essence, Tech@Core is changing your fundamental view of technology from thinking about it as supporting your business to thinking about it as an integral, inseparable component of your business. At one level, the question seems almost irrelevant, given that we’re talking about transforming to a digital enterprise that embodies technology. However, we can’t make the point strongly enough that this chapter is not for the technical staff, but rather for both IT and business leaders. Your leaders and executives need to internalize the concept that technology no longer supports your business, but rather is your business. Understanding the components of Tech@Core should help with this internalization.

You may think that the phrase “technology is your business” overstates the case—and maybe so. But we need to overstate the case to state the case. No aspect of a business—from product development to manufacturing—survives without the other components. But the future—for many, many businesses—lies in becoming digital. And becoming digital is everyone’s job. The key question is, How do you accomplish this?

Developing a Technology Strategy

If your vision is to become a highly competitive digital enterprise in the next three to five years, then you need a technology strategy that contains the components required to make that transition. Furthermore, you can’t make the transition with a “more of the same” technology strategy and execution. A couple of cautions apply here. First, approach this task with your agile hat on. Agilists plan and they document, but they certainly don’t turn the process into a lengthy, document-centric one. Fast feedback, iteration, and learning are just as important here as in product development. Second, communicate and collaborate first and document second (or third).

Jim once worked with a telecom firm in the east. Its architects had developed extensive documentation full of diagrams and standards. When Jim talked to the development staff, he asked if they understood the architecture. “Nope,” they said, “the documents don’t make much sense to us.” When Jim talked to the architecture staff about how they communicated in person in the past or how they planned to do so in the future, their response was “We don’t have time to meet with them. We have to work on analysis and documentation.” Don’t fall into this trap: Everyone needs to keep an agile hat on, no matter what his or her task.

To broaden and strengthen your technology capabilities, you need to take the following steps:

• Shift your technology fitness function to speed and adaptability.

• Accelerate your technology edge over competitors.

• Maintain awareness and take advantage of technology shifts and trends.

• Develop a digital technology platform strategy.

• Reduce technical debt to increase speed and adaptability.

• Get your key tech staff involved and constantly improving their capabilities.

Embracing Tech@Core means keeping up with technology—a daunting task today. Which technologies do you monitor? Which ones do you experiment with? Which ones do you set aside? Which ones do you embrace? Fifteen years ago, few people anticipated the impact of cloud computing or big data or social media. At that time, a software tech stack (layers of programs to accomplish specific tasks) might have 5 components. Today, these stacks often exceed 15 components, further complicating your tech strategy to keep ahead.⁵ How do you monitor what might appear next on the technological horizon?

5. Highsmith, Jim, Mike Mason, Neal Ford. The Implications of Tech Stack Complexity for Executives. ThoughtWorks Insights, December 2015.

Embracing a tech strategy should not be undertaken lightly. However, it is clear that if your organization wants to become a digital enterprise and maintain a competitive edge, then embracing tech is a necessity. Do you really have a choice? Where are the bookstores, record stores, and film cameras of yesteryear? Why have so many retail stores closed or gone bankrupt (for example, Toys-R-Us)? If you still view digital technology as something the IT department is responsible for, you might as well start the countdown to your organization’s demise.

A tech capability strategy should be derived from your enterprise vision and goals. Your vision to increase tech capability might be as broad as “integrate technology into every aspect of our business” or as specific as “transform our product-line technology capability to adapt quickly to industry changes.” Clear capability goals also require new measures of success (measures of adaptability and speed): You can’t expect a different outcome if you keep old measurements.

As stated in Chapter 1, becoming a digital enterprise requires a change in fitness function, a change in the highest level of how you measure success in your organization. In the pre-digital world, the business fitness function tended to be return on investment (ROI). In the digital world, it is customer value. For technology, the fitness function is also undergoing a big change—from cost and efficiency to speed and adaptability. Make no mistake: These changes in fitness functions are monumental, but absolutely necessary to make the transition.

In the technology realm, speed and adaptability might appear to be conflicting goals. In some instances, they may require a tradeoff, but to a great extent they reinforce each other. Part of the problem lies in the existence of a project culture rather than a product culture. In a project culture, teams strive to deliver features based on a traditional schedule, scope, and cost objectives, knowing that long-term maintenance will be left to another team. This culture drives development staff to cut corners, to limit testing, and to take other shortcuts that negatively impact adaptability. The project culture also encourages leaders to define up front a set of expected features, and success is perceived as the number of features delivered within the specified time frame and budget, rather than in terms of how extendable and adaptable the product is. That said, there will always be projects, especially during your transition to a product mindset. Likewise, problems can also arise in a product culture,⁶ but it has a better chance of delivering continuous value over time.

6. Chapter 6, Building a Product Mindset, on developing a product mindset, further describes the differences between a product and project culture.

The technical debt chart (see Figure 2-4 later in this chapter) shows that software degrades over time in an exponentially increasing fashion. You need to adopt strategies first to avoid this degradation, and then to bring the curve down for existing applications. The key to pursuing speed and adaptability at the same time is to view software technology as a continuously evolving asset, instead of something that is built once and then maintained. Adding quality and cycle time to the mix of success measures helps ensure that new features of technology assets can be added over a long period of time.

In developing your tech strategy, you also need to analyze three types of time horizons—continuing the existing business, growing new opportunities, and experimenting with future opportunities.⁷ Time frames for these three horizons will vary from business to business, but a rough starting point might be one to two years, three to five years, and more than five years. These horizons will help guide investment decisions. Near-term objectives will probably garner more investment, and far horizons less, but all three horizons should be included in every budget cycle. These different horizons do need to be in different portfolios because they should have different measures of success, especially to ensure future endeavors receive enough funding.

7. For more information, see McKinsey and Company’s three-horizons model.

As long as your enterprise operates on a ROI fitness function, transforming it into a digital enterprise will be a nearly impossible quest. Finding out how to balance speed and adaptability, and how to foster both at the same time, will be a critical portion of your technology strategy. Finally, it is essential to get the technology part of your transformation right.

Seismic Shifts and Trends

Understanding seismic shifts and trends⁸ will help you develop an effective technology strategy. They are lenses through which you can view the changing business and technology landscape. You can also think of these shifts as a storyline that plays out over time as different aspects of the story unfold. Shifts also provide us with a container to organize trends that are more specific and detailed. For example, starting in the early 2000s, the “agile” wave ushered in a seismic shift in software development. Agile included specific trends such as Scrum, XP, test-first, and continuous integration. Examples from the 1990s include object-oriented (OO) programming and SmallTalk. OO programming was a major shift at the time and became a standard “method” of programming over time. SmallTalk, by contrast, was a specific language that attracted acolytes for a time but didn’t survive the introduction of other OO languages.

8. The material in this section was excerpted and revised from ThoughtWorks’ presentations and articles that we use internally and to advise clients.

Shifts and trends evolve together. Sometimes a series of trends indicate a seismic shift, sometimes shifts begin to emerge independently, and some trends don’t fall within a specific shift.

The organizations with successful [digital] transformations are likelier than others to use more sophisticated technologies such as artificial intelligence, the Internet of Things, and advanced neural machine-learning techniques.⁹

9. McKinsey & Company. “Unlocking Success in Digital Transformations.” October 2018.

For each shift and trend, you need to acquire, analyze, and formulate a variety of data:

• Signals: What are you seeing that is indicative of this shift?

• Business impact: How might this shift affect your enterprise?

• Horizon—what is the time horizon for the trends within this shift?

• Urgency: How urgently do you need to react to this trend?

• Technical impact: What capabilities will you need to implement your strategies?

• Actionable advice: What advice will you offer your enterprise on how to approach and use these shifts and trends?

An example is helping in understanding this shift/trend framework. The shift described as “Evolving Interactions” entails advancing from screen-and-keyboard to true “multimodal” interactions—that is, moving between speech, gesture, tactile, and mixed reality interfaces. Rapid evolution of these technologies and the “cellphoneization” of virtual reality (VR)/augmented reality (AR) will give us both better realism and cheaper hardware.

The following signals indicate that this shift is taking place:

• Increased accuracy of voice recognition technology

• More speech platforms (Amazon Alexa, Bing Speech, Google Cloud Speech API)

• Reduced costs for VR/AR headsets

• Emergence of a dominant AR/VR player in the market, as the trend becomes real

The “Evolving Interactions” trend may potentially impact your business in the following ways:

• Growing consumer expectation of chat bots, intelligent agents, and “live” interactions

• Major bot/speech/artificial intelligence (AI) players—Apple, Google, Facebook, Amazon, Microsoft—that heavily disrupt digital engagement strategies

• Potential disintermediation of end-user suppliers given access through Siri/Alexa

• Delivery of functionality becomes more complicated than ever—exploding number of channels, Omni channel++

This trend may also impact on your technical capabilities:

• Skills and capabilities (but you might not need to know it all—how to buy instead of how to build)

• Can you possibly hire enough designers?

• Design capabilities evolve: you need multimodal interactions, and interaction design in space instead of on a screen

• Speech and image recognition technology

Actionable advice consists of more granular advice than the business impact statements just presented. Examples of advice for AR/VR/machine learning (ML) and machine learning/AI might be:

AR likely has a bigger impact than VR. Understand if this is true for your business, the likely business impacts of these technologies, and get involved in the global community.

Ensure prerequisite capabilities are in place, including data engineering and management of large data sets. Then consider how ML and AI can be applied in business contexts.

One approach we have found useful in looking at tech trends is to plot each trend on a chart like Figure 2-2, with the time horizon on one axis and the urgency of action on the other axis. In this chart, the urgency horizons are named a little differently than those on McKinsey and Company’s three-horizons model, as they indicate the visibility of the technology rather than an investment category. Investment categories need to include your time horizon as well as other factors. Often, the fuzzy future gets sacrificed to the more tangible needs of the present. Determining the balance between investing in the now, the near future, and the far-off horizon needs to be accomplished at the executive level, and having a visual aid like Figure 2-2 can assist in that process.

Seismic shifts and tech trends could significantly alter your business plans. If you can understand what these shifts and trends are, early in their life cycle, you may be able to get out in front of them and use them to your competitive advantage. Then again, you might get too far out in front and suffer the consequences. Sometimes you cross over from the leading edge to the bleeding edge—Google glasses spring to mind as an example. Every organization needs to figure out just how far to push into its technology crystal ball gazing, trying to balance going far enough with going too far. The faster the pace, the more critical the timing and use of experimental practices become.

Creating a Tech Radar

A tech radar is a tool to foster discussions about technology trends and how they might benefit your enterprise. Figure 2-3 shows a sample quadrant of a recent ThoughtWorks radar.¹⁰ This radar focuses on software technology, but depending on your business you might have several such radars for different technologies (materials or medical tech, for example). The figure shows one of the four quadrants—techniques, platforms, tools, languages, and frameworks. The location on the rings of the radar indicate actions—adopt, trial, assess, hold.

10. For the latest full radar, go to the ThoughtWorks website: www.thoughtworks.com.

• Adopt: Ready for use now. It has been proven through use on projects and general industry acceptance.

• Trial: Ready for cautious use. It is not completely proven, so use on carefully selected initiatives.

• Assess: Up and coming. It should be followed closely and used experimentally.

• Hold: Getting industry attention but not yet, or maybe ever, ready to use. It may be flawed, and might be viewed as something to avoid.

Probably the most important factor in building a tech radar and evaluating technologies is blending analysis with actual “use.” While there are four actions on the radar, a couple of preliminary activities also exist: survey and investigate.

Survey is the process of identifying new technologies by gathering information from conferences, conversations, social media, analysis firms, professional papers, books (although books don’t often come early enough), and Internet articles. This is the awareness stage—the point at which someone says, “Ah, we haven’t heard about this before.” This is the stage where you choose to go onto the next level or discontinue interest. After all, no one can afford to elevate every new technology to the next level of scrutiny.

At the investigate level, you continue gathering information from the sources mentioned previously and expand the search to include early adopters’ experiences. In this activity, you are trying to answer questions about both business and technical viability. While the survey stage identifies something new, the investigate stage provides enough information to warrant potential addition to the radar.

“Could be a long week … Tech Radar creation, first session, blips unfiltered so far. Amazing how much changes in tech in 6 months!” (Tweet from Mike Mason, Head of Technology for ThoughtWorks, during an early 2018 Radar update session)

In the assess stage (or action), you begin to try out the technology, mostly on internal experiments within the technology organization. At this point, you are assessing technical viability, rather than business viability. For example, you might play around with VR equipment to get a feel for the technology and its maturity. You might think about how it could be applied to your business, but wouldn’t experiment with it yet.

During the trial stage, the technology could be used on carefully selected, and probably smaller, business initiatives. These trials should help determine whether the technology might move ahead to full adoption. You would continue to gather information from other users during this time to determine the pluses and minuses of the technology.

Once sufficient data is gathered from the trial stage and industry usage increases, you can then adopt the technology for wider use within your organization. Several factors, including how you can develop your capability (or buy it), influence the adopt decision.

At each of the levels, you ask critical questions relative to advancing the technology to the next level. Only a few will make it through each stage: Some will be abandoned, and some placed into a hold status. You need to limit work-in-progress (WIP) for each stage. Limit the number of things you’re assessing or trialing at any one time, and make it clear to teams if another team is already assessing a technology so they can quickly ask and learn how that trial is going. This might be considered a kind of governance for learning.

Reducing Technical Debt

If your enterprise has been in existence for some time and has a large investment in legacy systems, how you manage technical debt will be a significant component of your technology strategy. Technical debt is the degradation of technology over time due to a lack of investment in maintaining adaptability and quality. It is similar to having a car that is not maintained, not even with oil changes, and therefore degrades over time—slows down, won’t start, leaks oil. In software, developers may be forced to take shortcuts to make deadlines, testing isn’t always rigorous, and periodic quick “fixes” can degrade code quality. Over the years, many legacy systems have delivered value to the business, but their technical debt accumulated to the point that even seemingly minor enhancements became difficult and time consuming. Figure 2-4 shows how this kind of degradation starts out slowly, but then accelerates as time passes.¹¹ More than a few legacy systems are now essentially unmaintainable. In the early days, changes are relatively easy. As technical debt grows, the answer to the question, “Do we implement new features or do we reduce technical debt?” is, of course skewed to new features. After a few years of ignoring technical debt, enhancements can take forever and you are faced with three equally bad options: rewrite the application (which is expensive and very risky), do nothing (and the problem gets worse and worse), or work toward reducing the technical debt systematically over time.

11. Highsmith, Jim. Agile Project Management: Creating Innovative Products. Boston: Addison-Wesley, 2010.

A second problem with legacy systems is the difference in delivery cycle time between digital experience and legacy development groups. In less turbulent times, the fact that one of these groups was agile and operated on two-week delivery cycles and the other used traditional methods and operated on nine-month delivery cycles was a nuisance, but not debilitating. Today, that difference in delivery cycle time increasingly causes big problems. This disconnect is compounded by differences in release cycle times, particularly when continuous delivery is used in one case and not in the other.

Organizations are caught in a dilemma years in the making: Redeveloping the systems is too time consuming and risky, but building new digital assets depends on upgrades to these systems. Finding solutions to this dilemma—finding creative ways to revitalize these legacy systems by wrapping, selective revisions, and automated testing—becomes a critical piece of building new digital assets.¹²

12. For more on reducing technical debt, see Earle, George, and Mike Mason. “The Business Imperative to Modernize Your Tech Estate.” ThoughtWorks Insights. https://www.thoughtworks.com/insights/blog/business-imperative-modernize-your-tech-estate.

Investment Decisions to Revitalize Core Enterprise Systems

You need to get creative about how to invest limited resources to revitalize core enterprise systems. An obvious choice, rewriting these systems, is an expensive and usually high-risk strategy—one to be pursued carefully. Fortunately, a wide range of options between doing nothing and rewriting are available—migrating to a services architecture (including microservices), evolutionary architecture, decoupling and wrapping, employing continuous delivery, and more.

It won’t be enough to just get the delivery model right. Another reason why operational efficiency has taken priority over operational agility is the investment classification systems used in many enterprises. A number of classification schemes are used today, but they generally follow along the lines of that offered by MIT’s Computer Information Systems Research group: infrastructure, transactional, informational, and strategic. In this scheme, perhaps 10 to 15 percent of the portfolio is deemed “strategic” and the rest is thought of as core enterprise systems, those where efficiency is king.

The need for agility in the Digital Age extends far beyond “strategic” systems, and revamping investment buckets is one way to emphasize this scope. What if we revise the scheme to reflect the new Digital Age reality, by including customer experience systems (a mobile app), customer experience support systems (order processing), internal support systems (accounting), and infrastructure (servers)? If we think of a scale that ranks needs from efficiency (1) to agility (5), then customer experience systems might need to be a 5, customer experience support systems a 3 or 4, internal support systems a 2, and infrastructure a 3.

Removing Friction

Friction is usually considered as resistance to movement, but it can also be considered as a conflict between people. Whether it is described as resistance or conflict, friction slows us down. When you are blasting down a ski slope on a mountain bike in the summer, friction can be a really good thing. However, friction within or external to a software delivery team isn’t a good thing. Using self-sufficient teams reduces the friction between organizational units that would otherwise slow decision making. In software delivery, the friction between software development and operations organizations can slow the process to a crawl. The practices in DevOps have greatly reduced this source of friction. These practices are both organizational and technological—from using continuous integration technology to bridge the organizational gap between development and operations.

Friction can also arise from using the wrong technology for an initiative. Frequently new initiatives are forced to use inappropriate technology because of existing standards. For example, some early big data initiatives floundered because organizational standards required the use of traditional relational databases to manipulate unstructured data. Another example would be using a very heavyweight message queue implementation when something very simple would do nicely.

Agile practices encourage teams to deliver deployment-ready code every iteration and even deploy code if the team uses continuous deployment. One easy metric that provides an indication of how far away from that goal a team might be—essentially an indicator of how much friction is in the development process—is “the tail,” referring to the time between freezing code development (it’s never completely frozen) and product deployment. During this period, non-agile teams continue testing (especially integration), bug fixing, performance analysis, operations preparations, and more. Often we have encountered “tails” of 3 to 6 months or more in a 12-month deployment cycle. The longest tail we encountered was 18 months from “code complete” to deployment! As agile practices are implemented, you can watch this “tail” decrease as a measure of progress.

There are many ways to reduce friction that focus on removing barriers to faster delivery and improving adaptability. Another option is to correct the false tradeoff between speed and quality.

When you trade off more features for less quality, it’s usually for a single release occurrence, not for an aggregation of releases over time. This practice is an outgrowth of waterfall development, in which intervals between releases were long, often a year or more, and trading new features for lower quality (say, poor design or less testing) obscured the cost and pushed consequences far into the future. When you have a large batch size (hundreds of features) and a long time frame (a year or more), the next releases (small maintenance or enhancements) are so trivial in relation to the first release that the feedback or impact of low quality is very difficult to determine.

In a waterfall project, it is easier to cut refactoring, for example, because the impact is felt in the future, when engineers feel the pain of technical debt and customers feel the pain of lengthy delivery schedules. Cycle time measures are irrelevant when release cycles are too long. However, as agile teams reduce delivery cycles to months, weeks, and days, the impact of poor quality becomes much easier to determine. When a team is running one-week deployment cycles, the effects of poor testing in one cycle may pop up quickly, in the next cycle or two. Poor design in one cycle begins to retard feature delivery in the next few cycles, so that the consequential feedback comes in a few weeks. If a team is measuring both feature throughput and cycle time, either or both can suffer quickly from software quality mediocrity.

Building an Asset Ecosystem

An ecosystem is a system or network of interconnecting and interacting parts. For example, the Apple iPhone thrived on an ecosystem of the hardware, operating system, and software developers and their “apps.” We might also add the word “interdependent” to the definition of an ecosystem. Assets we think about in a platform strategy are data, hardware, software, capability, and thoughtware. Companies that grew up as digital companies—think about Google, Airbnb, and Netflix—have considered their platforms as ecosystems from the beginning. Similarly, they have built their digital platforms as strategic assets.

For long-time organizations with high technical debt, a strategy to rewrite existing software applications won’t work—it’s just too expensive. Plus, rewriting without making the necessary technical and organizational transformations is a waste of money. Your strategy needs to be a well–considered “layered” strategy where the layers are time. In 1995, Stewart Brand wrote an interesting book titled How Buildings Learn: What Happens After They’re Built. Brand’s premise was that the layers of a building change over time, at different rates. He envisions six building layers: site, structure, skin, services, space plan, and stuff. The structure, for example, changes at a very slow rate and is expensive to change; services (air conditioning and heating) change every 15 to 20 years and are moderately expensive; and stuff (furniture and fixtures) changes frequently and is inexpensive to change. Thinking of change in layers of time will assist you in tech strategy development.

As mentioned earlier, this analysis should be done in the spirit of agility—not an exhaustive analysis, but just enough to guide decision making. One of the tasks you need to complete is to determine a strategy for your key technology assets or asset classes. This analysis includes three components, shown in Figure 2-6: (1) determining the asset classes’ impact on Lean Value Tree (LVT) goals, (2) speculating on the rate of change of this area of the business, and (3) determining the current adaptability of asset classes.

First, look at each asset class and determine how integral this asset class is to implementing goals across the LVT:

• Impacts many goals (customer assets, for example)

• Impacts several goals

• Impacts very few goals

Second, for each business capability or product line, you need to anticipate the future rate of change:

• Extremely volatile

• Volatile

• Moderately volatile

• Relatively stable

Obviously, this analysis will be subject to change as the future unfolds, but making a relative assessment like this will help you develop an asset management strategy. Until you experiment with actual measurements such as cycle times, relative comparisons will be adequate. Especially for organizations with huge investments in legacy systems, prioritizing adaptability investments is critical.

The third stage of the asset analysis is to estimate the relative adaptability of each asset or asset class.

• Highly adaptable—relatively quick and inexpensive to change

• Adaptable—moderately expensive and time consuming to change

• Somewhat adaptable—difficult and expensive to change

• Not adaptable—very expensive and time consuming to change

Having these three estimates of the need to adapt, the rate of change, and the ability to adapt helps to determine strategy. For example, an asset that is critical to implementing a number of goals in an extremely volatile business environment and whose adaptability is very expensive and time consuming to change is obviously on the “critical” list. An asset whose business environment is relatively stable, that is used in only one goal, and whose adaptability is expensive and time consuming would have a very low priority.

This kind of asset analysis is particularly important when you are prioritizing legacy systems that support Business as Usual (BAU) and trying to reduce technical debt.

Experimenting

One of the premises of EDGE is that adaptation requires experimentation, and for that experimentation to succeed, you need an experimental mindset, an experimental process, and experimental tools. Rather than planning, which indicates a prescriptive solution, you need to think of the future in terms of hypotheses about the future. You then test those hypotheses with short-cycle experiments.

The cultural mindset is one of exploration—that you can’t know everything in advance and that significant deviations are the norm. The cultural aspects of experimentation are covered in more depth in Chapter 10. The second requirement is an experimental process, which for the purposes of this book is an enhanced version of agile. The third requirement is that you need a platform, the right technology components, to experiment rapidly. These components need to cover the entire development life cycle, from spinning up development environments rapidly to effective continuous integration tools.

You need these technology components for every type of development— legacy back-office systems, online applications, mobile applications, big data and analytical systems, and applications with an Internet of Things (IoT) piece.