C H A P T E R 1

Introduction

As Marc Andreessen wrote in his Wall Street Journal op-ed [6], software iseating the world. For industry after industry, investment in software R&Dis increasing and the software in products, rather than the mechanics andhardware, defines the value. Thus, software plays an increasingly central rolein the modern world. In virtually any industry there are examples of softwareenabling new business models, novel applications and unprecedented efficiencyimprovements. Of course, well-known companies such as Google, Facebookand Spotify are entirely driven by software. But even for a Volvo truck, morethan 70% of all innovation is now driven by software.

With the growing importance of software for the industry, the size of thesoftware in systems has been going up accordingly. According to Ebert andJones [26], the size of software increases with an order of magnitude (10x!)every five to ten years. This leads to several strategic challenges for the compa-nies delivering these systems. First, we see a marked shift in R&D investmentfrom the mechanical and hardware parts of systems to the software parts. Inseveral of the companies that we work with, we have witnessed the investmentin software R&D going up significantly (sometimes dramatically) at the ex-pense of investments in other fields. Second, as the size of the software goes upand companies have a tendency to keep using the same development models,the cycle time of development has a tendency to slow down. For example, inone of the companies that we work with, the release cycle for their main plat-form slowed from once every nine months to once every 18 months until thecompany realized that this was unacceptable and took measures to addressthis. Third, part of the increase in software size is caused by the companytaking in new externally developed software. This software can be commercialor open-source, but it requires integration and validation as much as any othersubsystem and consequently requires R&D effort to be allocated to it. As thesaying goes, quantity has a quality of its own. Another consequence of rely-ing increasingly on externally developed software is that companies naturallyshift from being internally focused to paying more attention to their businessecosystem and the partners and suppliers that are part of it.

3

4 � Speed, Data and Ecosystems: Excelling in a Software-Driven World

The cloud computing and Software-as-a-Services companies have beenleading the industry in these developments. By taking an experimentation-based approach and adopting short feedback loops, the traditional organiza-tional models using functional hierarchies of product managers, architects,developers, testers and release engineers are becoming increasingly obsolete.Often referred to as DevOps, these roles can no long stay in their respectivesilos and instead need to become part of the same team. Each team needsall the functions required to take an innovative idea to a fully implementedand deployed feature. This includes skills around product management, soft-ware architecture, development, testing and deployment as well as other skillsdepending on the type of system, such as user experience, security or safety.Such teams are often referred to as cross-functional teams, but in this bookwe use the term multi-disciplinary teams. The reason is that the term cross-functional suggests that the team members belong to different functions (as inorganizational units) and that working cross-functional is an exceptional ap-proach. Instead, multi-disciplinary teams with a high degree of autonomy areincreasingly becoming the norm in many companies, especially in the cloudcomputing and SaaS industries but rapidly followed by the embedded systemsindustries.

The notion of requirements engineering through experimentation changesthe role of product management in traditional organizations. Traditionally,product managers talk to current and potential customers and listen to theirwishes and desires. Subsequently, this input is turned into an elaborate re-quirement specification that covers all aspects of a new product or the nextrelease of an existing product. This specification is then given to the R&Dorganization together with a budget. Due to the complex and frequently an-tagonistic relationship between product management and development, theiteration speed of the system is often low, for instance yearly or six-monthcycles. Adopting multi-disciplinary teams and shifting towards continuous de-ployment allows organizations to overcome these challenges.

Over the last decade, the space of software start-ups as well as onlinecompanies have changed quite fundamentally along the approaches discussedabove. Although cloud and SaaS provide inherent advantages, many industryobservers fail to recognize that these companies work in a different way, em-brace a different culture and have different norms and values. This contributesas much to the success of these companies as the underlying technology in-frastructure. Traditional on-premise software companies as well as embeddedsystems companies have now started the transition as well. For pure softwarecompanies, this transition is challenging but in certain ways easier and con-sequently we see large on-premise software companies experiment with cloudand SaaS and introduce new offerings based on these technologies.

Embedded systems companies, on the other hand, have had a much moredifficult time to adapt the aforementioned approaches. This is, among others,due to two factors. First, embedded systems often have safety and reliabil-ity requirements that exceed those of pure software systems. For instance, a

Introduction � 5

software failure in the safety-critical parts of a car, train or airplane can re-sult in devastating consequences. This leads to quite conservative behavior byboth the producers of embedded systems as well as the certification institutes.Second, the culture at these companies has traditionally been driven by me-chanics and hardware (electronics) and both of these disciplines are defined bythe immutability of the product post-manufacturing. Consequently, engineer-ing processes are focused on ease of manufacturing and the minimization ofissues at the customer through rigid, milestone-based development processes.

The embedded systems industry is, however, at the verge of a fundamentalshift similar to the shift from installed software to SaaS. Various metrics showthat the amount of software in embedded systems follows Moore’s law anddoubles every couple of years, depending on the industry. This is leading to afundamental shift in R&D resource allocation from mechanical and electron-ics to software. In addition to the shift of resources, we also see increasingfrustration with the aforementioned rigid, milestone-driven product develop-ment process dictated by mechanics and electronics. As embedded systemsare increasingly connected to the internet, the ability of performing continu-ous deployment of software on systems out in the field becomes a reality.

In addition to software being deployed at products out in the field, theproducts can also be instrumented with data collection mechanisms that candetermine the use cases employed by the system, the level of quality attributessuch as performance, reliability and safety as well as contextual informationusing sensors.

Once the products deployed in the field are constantly accessible for dataand deployment of software, it becomes possible to perform A/B experimentswhere the installed base of products is viewed as a population. Out of this pop-ulation, experiment groups can be selected and experiments performed. Theseexperiments can consist of alternative implementations of existing function-ality and features and alternative workflows as well the introduction of newfunctionality and features with the intent of improving some aspect of thesystem.

The experiments typically are small-scale changes in functionality, featuresor structure and hence are typically not or barely noticeable by users. In acontinuous deployment context, the delta between two releases of the softwareis highly limited. This addresses one of the main concerns by some users whohave experienced the large changes present in infrequent, e.g., yearly, releasesof software.

The potential benefits of an experimentation-based approach to softwaredevelopment for embedded systems are even larger than in traditional SaaSsoftware. In SaaS solutions, the experimentation is virtually exclusively di-rected towards the user experience. In embedded systems, all qualities of thesystem can be experimented with. For instance, imagine a car that gets betterwith every day of use as software ranging from engine control to active safetyto infotainment is constantly undergoing minor changes that, as a whole, re-sult in a superior, continuously improving system.

6 � Speed, Data and Ecosystems: Excelling in a Software-Driven World

Achieving the potential benefits resulting from very short feedback cy-cles using technologies, such as continuous deployment, experimentation-baseddevelopment and multi-disciplinary teams, requires a fundamentally differentR&D strategy, process and ways of working, tooling, relationship to customersas well as organizational changes. However, adopting this alternative approachis complicated as it requires so many changes in so many different areas andaspects of a business and its organization. There is surprisingly little researchand publications that provide a top-level, end-to-end overview including busi-ness, technology, process, tooling and organization implications. Often, theliterature tends to address aspects of the above, e.g., agile development forteams or continuous integration, but fails to connect this to an integrationvision of how the organization will function as a whole.

The goal of this book is to address that gap and to provide an integrated,high-level perspective while combining it with detailed, actionable and con-crete methods, techniques and tools for achieving the desired outcomes inthe context of an organization. As the literature that exists mostly focuseson cloud and SaaS companies, we will allocate significant space to large-scaleembedded systems. However, the concepts apply to any company that has ma-jor software products in its portfolio, including products that are only usedinternally.

As we conducted the research that forms the basis for this book, it be-came clear that companies are grappling with three overall challenges, whichcan be summarized as speed, data and ecosystems. Speed is concerned withshortening the cycle time in R&D or, in other words, how to shorten the timefrom identified customer need to delivered solution in the hands of customers.The speed dimension is concerned with agile development practices, continu-ous integration and continuous deployment but needs to address all the rel-evant dimensions of large-scale software development, including system andsoftware architecture, ways of working and organization. Data is concernedwith increasing the use of and benefit from the massive amounts of data thatcompanies are collecting from their systems deployed in the field, includingdata about user behavior and system performance. The data dimension isconcerned with data-driven decision making in R&D and with using the fastrelease cycles enabled in the speed dimension for fast, evidence-based deci-sion making about the value and viability of new features and new products.Ecosystems are addressing the transition of companies from being internallyfocused to being ecosystem oriented. The ecosystem dimension is concernedwith analyzing what the company is uniquely good at and where it adds valueand, subsequently, relying on its ecosystem of partners and suppliers to delivereverything else.

The speed dimension is concerned with increasing the efficiency of soft-ware development in the software-intensive systems industries. The data andecosystem dimensions are concerned with increasing the effectiveness of thecompanies in their own way. The increased use of data during the developmentprocess allows R&D teams to decide whether a feature or product is viable and

Introduction � 7

Figure 1.1 Overview of the Stairway to Heaven model

will deliver on its promise. This allows the company to stop development afterinvesting only a fraction of the allocated resources if the data show that thepotential is not realized. As research by us and others shows that more than50% of features in systems are waste as these are not used but add to clutterand complexity, there is a major opportunity for increasing effectiveness ofR&D in terms of value delivered to customers. Ecosystems focus on using thecompany’s R&D resources on the things best done by the company itself andrelying on the ecosystem for everything else. Although ecosystem partners willneed to share part of the revenue generated, the company can focus on its keydifferentiators rather than the entire scope of system functionality. This alsoincreases the effectiveness of R&D efforts.

We have structured our findings around speed, data and ecosystems in amodel that has been christened the “Stairway to Heaven.” The model has threedimensions and each dimension has five levels. The levels in each dimensionare the result of extensive research with dozens of companies and capture thetypical evolution paths for companies. In figure 1.1, we provide an overviewof the model as well as the stakeholders involved in it.

As such, the Stairway to Heaven model provides a framework for assessingthe current state of software development, modeling desired state and planningand sequencing the improvements required to reach desired state. We providemethods, techniques and tools for each of these activities for each of the di-mensions and describe in detail the changes that companies go through whenevolving from one level to the next in each dimension. In the next sections,we provide a short introduction into each of the dimensions of the model.

8 � Speed, Data and Ecosystems: Excelling in a Software-Driven World

Figure 1.2 Speed dimension of the Stairway to Heaven

1.1 SPEED

Over the last decade, one of the main developments in software products isthe broad adoption of continuous deployment. This development started in thecloud-based “Software as a Service” (SaaS) companies. This is due to the factthat the cost of deploying new versions of software in a SaaS environment isvery low, perhaps even negligible, compared to traditional installed software.That allows for a deployment model where software is updated very frequently,in some cases many times per day.

The ability to deploy frequently brings enormous benefits to companiesand, as a consequence, the software-intensive systems industry is now under-going the transformation towards continuous deployment of software even inareas where the reliability requirements are much higher. Even without thedata that come back from deployed systems, continuous deployment allowsfor constant adjustment of the development backlog to customer needs, al-lows for continuous testing of small slices of new functionality in systems inthe field and provides a productive outlet for teams as the functionality thatthey developed is not sitting on a shelf for months at a time but in the handsof customers hours or days after it got written.

Based on studying dozens of companies, we have identified and definedthe levels that companies evolve through in the speed dimension. As shownin figure 1.2, starting from traditional development, companies adopt agiledevelopment practices first. Then there is a need to build continuous integra-tion capabilities. Once the company reaches a point where it always has aproduction quality version of the software, it moves to continuous deploymentwhere software gets deployed in systems at least every agile sprint and poten-tially much more often. Finally, the company uses this capability to shift itsdevelopment process from requirements driven to experimentation driven.

Introduction � 9

1.2 DATA

The ability to continuously deploy new versions of software to some or allcustomers leads to another major evolution concerning the radically changedability of companies to measure how users are using the software. Althoughsoftware companies have often used techniques to collect usage and qualitydata, continuous deployment demands continuous connectivity for the de-ployed systems. This, in turn, allows for the collection of much more detailed,timely data.

The ability to collect product data in real time leads to the possibilityto significantly shorten the feedback loop of product development. Shorterproduct development feedback loops allow for a much more rapid discovery ofthe functionality and qualities that lead to significantly increased alignmentbetween the needs of customers and the product. This in turn improves thecompetitive position of a company as the product better meets the marketdemands.

The short feedback loops in product development and evolution allow fora different approach to requirement engineering: the deployed system can nowbe used for experimenting with customers and with system behavior. Differ-ent deployed systems can get different versions of the software or of featureimplementations. By studying the behavior of users and systems while usingthe different versions, one can empirically and based on statistically relevantdata determine which version of a feature implementation or system softwareis preferred. As many studies have shown the major gap between espousedpreferences and actual behavior, the ability to collect data on actual behavioris incredibly valuable.

The way companies evolve through their ability to use data proves to fol-low a predictable pattern. As shown in figure 1.3, companies start with a veryad hoc and manual approach to data driven by passionate and committedindividuals. Then, the collection of data is automated, followed by the in-troduction of dashboards for relevant teams that get automatically updatedwith data from the field. The challenge with these dashboards is that theyeasily become outdated, which leads to the data innovation stage where thereis a constant flow of new insights that results in evolving dashboards andfocus areas. Finally, the entire company adopts data-driven decision makingin everything it does including sales, performance reviews, hiring and otherprocesses.

1.3 ECOSYSTEMS

The transition from internally focused to ecosystem-centric ways of workingbrings with it many advantages. It allows for companies to focus on their corecompetencies, to outsource all activities that are not strategic for the com-pany and to employ ecosystems of third party developers to complement the

10 � Speed, Data and Ecosystems: Excelling in a Software-Driven World

Figure 1.3 Data dimension of the Stairway to Heaven

core functionality provided by the company itself with extensions for specificcustomers and customer segments.

For the industry at large, our research shows that although the princi-ples of core competencies, outsourcing and crowdsourced ecosystems are wellunderstood, many companies are still quite poor at fully embracing these con-cepts. Many of the companies studied still have a preference to continue todo many things internally that should be outsourced and tend to managetheir ecosystem partners during the selection, the execution and the conflictresolution stages, in a largely ad hoc and locally optimized fashion.

One of the reasons for the aforementioned challenge is that there are fewreally actionable models and frameworks for companies to use in determiningthe best course of action. Thus, every company has to build, over time, its ownset of experiences and learn and structure its interactions with its ecosystem.There is little knowledge exchange beyond the vision level and, consequently,the operational level is ad hoc and executed based on the best efforts of theindividuals responsible for the task.

Similar to the speed and data dimensions, we have defined, again basedon our research, an evolution model for how companies work with softwareecosystems. As shown in figure 1.4, starting from an internally focused com-pany, the first interactions with the ecosystem tend to be ad hoc and locallyinitiated. Once the benefits are shown, the next step is to take a more cen-tralized approach but to focus on short-term benefits and hence the companytakes more of a tactical approach. Over time, one of the ecosystems that thecompany is part of will start to be managed in a more strategic fashion. Fi-nally, the company adopts this strategic approach to all its ecosystems.

One of the models that we use to discuss the approach to software ecosys-tems is the three layer product model. This model distinguishes between thecommodity layer of functionality, the layer of differentiating functionality andthe layer of experimental and innovative functionality. The company has dif-ferent ecosystems to deal with for each layer of the model as well as managethe transition of functionality between these layers. The three layer productmodel can be used as a conceptual model, but it can also be used as a physical

Introduction � 11

Figure 1.4 Ecosystem dimension of the Stairway to Heaven

software architecture with different teams, with different success metrics, asso-ciated with each layer. Although software ecosystems have associated technicalchallenges, in our experience, the technical challenges of realizing a softwareecosystem are often quite manageable whenever the company is clear on thebusiness strategy.

1.4 THE BAPO MODEL

As the topics in this book touch upon business and business strategy andtechnology as well as on process and ways of working as well as architecture, itis important to ensure that we establish the relationship and priority betweenthese topics carefully. In earlier work [49], we presented the BAPO model.The BAPO model identifies four major areas of concern:

Business: The business and business strategy for a company is thestarting point and everyone in the company (especially those in R&D)needs to have a deep and intimate understanding of the business thecompany is in, the vision, mission, goals and strategy for accomplishingthose goals and the customers that are served by the company. Especiallyin engineering, there has traditionally been a culture where the businessside is viewed as "not our concern" and engineers tended to ask forclearly specified requirements. In a fast moving world where technologies,customers needs and business models change rapidly, engineers can nolonger afford to be ignorant of the business.

Architecture: Although the word architecture has become overloadedand in many contexts gets to mean whatever the user of the word wantsit to, the fact remains that the top-level breakdown of a system, thedesign principles and patterns that form the fabric of a system as wellas the design rules and constraints that result from the design decisionsforming the basis of the architecture are of critical importance for thesuccess of a system and its ability to realize and support the businessstrategy. Engineers and other technical staff, as well as product managers

12 � Speed, Data and Ecosystems: Excelling in a Software-Driven World

and others working with R&D, need to understand the architecture andthe reasons the architecture is structured as it is.

Process: Especially in the agile community, process has a bad reputa-tion and considering the straitjacket that approaches like CMMi [22] putdevelopers into, this reputation is not undeserved. However, many forgetthat agile approaches like SCRUM also define processes. A well-definedset of process steps and order in which these are performed providestructure that allows individuals and teams to perform at their best bystreamlining activities and minimizing coordination overhead.

Organization: People in any organization larger than a handful need tobe organized in teams and departments. A company needs a work break-down structure that ideally assigns most of the coordination to intra-team communication and minimizes inter-team communication. Also,individuals need to know who are in their team and who are not if onlyto know who to rely on and partner with. Consequently, the structureof the organization is important and requires attention.

In figure 1.5 we present the BAPO model graphically. It is important tonote, however, that although all four areas of concern in the BAPO model areimportant, there is an order of priority. The starting point is the business andbusiness strategy. The architecture is the next area as this is where the businessstrategy and its priorities need to be realized in the structure and architecturalpatterns through design decisions. The processes and ways of working are aconsequence of the architecture as components of the architecture often can bereleased (internally or externally) separately and the process will be informedby the structure of the architecture. Finally, the other areas should result inan organizational structure that meets the needs of the business, architectureand process.

Although the BAPO model has a clear priority order for the different areas,in reality there are connections between all four areas and there is feedbackfrom the lower priority areas that will influence the decisions around, for in-stance, business and architecture. For instance, an organization that has teamsin different continents will influence the architecture to increase the amount ofindependence between the parts assigned to the different locations. However,to the largest extent possible, one should start from business and businessstrategy and adjust the other areas according to the discussed priorities.

In the remainder of the book, where we explore the speed, data andecosystem dimensions of the Stairway to Heaven, the paradigm underlyingthe BAPO model should be considered as the basis even where we leave itimplicit in the text.

Introduction � 13

Figure 1.5 The BAPO model

1.5 WHERE ALL THIS COMES FROM

The content in this book is based on three sources. First is the industrialexperience while working in industry and being actively involved in large-scalesoftware development. The companies were concerned with mobile devices andwith pure software and SaaS deployments as well as headquartered in Europeand in Silicon Valley.

The second source is the Software Center in Sweden. This is a collaborationbetween, at the time of writing, nine large companies and five universities. Thecompanies involved are Ericsson, Volvo Car Corporation, AB Volvo, Saab AB,Jeppesen (part of Boeing), Axis Communications, Grundfos, Tetra Pak andVerisure. These companies are the employers of hundreds to tens of thousandsof software engineers. In the research activities, we have been involved in abroad range of topics, ranging from agile development methods and continuousintegration to continuous deployment, data-driven development and softwareecosystems. The techniques, methods and tools presented in this book arein active use by some or all of the companies in the Software Center andconsequently validated in industrial contexts.

The third source is the consulting engagements that I have been drivingwith a variety of companies over the last years. Having worked with wellover a dozen companies on a range of topics including software architectureand platforms, development practices, continuous integration and deployment,innovation practices, the relationship between business and R&D, businessand software ecosystems has resulted in a solid understanding of the practicesand approaches that work and those that don’t work in large-scale software-intensive systems.

Although I currently work in academia, I would like to ensure you as areader that the content in this book is based on a solid empirical foundationwith significant hands-on industrial experience underlying the concepts. Many

14 � Speed, Data and Ecosystems: Excelling in a Software-Driven World

of the topics that we discuss are hard to implement and realize in a typicalorganization, but the benefits exist and have been confirmed and documentedin real, large-scale software-intensive companies.

1.6 FOR WHOM THIS BOOK WAS WRITTEN

The primary audience for which the book is intended are senior leaders insoftware-intensive companies, both from the general management as well asfrom product and R&D management. For the vast majority of organizations,technology has become too important to leave to the technologists. Interest-ingly, however, the opposite is true as well: the business of companies is soinfluenced by technology that it can no longer be left to the business leadersonly. The technology leaders, both in product management and in R&D, needto be deeply involved in the business of the company as well in order to ensureoptimal alignment between the business and the technology.

The main reason for this increased level of integration is that the tra-ditional functional organization is unable to respond sufficiently quickly tochanges in the market. Instead, organizations increasingly move to cross-functional teams holding the necessary skills in the team and jointly movingtowards a goal. These teams have levels of autonomy that go significantlybeyond the traditional approaches and are supported by levels of automationthat allow these teams to respond rapidly. For these cross-functional teamsto be effective, there is a need for a common terminology, perspective andparadigm. This book seeks to address that challenge by providing the com-mon language and shared point of view that technical as well as businesspeople can appreciate and use as a basis for their work.

Consequently, the third audience group is senior engineers and softwarearchitects. As technical staff need to understand the business, the businessstrategy as well as the trends and developments influencing the business andtechnology, it is no longer sufficient to focus just on the technological chal-lenges. The alignment between business and technology needs to be driven byengineers and especially architects as much as by the folks in formal leadershiproles.

The final audience group is researchers and students in software engineer-ing, product management, technology management and innovation manage-ment. Although the book is predominantly written towards industry, the con-tent is academically well founded and based on dozens of publications. Al-though not as extensive as in traditional academic literature, there are manyreferences to the publications underlying the material in the book and this initself may be relevant for researchers and academics in general.

Summarizing, the book has four audience groups for which it is intended:

General management and leaders outside of R&D

Leaders in R&D and product management

Introduction � 15

Technical staff such as senior engineers and architects

Researchers, students and academics in general

1.7 READING GUIDE

Although as an author one wants to have everyone read one’s book cover tocover, the reality is that time is limited and that not all parts are equallyinteresting to all readers. There are two ways to limit the reading of this bookto a subset of chapters. One is to read about the entire set of concepts in thebook but at different levels of depth. The second is to focus on a topical sliceof the book.

Covering all concepts in the book can be accomplished at three levels ofcoverage:

Elevator pitch: For you who just want to know the main conceptsand ideas underlying the book, reading this chapter and the conclu-sion (chapter 14) will give you high-level understanding of the topicsaddressed. This will give you a first insight and help you decide if thecontent is relevant for your situation.

Just the basics: The second level of coverage is read this introduc-tion chapter, chapter 2 to understand the trends that are driving thecontent in the book, chapters 4, 8 and 11 as the description for eachof the dimensions of the Stairway to Heaven model and the conclusion(chapter 14).

The full monty: The final level is to read all chapters in the book andto understand not just the concepts, but also develop an insight into themethods, techniques and tools that we are introducing into the book.

If your interest is more focused on one of the Stairway to Heaven dimen-sions, you can read the content of each part independent of the other parts:

Speed: if your interest is predominantly concerning increasing speedand efficiency of software development, your reading should focus onpart I (chapters 1, 2 and 3), part II (chapters 4, 5, 6 and 7) and part V(chapter 14).

Data: If the use of data to increase effectiveness of software developmentis your primary interest, please read part I (chapters 1, 2 and 3), partIII (chapters 8, 9 and 10) and part V (chapter 14).

Ecosystem: Similarly, if software ecosystems and the strategic man-agement of your partners, suppliers, customers and complementors arethe key focus, you should read part I (chapters 1, 2 and 3), part IV(chapters 11, 12 and 13) and part V (chapter 14).

16 � Speed, Data and Ecosystems: Excelling in a Software-Driven World

Finally, the book is intended for industrial professionals and aims to pro-vide as much in terms of concrete, tangible solutions that can be directlyapplied in your organization as it is concerned with building an understand-ing between the strategic trends, developments and business implications andthe role that R&D needs to play in response to these. As such, the book is nota cookbook with clear-cut recipes, but rather invites you as a reader to builda deeper understanding of the subject matter and to use this understandingto materially improve the competitive position of your organization.