the software architect - IEEE Computer Society [PDF]

NOVEMBER/DECEMBER 2016 IEEE SOFTWARE November/December 2016

The Role of the

THE ROLE OF THE SOFTWARE ARCHITECT

Software Architect SOFTWARE AND THE ENVIRONMENT // 23 THE TRAGEDY OF DEFECT PREDICTION // 102

Volume 33 Number 6

WWW.COMPUTER.ORG/SOFTWARE

PREFERRED PLUS

TRAINING & DEVELOPMENT

RESEARCH

BASIC

STUDENT

New Membership Options for a Better Fit And a better match for your career goals. Now IEEE Computer Society lets you choose your membership — and the benefits it provides — to fit your specific career needs. With four professional membership categories and one student package, you can select the precise industry resources, offered exclusively through the Computer Society, that will help you achieve your goals.

Learn more at www.computer.org/membership.

IEEE Computer Society Is Where You Choose the Resources that Fit Your Career Find the membership that fits you best. IEEE Computer Society lets you choose your membership — and the benefits it provides — to meet your specific career needs. With four professional membership categories and one student package, you can select the precise industry resources, offered exclusively through the Computer Society, that will help you achieve your goals.

Select your membership

Preferred Plus

Training & Development

Research

Basic

Student

$60

$126

$55

$115

$55

$115

$40

$99

$8

IEEE Member

Affiliate Member

IEEE Member

Affiliate Member

IEEE Member

Affiliate Member

IEEE Member

Affiliate Member

Does not include IEEE membership

Computer magazine (12 digital issues)* ComputingEdge magazine (12 issues) Members-only discounts on conferences and events Members-only webinars Unlimited access to Computing Now, computer.org, and the new mobile-ready myCS Local chapter membership Safari Books Online (600 titles and 50 training videos) Skillsoft online solutions (courses, certifications, practice exams, videos, mentoring) Two complimentary Computer Society magazine subscriptions myComputer mobile app Computer Society Digital Library Training webinars

30 tokens

30 tokens

30 tokens

12 FREE downloads

Member pricing

12 FREE downloads

Member pricing

Included

3 FREE webinars

3 FREE webinars

Member pricing

Member pricing

Member pricing

Priority registration to Computer Society events Right to vote and hold office One-time 20% Computer Society online store discount * Print publications are available for an additional fee. See catalog for details.

www.computer.org/membership

TABLE OF CONTENTS November/December 2016

Vol. 33 No. 6

FOCUS

FEATURES

THE ROLE OF THE SOFTWARE ARCHITECT

80 A Paradigm Shift for the CAPTCHA Race: Adding Uncertainty to the Process

30 Guest Editors’ Introduction The Software Architect’s Role in the Digital Age Gregor Hohpe, Ipek Ozkaya, Uwe Zdun, and Olaf Zimmermann

41 How Software Architects Drive Connected Vehicles Sören Frey, Lambros Charissis, and Jens Nahm

48 Software Architects in Large-Scale

Distributed Projects: An Ericsson Case Study Ricardo Britto, Darja Šmite, and Lars-Ola Damm

Shinil Kwon and Sungdeok Cha

86 Examining the Rating System Used in Mobile-App Stores

Israel J. Mojica Ruiz, Meiyappan Nagappan, Bram Adams, Thorsten Berger, Steffen Dienst, and Ahmed E. Hassan

MISCELLANEOUS 6

How to Reach Us

Inside IEEE Computer Society Information Back Cover

56 Embedded-Software Architects: It’s Not Only about the Software Pablo Oliveira Antonino, Andreas Morgenstern, and Thomas Kuhn

63 The Architect’s Role in Practice:

From Decision Maker to Knowledge Manager?

Rainer Weinreich and Iris Groher

70 The Architect’s Role

in Community Shepherding

Damian A. Tamburri, Rick Kazman, and Hamed Fahimi

See www.computer.org /software-multimedia for multimedia content related to the features in this issue.

30

98

8

102

DEPARTMENTS 4 From the Editor

94 The Pragmatic Architect

The Changing Role of the Software Architect

Software Architecture in a Changing World

Diomidis Spinellis

Eoin Woods

8 On Computing

98 Reliable Code

Once upon a Time

Hi Maintenance

Grady Booch

Gerard J. Holzmann

11 Insights

102 Sounding Board

Just Enough Anticipation: Architect Your Time Dimension Eltjo Poort

The Tragedy of Defect Prediction, Prince of Empirical Software Engineering Research

16 Requirements

Michele Lanza, Andrea Mocci, and Luca Ponzanelli

Caring: An Undiscovered “Super -ility” of Smart Healthcare

106 Voice of Evidence

Nancy Laplante, Phillip A. Laplante, and Jeffrey Voas

ADAPT: A Framework for Agile Distributed Software Development

20 Practitioners’ Digest

Raoul Vallon, Stefan Strobl, Mario Bernhart, Rafael Prikladnicki, and Thomas Grechenig

Trends in Agile: Perspectives from the Practitioners Rafael Prikladnicki, Casper Lassenius, Evelyn Tian, and Jeffrey C. Carver

112 Software Technology Software Crowdsourcing Platforms

Alexandre Lazaretti Zanatta, Leticia Santos Machado, Graziela Basilio Pereira, When Software Impacts the Economy Rafael Prikladnicki, and Erran Carmel

23 Impact

and Environment

Edleno Silva de Moura, Mauro Rojas Herrera, Leonardo Santos, and Tayana Conte

117 Software Engineering James Phillips on Service Discovery Charles Anderson

27 Invited Content Cyclomatic Complexity Christof Ebert and James Cain

Building the Community of Leading Software Practitioners

www.computer.org/software

FROM THE EDITOR

Editor in Chief: Diomidis Spinellis Athens University of Economics and Business, [email protected]

The Changing Role of the Software Architect Diomidis Spinellis

BEING A GOOD software architect has never been easy. Changes in the software industry are making the job even more challenging. The key drivers are the rising role of software in systems of all kinds and their operation; more emphasis on reuse, agility, and testability during software development; and several quality elements increasingly affected by architectural choices. Most of these drivers have always concerned software architects. What’s changing is that the requirements they impose appear much more frequently and are more difficult to satisfy.

Systems and Operations The systems running the software are becoming ever-more intertwined with it. In the past we could often afford to abstract the system on which the code was running and view software architecture in isolation. John von Neumann taught us how to do that, and it has worked wonderfully for more than half a century. Nowadays, however, software increasingly determines the architecture of a complete system (this includes hardware

IEEE Software Mission Statement 4

IEEE SOFTWARE

and “wetware”—humans), which can in turn affect the software’s architecture. Consider software that coordinates a car’s electronic control units, binds together a large organization’s departments, or dishes out work among datacenters around the planet. In each case, the system’s structure constrains the software’s architecture, which in turn can determine the system’s quality (more on that later) and fi nancial viability. For instance, consider the division of work among multiple (cloud) datacenters. Their setup, cost, and communication affordances will guide architectural choices in the software that processes work requests. The resultant system’s architecture determines the offering’s performance, reliability, security, and efficiency. Software architects must also take an enterprise’s operations into account. As this issue’s guest editors point out in their introduction, the DevOps movement has demonstrated the importance of closely collaborating with IT professionals when you’re developing software. Architects must play their part by

designing software that’s easy to build, configure, test, deploy, monitor, scale, and troubleshoot. For each link in this chain there are important domain-specific designs, tools, and techniques that architects must select and apply.

Reuse The increasing use of open source third-party components is a welcome and partly unexpected development. Open source software libraries, often concocted by hobbyists and maintained by volunteers through pull requests on GitHub, are fi nding their way into mass-market TVs, smartphones, routers, enterprise applications, and even medical equipment. Software package managers, such as npm, pip, and Maven, enable and promote deep, complex dependencies between hundreds of components, which we take for granted— until they fail. Given this state of affairs, modern software architects must decide which components to use as open source software and which to purchase or build in-house. In their de-

To be the best source of reliable, useful, peer-reviewed information for leading software practitioners— the developers and managers who want to keep up with rapid technology change. |

PUBLISHED BY THE IEEE COMPUTER SOCIETY

0740-7459/16/$33.00 © 2016 IEEE

The MIT Press

cisions, they must balance factors such as quality, technological risk, and licensing restrictions, as well as each component’s fit with the rest of the project and its total cost of ownership. True to choices that building architects have faced for centuries, this is a multi-objective optimization with many unknowns. As Philippe Kruchten put it, “The life of a software architect is a long and rapid succession of suboptimal design decisions taken partly in the dark.”1 Having chosen the parts to reuse, architects must align the interfaces of diverse modules with the project’s design. Then they must come up with a plan for maintaining thirdparty components and integrating their changes back into the project.

Agility Today’s software architects are instrumental in delivering and managing development agility. Early on, they must consider and decide on the change forces that the software will most likely face. Then, they need to devise a design that not only is amenable to the change coming from these forces but also maintains its conceptual integrity when subjected to them. Some architects’ choices will be (or turn out to be) incorrect. In such cases, they must come up with fresh software designs that accommodate novel requirements with gusto. These must result in a new powerful software structure with minimal disruption to existing code. And, just as the software’s initial architecture must enable its efficient implementation, modified architectures must allow efficient refactoring.

Testability System architectures have long been designed for testability: consider

the power-on self-test of most electronic equipment or the test pads and modes on complex integrated circuits. Software architects can help developers with designs that are easy to unit-test, components that can be tested in isolation, interfaces that be easily driven, and operations that are amenable to automation. For instance, a microservice with a public RESTful HTTP interface expressed as an Open API specification (formerly called Swagger) might be easier to test than a proprietary, internal Java interface in a monolith. (REST stands for Representational State Transfer.)

Quality As key quality elements affected by architectural choices in the digital age, consider usability, security, reliability, and efficiency. Usability quirks and wonders, on devices ranging from phones to desktops, often come about through bad and good architectural decisions. An appropriate abstraction can provide a coherent and pleasant user experience; failing to provide one can result in a hodgepodge of nauseatingly inconsistent interfaces. Adding insult to injury, a first-class software design will deliver orthogonal functionality with negligible implementation cost, whereas the deficient model might require expensively coding thousands of error-prone special cases. For example, think of how some popular OSs and their applications handle the changing of a display’s resolution. Security’s importance increases as each new device on the planet connects to the Internet. The software’s architecture will determine where data is stored, where it’s processed, what becomes encrypted, and how the software guarantees

Software Design Decoded 66 Ways Experts Think Marian Petre and André van der Hoek illustrations by Yen Quach “This is the book I wish I'd had around throughout my journey as a software architect. It’s charming, approachable, and full of wisdom—you'll learn things you'll come back to again and again.” —Grady Booch, IBM Fellow and Chief Scientist, IBM

Modeling and Simulating Software Architectures The Palladio Approach Ralf H. Reussner, Steffen Becker, Jens Happe, Anne Koziolek, Heiko Koziolek, Klaus Krogmann, Max Kramer, and Robert Heinrich A new, quantitative architecture simulation approach to software design that circumvents costly testing cycles by modeling quality of service in early design states.

mitpress.mit.edu

FROM THE EDITOR

HOW TO R EAC H US AUT H O R S For detailed information on submitting articles, write for our editorial guidelines ([email protected]) or access www.computer.org/software/author.htm. LETTERS T O T H E E D I T O R Send letters to Editor, IEEE Software 10662 Los Vaqueros Circle Los Alamitos, CA 90720 [email protected] Please provide an email address or daytime phone number with your letter. O N T H E WE B www.computer.org/software S UBS CR I BE www.computer.org/software/subscribe S UBS CR I P T I O N CHA NG E O F A D D R E S S Send change-of-address requests for magazine subscriptions to [email protected]. Be sure to specify IEEE Software. M E M BE R S H I P C HA NG E O F A D D R E S S Send change-of-address requests for IEEE and Computer Society membership to [email protected]. M I S S I NG OR DA M AG E D CO P I E S If you are missing an issue or you received a damaged copy, contact [email protected]. REPRIN T S O F A R T I CL E S For price information or to order reprints, email [email protected] or fax +1 714 821 4010. REPR I NT P E R M I S S I O N To obtain permission to reprint an article, contact the Intellectual Property Rights Office at [email protected].

the maintenance of its security attributes, such as the data’s confidentiality and integrity. Architecture also determines the software’s attack surface: the places where enemies can target their assaults. The goal here is to minimize the attack surface and bring it close to (physical or logical) places where it can be effectively safeguarded. The differing number of vulnerabilities discovered in competing OSs or Web browsers exemplifies this situation. A large part of the difference is due to architectural choices. In the past, the reliability of most software depended mainly on its implementation. Now architecture is playing an increasing role, for two reasons. First, service-oriented architectures and cloud-based infrastructures depend on connectivity that might be intermittent or fail entirely, problems that are exacerbated by wireless and mobile data links. Second, the Internet of Things has software work with ephemeral and fickle devices. Reliability in these settings can’t be micromanaged at the implementation level; it must be architected. The software architect is responsible for adopting tactics such as caching, redundancy, idempotence, and graceful degradation to handle varied and sometimes unexpected failures. Architectural patterns such as Circuit Breaker or Watchdog can be applied to achieve the desired reliability qualities, following a “design for failure” principle. Efficiency has always been an important concern in software architecture. What’s changing is the breadth of choices and the diversity of outcomes and performance indicators. Will an expensive calculation be performed on a phone’s CPU, draining its battery, or on the cloud, increasing the latency? Will some 6

I E E E S O F T WA R E

|

time-critical processing occur on a powerful multicore CPU, a cluster of servers, or a GPU? Will service elasticity be provided by the dynamic leveraging of costly cloud-based resources or by the peer-to-peer distribution of the load among free but unreliable clients?

A

ll the choices and challenges facing the modern software architect are staggeringly intertwined. Each of them both constrains the others and affects multiple key outcomes. Minor decisions often have huge implications. As in the physical world, this is the difference between engineering and architecting.

Reference 1. P. Kruchten, “The Architects—and the Software Architecture Team,” Proc. 1st Working IFIP Conf. Software Architecture (WICSA 99), 1999, pp. 565–584.

Selected CS articles and columns are also available for free at http://ComputingNow.computer.org.

W W W. C O M P U T E R . O R G / S O F T W A R E

E D I T OR I N C H I E F DIOMIDIS SPINELLIS, [email protected] EDITOR IN CHIEF EMERITUS: Forrest Shull, Carnegie Mellon University

A S S O C I AT E E D I T O R S Agile Practices: Casper Lassenius, Aalto University; [email protected] Agile Processes: Grigori Melnik, Splunk; [email protected] Cloud Software Engineering: Rami Bahsoon University of Birmingham; [email protected] Cloud Systems: Jorge Cardoso, University of Coimbra; [email protected] Configuration Management: Sven Apel, University of Passau; [email protected] Design/Architecture: Uwe Zdun, University of Vienna; [email protected]

Development Infrastructures and Tools: Thomas Zimmermann, Microsoft Research; [email protected] Distributed and Enterprise Software: John Grundy, Swinburne University of Technology; [email protected] Empirical Studies: Laurie Williams, North Carolina State University; [email protected] Human Factors: Marian Petre, The Open University Management: John Favaro, Intecs; [email protected]

Mobile Applications and Systems: Alexis Eduardo Ocampo Ramírez, Ecopetrol; [email protected] Models and Methods: Paris Avgeriou, University of Groningen; [email protected] Online Initiatives and Software Engineering Process: Maurizio Morisio, Politecnico di Torino; maurizio.morisio@ polito.it Professional Practice: Rajiv Ramnath, The Ohio State University; ramnath.6@ osu.edu Programming Languages and Paradigms: Adam Welc, Oracle Labs; [email protected]

Quality: Annie Combelles, inspearit; [email protected] Requirements: Jane Cleland-Huang, DePaul University; [email protected] Software Economy: Davide Falessi, California Polytechnic State University, San Luis Obispo; [email protected] Software Maintenance: Harald Gall, University of Zurich; [email protected] Software Testing: Jerry Gao, San Jose University; [email protected] Theme Issues: Henry Muccini, University of L’Aquila, Italy; [email protected]

of Eastern Switzerland, Rapperswil Invited Content: Giuliano Antoniol, Polytechnique Montréal; Steve Counsell, Brunel University; Phillip Laplante, Pennsylvania State University Multimedia: Davide Falessi, California Polytechnic State University, San Luis Obispo

On Computing: Grady Booch, IBM Research The Pragmatic Architect: Eoin Woods, Endava Reliable Code: Gerard Holzmann, NASA/JPL Requirements: Jane Cleland-Huang, DePaul University

Software Engineering Radio: Robert Blumen, Symphony Commerce Software Technology: Christof Ebert, Vector Sounding Board: Philippe Kruchten, University of British Columbia Voice of Evidence: Rafael Prikladnicki, Pontifica Universidade Catolica do Rio Grande do Sul

Illinois at Urbana-Champaign Ayse Basar Bener, Ryerson University Jan Bosch, Chalmers Univ. of Technology Anita Carleton, Carnegie Mellon Software Engineering Institute Jeromy Carriere, Google Taku Fujii, Osaka Gas Information System Research Institute

Gregor Hohpe, Allianz SE Magnus Larsson, ABB Ramesh Padmanabhan, NSE.IT Rafael Prikladnicki, PUCRS, Brazil Walker Royce, IBM Software Helen Sharp, The Open University Girish Suryanarayana, Siemens Corporate Research & Technologies

Evelyn Tian, Ericsson Communications Douglas R. Vogel, City Univ. of Hong Kong James Whittaker, Microsoft Rebecca Wirfs-Brock, Wirfs-Brock Associates

LinkedIn Ambassador: Rajesh Vasa, Swinburne NICTA Software Innovation Lab; [email protected] Metrics: Marco Torchiano, Politecnico di Torino; [email protected]

Newsletter Editor: Kunal Taneja, Accenture; [email protected] Online and Social Network Engagement: Alexander Serebrenik, Eindhoven University of Technology; [email protected]

Twitter Ambassador: Marco Torchiano, Politecnico di Torino; marco.torchiano@ polito.it

ICSE, SPLC, and ICSR: Eduardo Santana de Almeida, Federal University of Bahia; [email protected] ICSME: Nicholas Kraft, ABB Corporate Research; [email protected] MODELS: Jordi Cabot, Universitat Oberta de Catalunya; [email protected] PROMISE: Leandro Minku, University of Birmingham; [email protected] Requirements Engineering: Birgit Penzenstadler, California State University, Long Beach; birgit.penzenstadler@ csulb.edu

Software Product Line Conferences: Rafael Capilla, Rey Juan Carlos University of Madrid; [email protected] WCRE: Aiko Yamashita, Mesan AS, Norway; [email protected]. WICSA: Henry Muccini, University of L’Aquila, Italy; [email protected] Constituency Ambassadors Infosys and India: Naveen Kulkarni, Infosys; [email protected] Medical Software: Jens H. Weber University of Victoria; [email protected]

The Research Triangle: Nicholas Kraft, ABB Corporate Research; [email protected] The Software Center: Miroslaw Staron, University of Gothenburg; miroslaw. [email protected] Spain and Latin America: Xabier Larrucea, Tecnalia; xabier.larrucea@ tecnalia.com

Italian: Damian A. Tamburri, Politecnico Di Milano; [email protected] Japanese: Taku Fujii, Osaka Gas Information System Research Institute; [email protected] Portuguese: Rui Abreu, Palo Alto

Research Center; [email protected] Rafael Prikladnicki, Pontifica Universidade Catolica do Rio Grande do Sul; rafael [email protected]

Spanish: Jordi Cabot, Universitat Oberta de Catalunya; [email protected] Swedish: Robert Feldt, Blekinge Institute of Technology; [email protected]

D E PA R T M E N T E D I T O R S Chair: Richard Selby, Northrop Grumman Conference Reports: Jeffrey Carver, University of Alabama Impact: Michiel van Genuchten, VitalHealth Software; Les Hatton, Oakwood Computing Associates Insights: Cesare Pautasso, University of Lugano; Olaf Zimmermann, University of Applied Sciences

A DV I S O RY B OA R D Ipek Ozkaya (Chair), Carnegie Mellon Software Engineering Institute Zeljko Obrenovic (Constituency Ambassadors Manager), Software Improvement Group Don Shafer (Initiatives Team Chair), Athens Group Tao Xie (Awards Chair), University of

I N I T I AT I V E S T E A M Blog Editor: Meiyappan Nagappan, University of Waterloo; [email protected] Facebook Ambassador: Damian A. Tamburri, Politecnico Di Milano; [email protected]

CONFERENCE CORRESPONDENTS ASE, FSE, ESEC, and ISSTA: Rui Abreu, Palo Alto Research Center; [email protected] Communicating Process Architectures: Alistair McEwan, University of Leicester; [email protected] Computer-Aided Verification: Zvonimir Rakamaric, University of Utah; zvonimir@ cs.utah.edu ESEM: Marco Torchiano, Politecnico di Torino; [email protected]

T R A N S L AT I O N S Chair: Richard Selby, Northrop Grumman; [email protected] German: Jens H. Weber, University of Victoria; [email protected]

ON COMPUTING

Editor: Grady Booch IBM, grady@ computing thehumanexperience.com

Once upon a Time Grady Booch

“GIVE MY GRANDCHILD what he is crying for. Give him that one hanging on the end. That is the bag of stars.”1 And so begins the story of how Raven brought light to the world. Every culture has its creation stories, and this particular one comes to us from the Tlingit, the indigenous people of the Pacific Northwest living around the border of Alaska and British Columbia. The Tlingit came into being in a region abundant with food— salmon, halibut, herring, berries, seal, deer, bear—and so were able to evolve a richly textured culture, one fi lled with family, art, spirituality, and relative peace. This continued until contact with European explorers in 1741, fi rst the Russians, then the Spanish, and then others, after which their society underwent massive changes, largely owing to succumbing to those distinctly European diseases of smallpox, syphilis, and capitalism. Still, and even to this day, their stories and their mythology continue, for they serve to bind the Tlingit to their past and defi ne them as a proud people. Even now, Raven remains an important character. For the Tlingit and many other cultures, Raven is the trickster, a figure who mediates between life and death. Tlingit society is divided into two moieties, one descended from Raven and the other from 8

IEEE SOFTWARE

|

PUBLISHED BY THE IEEE COMPUTER SOCIETY

0740-7459/16/$33.00 © 2016 IEEE

ON COMPUTING

Eagle, and across these two divisions marriages are made. Of course, science tells us that it was not Raven who brought light to the world; it’s a bit more complex than that. However, just because something is not factual does not mean that it is not true. These stories, these myths, says Joseph Campbell, are “clues to the spiritual potentialities of human life.”2 According to Campbell, myths have four functions: The first is the mystical function, realizing what a wonder the universe is, and what a wonder you are, and experiencing awe before this mystery. The second is a cosmological dimension, the dimension with which science is concerned, showing you what shape the universe is, but showing it in such a way that the mystery again comes through. The third function is the sociological one, supporting and validating a certain social order. There is a fourth function of myth, and that is the pedagogical function, of how to live a human lifetime under any circumstances.2

Raven is a cosmological myth, the story of a pre-science culture trying to make sense of reality. In the world of computing, we have our own myths, and they too help us to make sense of this complex world of our own relatively recent invention. Even Campbell gives us a bridge between the digital and the mystical, once observing that “computers are like Old Testament gods; lots of rules and no mercy.”3 I posit that there are three kinds of computing stories: we hold myths about the world of computing, we tell stories with our computers, and we tell stories to our machines.

The Myths of Computing The creation story of Twitter is an example of the fi rst, and it illustrates that the story of computing is the story of humanity, fi lled with drama, hubris, passion, betrayal, and serendipity. Twitter was founded by Evan Williams, Biz Stone, Jack Dorsey, and Noah Glass, and as you might expect when you bash four very intense people together, sparks can fly. Nick Bilton, in Hatching Twitter: A True Story of Money, Power, Friendship, and Betrayal, gives a wonderful account of Twitter’s genesis.4 Indeed, these creation stories

it is today and additionally be intentional about the future. We don’t just tell ourselves creation stories; we also weave stories about the future. The singularity is such a myth. Ray Kurzweil was not the fi rst to tell this story. John von Neuman used the term several decades before when he spoke of the (in Stan Ulam’s words) “ever accelerating progress of technology and changes in the mode of human life, which gives the appearance of approaching some essential singularity in the history of the race beyond which human af-

The story of computing is the story of humanity, filled with drama, hubris, passion, betrayal, and serendipity.

are so interesting they have spawned a subindustry: Brad Stone’s The Everything Store: Jeff Bezos and the Age of Amazon; David Kirkpatrick’s The Facebook Effect: The Inside Story of the Company That Is Connecting the World; Steven Levy’s In the Plex: How Google Thinks, Works, and Shapes Our Lives; Emerson Pugh’s Building IBM: Shaping an Industry and Its Technology; Walter Isaacson’s Steve Jobs; and the list goes on. Why do we read these stories? It’s more than just our curiosity about the past; it’s about trying to reconcile our present. Steve and Bill and Elon and Woz are all fascinating people in their own right, and by understanding how they faced challenges, we might better understand why the world of computing is what

fairs, as we know them, could not continue.”5 Ray vastly extended this story in his book so conveniently titled The Singularity Is Near: When Humans Transcend Biology, suggesting with some remarkable degree of precision that humanity would reach the singularity around the year 2045.6 (One is reminded of another intellectual, Archbishop James Ussher, who projected back in time, declaring that the fi rst day of creation was Sunday, the 23rd of October, 4004 BCE.) Why do we tell ourselves these kinds of stories? I think it goes back to Campbell’s idea of cosmological mythology, an attempt on our part to both look back on and extrapolate forward the world as we know it at this moment in time. Personally, I think our stories of a technical

NOVEMBER/DECEMBER 2016

|

I E E E S O F T WA R E

9

ON COMPUTING

singularity spring from some very fundamental human needs—namely, a fear of our own mortality and thus a hope, a longing for something that transcends us. Do I believe in a singularity? Not at all; I think the very idea is foolish. We are a remarkably resilient species, and from the discovery of fi re, to the Black Death, to the great world wars, to our contemporary frantic, informationsaturated world, we’ve managed to adapt. Gathered on this beach of digital design, the world does not end with a bang; it moves on with a whisper (with apologies to T.S. Eliot and “The Hollow Men”).

The Digital Storyteller Continuing, we most certainly tell stories with our computers, and furthermore, we may reasonably claim that computing has given storytellers a new art form. This is perhaps most evident in the history of computer games. Roger Ebert triggered a most passionate reaction from the gamer community when, in 2010, he boldly declared that “video games cannot be art” and that “no one in or out of the field has ever been able to cite a game worthy of comparison with the great poets, fi lmmakers, novelists and poets [sic].”7 Oh my. Them’s fighting words. Ebert somewhat doubled down a few months later, when he noted, “I had to be prepared to agree that gamers can have an experience that, for them, is Art. I don’t know what they can learn about another human being that way, no matter how much they learn about Human Nature. I don’t know if they can be inspired to transcend themselves. Perhaps they can.”8 Plato once argued that writing things down was a Very Bad Thing 10

I E E E S O F T WA R E

|

because it chipped away at people being able to remember. Phonograph records were similarly condemned for taking away the spontaneity of live music and thus threatening the livelihood of many. Digital streaming has been vilified as an instrument of evil that steals from the artist. And yet, in all these cases—and especially in the case of computing— technology gives us a medium in which we can not only tell our old stories, but we can tell them, as well as new ones, in new ways. I have an Oculus Rift, and the moment I put it on for the fi rst time I was blown away by the possibilities. Not only do we use our computers to tell stories like Halo or No Man’s Sky, we now have an instrument to inject ourselves into our stories in some profound ways.

The Software–Hardware Dance Finally, we tell stories to our computers. This is the privilege and the power of the developer, and I spoke of this in my earlier column “The Stories of Possibility,” in which I said that “software is the invisible writing that whispers the stories of possibility to our hardware.”9 As a developer—especially if you are using agile methods—you fi rst shape the systems you build by crafting the stories that are important to your stakeholders. Any complex system—as in life—is formed not from a single story, but from a myriad of stories that weave in and out in subtle and exquisite ways. Next, as a developer, you write your software such that, in effect, you are telling a story to your hardware, a story that software– hardware dance will play back to the real world. In that sense, we are indeed the storytellers, we who use our software as brushes and our machines as the canvas.

W W W. C O M P U T E R . O R G / S O F T W A R E

|

And, there are so many stories yet to be told. References 1. “Raven,” Myth Recorded in English at Sitka; http://sacred-texts.com/nam /nw/tmt/tmt005.htm. 2. J. Campbell and B. Moyers, The Power of Myth, Anchor, 1991. 3. J. Campbell and P. Cousineau, The Hero’s Journey: Joseph Campbell on His Life and Work, New World Library, 2014. 4. N. Bilton, Hatching Twitter: A True Story of Money, Power, Friendship, and Betrayal, Portfolio, 2014. 5. S. Ulam, “Tribute to John von Neumann 1903–1957,” Bull. Am. Math. Soc., vol. 64, 1958, pp. 1–49. 6. R. Kurzweil, The Singularity Is Near: When Humans Transcend Biology, Penguin Books, 2006. 7. R. Ebert, “Video Games Can Never Be Art,” 16 Apr. 2010; www.roger ebert.com/rogers-journal/video -games-can-never-be-art. 8. R. Ebert, “Okay, Kids, Play on My Lawn,” 1 July 2010; www.roger ebert.com/rogers-journal/okay-kids -play-on-my-lawn. 9. G. Booch, “The Stories of Possibility,” IEEE Software, vol. 30, no. 5, 2013, pp. 14–15. GRADY BOOCH is an IBM Fellow and one of

UML’s original authors. He’s currently developing Computing: The Human Experience, a major transmedia project for public broadcast. Contact him at grady@computingthehumanexperience .com and follow him on Twitter @grady_booch.

@ I E E E S O F T WA R E

See www.computer.org /software-multimedia for multimedia content related to this article.

Editor: Cesare Pautasso University of Lugano c.pautasso@ ieee.org

INSIGHTS

Editor: Olaf Zimmermann University of Applied Sciences of Eastern Switzerla nd, Rapperswil

ozimmerm@ hsr.ch

Just Enough Anticipation Architect Your Time Dimension Eltjo Poort

A bit of planning is indispensable to anticipate events that will affect your software’s risk profile. Traditional architectural planning emphasizes the spatial dimension (for example, components and connectors) but neglects the time dimension. Consulting IT architect Eltjo Poort makes the case for an explicit representation of architectural evolution along the time axis and reports on the experiences with architecture roadmapping in his practitioner community. — Cesare Pautasso and Olaf Zimmermann ARCHITECTS IN THE digital world, such as software, enterprise, or solution architects, derive their role name from architects in the civil-construction world. The metaphor works on more than one level: architects in both worlds are responsible for conceptual (and structural) integrity and are the content leaders with overview over design and realization, making key design decisions and drawing blueprints. However, the digital world differs considerably from the civil-construction world in at least one aspect. IT-based solutions such as application software, IT infrastructure, and IT services change far more frequently then buildings do. After all, bits and bytes are easier to change than brick and mortar, right? The defi nition of architecture in the ISO/IEC 42010:2011 standard explicitly mentions evolution.1 Change is also the central theme in modern software development practices such as agile de0740-7459/16/$33.00 © 2016 IEEE

velopment and DevOps. Nevertheless, the digital-architecture disciplines seem to be lagging behind a bit in this development, perhaps hindered by the metaphor that gave them their name. My recent experiences indicate that evolution and change should be given their proper place in the digital-architecture world. So, time should become a fi rstclass concept for architects of software, infrastructure, services, enterprises, and so on.

Issues with Time-Agnostic Architectures Many software-intensive systems are part of a complex application landscape. They form systems of systems or software ecosystems with myriad interdependencies between commercial and custom-made software, hardware platforms, and organizational entities, all with their own evolution cycles. Such landscapes now occur in all industries:

NOVEMBER/DECEMBER 2016

|

IEEE SOFTWARE

11

INSIGHTS

DEALING WITH DEPENDENCIES Popular architectural styles such as service-oriented architecture (SOA) and its microservices1 variant reduce the pain of ever-changing dependencies by decoupling subsystems or components. SOA decouples applications in an IT landscape by hiding their internal behavior behind service interfaces. Using the right tools and protocols, such architectural styles achieve independent deployability at the technical level. However, these architectural styles can provide only limited relief regarding logical dependencies. After all, a service’s consumers can never use a feature that hasn’t yet been implemented in that service. If they need that feature, they must wait, and the service might gracefully fail in the meantime. In other words, logical dependencies are related to the arrow of time. Reference 1. S. Newman, Building Microservices: Designing Fine-Grained Systems, O’Reilly, 2015.

my experience ranges from banks and insurance companies, to transport and logistics, to safety, justice, and other public-sector domains. In these landscapes, a time-agnostic architecture is a perishable good: its best-before date is often only weeks in the future. I’ve observed issues such as these: • architecture documents that are perpetually “almost fi nished” (delaying the projects dependent on them) or are already obsolete when they’re issued; • development based on architectural decisions that have already been revoked (to address changing circumstances); and • difficulty planning ahead, caused by lack of insight into architectural constructs’ time dependencies. One way to address such issues is to design the solution’s evolution into the architecture. At CGI, we started developing this practice in situations with many logical depen12

I E E E S O F T WA R E

|

dencies, both inside and outside our solution scope. (For more on dealing with dependencies, see the related sidebar.) As part of our risk- and cost-driven architecture (RCDA) approach, we created architecture documentation that not only describes the current situation and expected future situation but also identifies and deals with architecturally significant events on the way from the current situation to the future situation. (RCDA is a set of architecture practices and principles CGI uses to design IT-based solutions for clients in a lean, agile manner.2) These events can be changes in the logical dependencies, such as a feature becoming available on a service, or an external system changing its behavior. But, as the following examples show, they can also be other occurrences that affect the solution’s risk, cost, or business value. Explicitly anticipating such events not only helps address the issues just identified but also is instrumental in fulfilling architecture’s role as a risk

W W W. C O M P U T E R . O R G / S O F T W A R E

|

management discipline, by addressing time-triggered risks. This practice also increases the documentation’s practical value in cases in which the future state turns out to be a moving target. When the world keeps changing, documentation that acknowledges change stays more relevant than documentation that doesn’t.

Architecting Time: An Evolution Viewpoint According to ISO/IEC 42010:2011, architecture documentation consists of views that represent the architecture from certain viewpoints. These viewpoints aim to demonstrate to stakeholders how the architecture addresses a particular set of their concerns. Philippe Kruchten’s 4+1 view model gives five good examples of viewpoints that do this for common stakeholder concerns.3 How about adding an evolution viewpoint that shows how the architecture addresses the impact of changes in the solution’s environment? Nick Rozanski and Eoin Woods introduced an evolution perspective in which the architecture explicitly considers change.4 One activity related to this perspective is to characterize a system’s evolution needs. To do this, an evolution viewpoint fi rst identifies future events that will have an architectural impact on the solution and then shows how the architecture anticipates them. Considering architecture as a risk- and cost-management discipline, 2 we’re interested in the events’ architectural impact in economic terms: risk, cost, and business value. Translating the events’ direct technical impact into those terms helps us communicate about the events with business stakeholders5 and helps us select the most important events if we can’t deal with all of them.

@ I E E E S O F T WA R E

TABLE 1

INSIGHTS

Some future events with architectural impact. Event

When expected

Impact type

Impact

A competitor releases its nextgeneration product.

4th quarter 2017

Risk + business value

If we don’t match our competition’s new features, our own product will be harder to sell, and we’ll lose revenue.

Microsoft discontinues Windows XP support.

Apr. 2014

Risk

Vulnerabilities are no longer patched. This implies a security risk—for example, the risk of intrusion and data leaks.

Our Corilla license contract expires.

May 2017

Cost

We could reduce costs by switching to an open source alternative.

A new version of Java EE (Enterprise Edition) application servers (for IBM WebSphere and JBoss) is released.

Nov. 2015

Cost

We could reduce maintenance costs by using new features announced for the next version of Java EE.

The project to build system Y finishes.

1st quarter 2017

Risk + business value

System Y (which is interdependent with ours) will require interface features that our solution currently doesn’t support. We must build these features, or our solution will lose its business value.

Table 1 shows some typical events and their architectural impact. As you can see, most of them are associated with risks. This is inherent in the definition of a “future event with architectural impact” in two ways. First, in a view of architecture as a risk- and cost-management discipline, an item’s architectural significance is closely related to its risk (and cost) impact.2 Second, any point in time at which a solution’s cost or value significantly changes has a deadline-like nature, and every deadline brings a risk of being too late. In fact, a project’s risk register is often a good source to search for such time-triggered events that need to be anticipated in the architecture. The second step in characterizing the system’s evolution needs is to identify backlog items for the solution’s evolution, which will potentially end up on the solution roadmap. At this stage, it’s important to understand the dependencies between the solution architecture and the architecturally significant events. The backlog items should be linked

to the components, modules, functions, nodes, and other architectural elements they touch in the design. On the basis of the dependencies between architectural elements, backlog items, and events, the architect can engage in economic reasoning about the roadmap with relevant stakeholders such as product owners, project managers, and product managers. For an example of an architecture roadmap visualizing these improvement items, including their dependencies on each other and on the significant events, see the sidebar “An Example of Architecture Roadmapping.” The economic reasoning is possible because we previously identified future events’ impact on the solution’s risk, cost, and business value. For example, the team might decide to take on some technical debt to make a release deadline in time for new reporting regulations coming into effect, if their analysis shows that the potential drop in the product’s value (if the deadline is missed) is greater than the interest incurred by the technical debt. (Technical

debt6 is a metaphor Ward Cunningham developed. The increased cost of modifications due to work left undone in a system, such as refactoring and upgrading, is compared to the interest paid on a loan. Doing that work is equivalent to paying back the loan.) For more details on this economic reasoning, see “Enabling Agility through Architecture,”7 which describes these activities as steps to achieve “informed anticipation” in software architecture. Like other viewpoints, the evolution viewpoint can be a chapter in an architectural description document or a stand-alone artifact prepared specifically for interested stakeholders. Because this viewpoint aims to deal with change and aims to work in volatile environments, a more dynamic medium such as a project or product wiki might also be suitable. Anyone with concerns related to change and planning is a stakeholder of the evolution viewpoint—­ specifically project, program, or product managers; product owners; and architects, designers, or developers

NOVEMBER/DECEMBER 2016

|

I E E E S O F T WA R E

13

INSIGHTS

AN EXAMPLE OF ARCHITECTURE ROADMAPPING Figure A shows the architecture Release 1.3 Release 2.0 Release 2.1 Release 2.2 Release 2.3 roadmap for a fictitious scenario; the Q1 2017 Q2 2017 Q3 2017 Q4 2017 Q1 2018 roadmap uses Philippe Kruchten’s New Competitor releases color-coding scheme for backlog Project W reporting next-generation items.1 In this scenario, our competifinishes regulations platform tor has announced it will release a next-generation version of its platform BuyYourTripsHere.com in the fourth F quarter of 2017. Our team’s product manager has identified a crucial feaA ture (F in Figure A) that our product, T AdventuresBeyondBelief.com, must have in place before the competitor’s Dependency User feature Architectural improvement next-generation release: the ability to Defect removal Technical-debt reduction check whether a hotel has free Wi-Fi. If we don’t have that feature in place in time, we expect a 25 percent marFIGURE A. An architecture roadmap. F is a crucial feature (a website’s ability ket share loss—a potential drop of to check whether a hotel has free Wi-Fi), A is a change necessary before F can $250,000 in business value. be implemented (an upgrade to a hotel communication platform), and T is the F is a functional feature but drives payment of technical debt through refactoring. architecture roadmapping because it depends on an architectural improvement (A in Figure A): our hotel communication platform must be upgraded to the latest version. Also, the free-Wi-Fi information must be exposed on the back office’s integration hub (for example, an enterprise service bus), but we can’t achieve this in time. The team decides to perform A and F in time to beat the competitor and to create a temporary solution bypassing the integration hub. This temporary solution means that the team will accrue technical debt, but we’ve estimated that the debt’s interest will be much lower than $250,000. Refactoring (T in Figure A) to replace the temporary solution with a proper connection over the integration hub is planned for the subsequent release. Reference 1. P. Kruchten, R.L. Nord, and I. Ozkaya, “Technical Debt: From Metaphor to Theory and Practice,” IEEE Software, vol. 29, no. 6, 2012, pp. 18–21.

working on other solutions in the same interdependent system of systems. The evolution viewpoint helps the managers and product owners plan ahead. By acknowledging future events in the time dimension, it helps fellow workers who depend on your architecture, by telling them what aspects of the architecture will change (for example, the integration hub or interfaces) and when. The viewpoint 14

I E E E S O F T WA R E

|

provides important input to project management tools such as risk registers and Gantt charts, and to product owners populating and prioritizing sprint backlogs in agile projects.

Experiences in Architecture Roadmapping The approach we just described has been applied in parts of CGI since 2012. This roadmapping aims to fi nd

W W W. C O M P U T E R . O R G / S O F T W A R E

|

the right balance between overanticipation and underanticipation in implementing architectural constructs. Architectural constructs are underthe-hood parts of a solution. They include things such as abstraction layers, fi rewalls, or caching mechanisms, which typically aren’t visible to users but are needed to achieve quality attributes such as modifiability, security, or performance. Over-

@ I E E E S O F T WA R E

INSIGHTS

anticipation typically manifests itself in architectural constructs that over time turn out to be less valuable than the trouble of creating them was worth. (This phenomenon is called YAGNI [you aren’t gonna need it] in agile circles.8) Underanticipation often occurs when architectural constructs are implemented too late, causing the solution to accrue technical debt and making it increasingly difficult to add features in an evolutionary manner. Naturally, the time dimension is crucial to achieving the right amount of anticipation. Our architects have been using architecture roadmapping in many contexts and domains, for time spans between one and six years ahead. Their anticipation documents are often quite informal, never called an evolution viewpoint but rather a “roadmap,” “decision support,” or a “strategy document.” Their architectures typically take into account these timed events: • project or process milestones, such as delivery and approval deadlines, and deadlines in dependent projects; • product version or infrastructure upgrades; • business changes due to various reasons—for example, changes in external agreements (such as Key Performance Indicators), mergers or takeovers, or legislative or policy changes; and • changes in the availability of resources, including the availability of expertise. These anticipated events generally affect a combination of risk, cost, and business value. For example, a delivery deadline typically has impact in terms of the cost of delay and risk of losing customers. The introduction

of a product version upgrade could add business value by supporting new features. However, it could also represent a risk if the product’s supplier discontinues support for a previous version (or changes the product’s backward-compatibility policy). Our architects reported significant benefits from making the time dimension part of their architecture in this way. The benefits mentioned most were improved (more realistic) stakeholder expectations and better prioritization of required architectural improvements. This is because architecture roadmapping helps architects articulate evolution scenarios’ business impact. It also helps them discuss the timing of architectural improvements on the basis of that business impact, rather than on the basis of generic (and sometimes dogmatic) “rules” such as YAGNI or “Do not optimize prematurely.” Some of our architects also stressed the importance of stakeholder communication to identify anticipated events.

D

ing with Cost and Risk,” IEEE Software, vol. 31, no. 5, 2014, pp. 20–23. 3. P. Kruchten, “The 4+1 View Model of Architecture,” IEEE Software, vol. 12, no. 6, 1995, pp. 42–50. 4. N. Rozanski and E. Woods, Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives, 2nd ed., Addison-­ Wesley, 2011. 5. J. Schulenklopper and E. Rommes, “Why They Just Don’t Get It: Communicating about Architecture with Business Stakeholders,” IEEE Software, vol. 33, no. 3, 2016, pp. 13–19. 6. P. Kruchten, R.L. Nord, and I. Ozkaya, “Technical Debt: From Metaphor to Theory and Practice,” IEEE Software, vol. 29, no. 6, 2012, pp. 18–21. 7. N. Brown, R.L. Nord, and I. Ozkaya, “Enabling Agility through Architecture,” CrossTalk, Nov./Dec. 2010, pp. 12–17. 8. M. Fowler, “Yagni,” blog, 26 May 2015; http://martinfowler.com/bliki /Yagni.html. ELTJO POORT is a solution architect at CGI.

ocumenting the time dimension part of your architecture might look like extra work. However, anticipation should be a large part of your job as an architect, anyway. If you communicate your anticipation as an evolution viewpoint or architecture roadmap, your architecture description will stay valid longer. And, you’ll have a ready answer when stakeholders ask how you’ve addressed their change and planning concerns.

Contact him at [email protected].

References 1. ISO/IEC 42010:2011, Systems and Software Engineering—Architecture Description, ISO, 24 Nov. 2011; www.iso-architecture.org/42010. 2. E.R. Poort, “Driving Agile Architect-

Selected CS articles and columns are also available for free at http://ComputingNow.computer.org.

NOVEMBER/DECEMBER 2016

|

I E E E S O F T WA R E

15

Editor: Jane Cleland-Huang DePaul University [email protected]

REQUIREMENTS

Caring An Undiscovered “Super -ility” of Smart Healthcare Nancy Laplante, Phillip A. Laplante, and Jeffrey Voas

16

IEEE SOFTWARE

|

CONSIDER A COMPLEX, smart healthcare system, whether it’s an assistive or therapeutic device, record management system, diagnostic system, physicianorder-entry system, or any healthcarerelated hardware or software system. These systems aim to improve the degree of certain qualities or attributes (“-ilities”) such as availability, privacy, reliability, safety, security, and, moreover, their nonintelligent counterparts. Collectively, systems that focus on these qualities are intended to improve health outcomes, reduce costs, and enhance the quality of life. However, these technologies can affect the patient’s perception of caring in a way that no other quality or group of qualities can completely capture. For example, consider leveraging the Internet of Things (IoT) to build smart healthcare technology. It’s not apparent how a healthcare system, such as one that monitors a patient and delivers medications or anesthetics, can care about the patient’s sufferings, feelings, and emotional needs. We need to more effectively capture the notion of caring so that we can somehow build it into systems that leverage commercial IoT components and services.

attributes, but it’s far more. Caring can be defi ned as a noun, a verb, or an adjective. Defi nitions of caring abound in dictionaries and have been given by professions both inside and outside healthcare. In trying to defi ne a notion of caring that’s meaningful to systems engineers, computer scientists, and, most important, patients, it’s advisable to consider the views of those in the profession that’s been rated as the most trusted because of its reputation for caring: nursing. Defi nitions of caring and related terms appear in the nursing literature and have been offered by various professional nursing organizations and healthcare institutions. Caring can be described as an act or as a way to approach patients. It can be a person’s trait, and it’s often an adjective describing someone perceived to be a good nurse. Vicki Lachman pointed out that “Caring and nursing are so intertwined that nursing always appeared on the same page in a Google search for the defi nition of caring.”1 For this discussion, we adopt caring as an adjective with this defi nition:

What Caring Is Caring is a qualitative behavioral attribute that encompasses aspects of many

This simple defi nition allows for the exploration of caring in relation to smart healthcare systems, without being too

PUBLISHED BY THE IEEE COMPUTER SOCIETY

0740-7459/16/$33.00 © 2016 IEEE

Displaying kindness and concern for others.2

REQUIREMENTS

specific to a particular nursing specialty or even to healthcare. The notion of displaying kindness and concern leads us to picture the relationship between the nurse and patient. This relationship will look different in a traditional face-to-face encounter without technology than in a smart healthcare application incorporating technologies such as remote monitoring or applications in the IoT. This defi nition of caring isn’t unique to nursing or healthcare, but it’s appropriate in our context. We can organize -ilities into hierarchies based on the context, application, and environment. In healthcare systems, at least, we contend that caring subsumes the -ilities we mentioned previously and several others. Seeking improvement in any or all of these other qualities out of concern for the patient is a part of caring, but it’s not enough. Caring is much more than system optimization; because it subsumes the other -ilities, we call it a “super -ility.”

A Nursing Perspective on Caring Nursing is often described as an art and a science, and people have discussed caring from both these perspectives. Nursing is also a human science that incorporates the art of caring. As of 2015, nurses had been rated as the most honest, ethical profession for the 14th-straight year. 3 This high rating was built on a relationship that combines trust, caring, and a personal connection with the public. Nursing theory has helped defi ne and build a scientific body of evidence concerning the profession. Many nursing theories focus on caring or its aspects. For example, one of the most recognized and studied

theories is Jean Watson’s theory of human caring. From its inception in the late 1970s, it has distinguished nursing from other healthcare disciplines and has highlighted the unique work of the profession. Watson’s theory has several core concepts; the one that most likely relates to smart healthcare systems and caring is a focus on the transpersonal caring relationship. This relationship encompasses a moral commitment to protect and enhance human dignity.4 It involves honoring another person’s needs and wishes; honoring that person’s wholeness, not just the physical self; maintaining balance; connecting to human beings; consciously doing

instrument based on a seven-point Likert scale that rates caregivers on certain caring practices. These practices include the environment, concepts of trust, meeting human needs, and feeling valued. The WCPS has been translated into five languages, and versions exist to assess the caring practices of hospital staff, colleagues, and peers. Ngozi Nkongho developed another scale—the Caring Ability Inventory. 5 This self-administered instrument uses four theoretical assumptions: caring is multidimensional, we all have the potential to care, caring can be learned, and caring is quantifi able. Both Watson’s and Nkongho’s work provides

At the heart of nursing is the intention to care for the whole person.

and being with another person; and honoring the connection through authentic presence. At the heart of nursing is the intention to care for the whole person, and Watson’s theory has provided that guidance for nurses in a multitude of practice settings. It could be applied to a smart healthcare system to explore the transpersonal caring relationship in situations involving remote technologies.

Measuring Caring In relation to nursing research, Watson developed a tool to assess perspectives of caring practices: the Watson Caritas Patient Score (WCPS).4 The WCPS is a survey

theoretical support for measuring caring and provides tools to help requirements engineers, systems builders, and test engineers evaluate their systems from this perspective. These measures could also be used to compare systems and provide opportunities to improve healthcare delivery. Whatever mechanism is used to measure caring, the degree to which a patient feels cared for depends on the patient’s perception. Static mechanisms, such as measuring contact time or analyzing words exchanged between the caregiver and patient, can provide quantitative evidence of caring, but only if the patient agrees that he or she feels cared for.

NOVEMBER/DECEMBER 2016

|

I E E E S O F T WA R E

17

REQUIREMENTS

We might assume that technology will increase the caring distance. However, caring could be estimated higher in a smart healthcare system than in its nonsmart equivalent. For example, as nurses become more aware of technology’s benefits in caring for patients, this increased knowledge might enhance caring relationships. The nurse’s comfort level in using technology could affect all parties’ perception of caring. We expect that smart healthcare systems will have specific requirements for caring—for example, to minimize the increase in the caring distance to comply with some standard. Research to determine that standard minimum level of caring will also be needed. For healthcare systems to continue to advance, technology must be an early, ongoing part of the conversation with stakeholders, particularly nurses. Nurses lead the day-to-day care of hospitalized patients and are usually the healthcare providers having the most patient contact. Technology can help nurses provide better patient care, but nurses must value and integrate these technologies and not see them as an impediment. Nurses must be involved early in requirements elicitation of smart healthcare

Patient

Caring distance, d Patient

Nurse System Caring distance, d New caring distance, d + ∆

FIGURE 1. An Internet of Things–based healthcare system increasing the caring distance between the nurse and patient. A goal is to design smart healthcare systems that can decrease this distance.

Caring Systems

march • april 2016

nov ember • december 2015

may • june 2016

jaNUaRy • fEbRUaRy 2016 INTERNET ECONOMICs

ClOUd sTORaGE

MEasURING ThE INTERNET

ExPlORING TOMORROw’s INTERNET

ThE INTERNET Of YOU

VOl. 20, NO. 1

www.COMPUTER.ORG/INTERNET/

www.COMPUTER.ORG/INTERNET/

www.COMPUTER.ORG/INTERNET/

VOl. 20, NO. 3

VOl. 20, NO. 4

www.COMPUTER.ORG/INTERNET/

www.COMPUTER.ORG/INTERNET/

VOl. 20, NO. 2

vOl. 19, NO. 6

October 9, 2015 3:26 PM

IEEE INTERNET COMPUTING

May • jUNE 2016

jUly • aUGUsT 2016

MaRCh • aPRIl 2016

NOvEMbER • DECEMbER 2015

Cover-1

IEEE INTERNET COMPUTING

IEEE INTERNET COMPUTING

IEEE INTERNET COMPUTING

IEEE INTERNET COMPUTING

IC-19-06-c1

july • august 2016

A system might increase or decrease the “caring distance” between the caregiver (for example, a nurse) and patient (see Figure 1). This distance could be determined by some administration of the WCPS or Caring Ability Inventory. For example, we could use one WCPS component for the caring distance or use all the components and treat the caring distance as a vector. We can estimate the change in the caring distance through controlled studies of nonsmart (for example, local) versus smart (for example, IoT-enabled) systems using the WCPS or another metric.

Systems can’t care about people, except, perhaps, in a Turing test sense (that is, the system behaves indistinguishably from a human), although a person might have the perception that a system cares or doesn’t care about his or her well-being. Also, the patient might have still complained about (or possibly praised) a smart healthcare system had that system been a human and capable of caring. But, setting aside this AI sense of caring, how do you incorporate caring into a smart healthcare system and measure that quality?

IC-20-01-c1

IC-20-03-c1

IC-20-02-c1

Cover-1

january • february 2016

Nurse

Cover-1

Cover-1

December 7, 2015 1:45 PM

April 13, 2016 8:45 PM

February 11, 2016 10:30 PM

Want to know more about the Internet?

This magazine covers all aspects of Internet computing, from programming and standards to security and networking.

www.computer.org/internet

18

I E E E S O F T WA R E

|

W W W. C O M P U T E R . O R G / S O F T W A R E

|

@ I E E E S O F T WA R E



REQUIREMENTS

systems to assure that the human connection isn’t compromised or lost. The -ility of caring shouldn’t be limited to healthcare systems. It could be a desired quality to be optimized in virtually every system that interacts with humans—for example, in smart transportation, smart homes, and smart cities. Caring should also be an important consideration in systems that interact with certain nonhuman entities such as animals and the global environment.

N

urses often struggle with balancing technology and patient contact because technology can remove them from direct contact with patients. Conversely, technology has helped improve patient care by allowing for better assessment, surveillance, and treatment. Software and systems engineers need to have the same conversation about balancing technology and human interaction while learning from the nursing profession before building smart healthcare systems (whether or not the systems are based on IoT services and products). The challenge in healthcare is to use smart technology to improve patient care while preserving human contact. Caring is about relationships, those forged between the nurse and the patient, family, and community. These relationships might manifest caring in different ways, and we need to recognize and acknowledge these differences. Caring is an -ility for smart healthcare systems that’s complex and difficult to capture, and it deserves further study. Because caring is so important, it must not be lost; that’s why we designate it as a super -ility. Technology can augment the human touch but can’t replace it.

E DI T O R I A L S TAFF

References 1. V.D. Lachman, “Applying the Ethics of Care to Your Nursing Practice,” MEDSURG Nursing, vol. 21, no. 2, 2012, pp. 112–116. 2. “Caring,” Oxford Dictionaries, 2016; www.oxforddictionaries.com /us/defi nition/american_english /caring. 3. “Nurses Rank as Most Honest, Ethical Profession for 14th Straight Year,” Am. Nurses Assoc., 21 Dec. 2015; http://nursingworld.org /FunctionalMenuCategories/Media Resources/PressReleases/2015-NR /Nurses-Rank-as-Most-Honest -Ethical-Profession-for-14th-Straight -Year.html. 4. “Watson Caritas Patient Score (WCPS),” Watson Caring Science Inst., 2016; www.watsoncaringscience.org /watson-caritas-patient-score. 5. K. Douglas, “When Caring Stops, Staffi ng Doesn’t Matter: Part II,” Nursing Economics, vol. 29, no. 3, 2011, pp. 145–147; www.medscape .com/viewarticle/746224. NANCY LAPLANTE is an associate professor

of nursing at Widener University. Contact her at [email protected]. PHILLIP A. LAPLANTE is a professor of software and systems engineering at Pennsylvania State University. Contact him at plaplante@ psu.edu. JEFFREY VOAS is a computer scientist at the US National Institute of Standards and Technology, a cofounder of Cigital, and Computer’s Cybertrust column editor. He’s an IEEE Fellow. Contact him at [email protected].

NOVEMBER/DECEMBER 2016

Lead Editor: Brian Brannon, [email protected] Content Editor: Dennis Taylor Staff Editors: Lee Garber, Meghan O’Dell, and Rebecca Torres Publications Coordinator: [email protected] Lead Designer: Jennie Zhu-Mai Production Editor: Monette Velasco Webmaster: Brandi Ortega Multimedia Editor: Erica Hardison Illustrators: Annie Jiu, Robert Stack, and Alex Torres Cover Artist: Peter Bollinger Director, Products & Services: Evan Butterfield Senior Manager, Editorial Services: Robin Baldwin Manager, Editorial Services Content Development: Richard Park Senior Business Development Manager: Sandra Brown Senior Advertising Coordinators: Marian Anderson, [email protected] Debbie Sims, [email protected] C S P U B L I C AT I O N S B OA R D

David S. Ebert (VP for Publications), Alain April, Alfredo Benso, Laxmi Bhuyan, Greg Byrd, Robert Dupuis, Jean-Luc Gaudiot, Ming C. Lin, Linda I. Shafer, Forrest Shull, H.J. Siegel M AG A Z I N E O P E R AT I O N S COMMITTEE

Forrest Shull (chair), M. Brian Blake, Maria Ebling, Lieven Eeckhout, Miguel Encarnação, Nathan Ensmenger, Sumi Helal, San Murugesan, Yong Rui, Ahmad-Reza Sadeghi, Diomidis Spinellis, George K. Thiruvathukal, Mazin Yousif, Daniel Zeng Editorial: All submissions are subject to editing for clarity, style, and space. Unless otherwise stated, bylined articles and departments, as well as product and service descriptions, reflect the author’s or firm’s opinion. Inclusion in IEEE Software does not necessarily constitute endorsement by IEEE or the IEEE Computer Society. To Submit: Access the IEEE Computer Society’s Webbased system, ScholarOne, at http://mc.manuscriptcentral .com/sw-cs. Be sure to select the right manuscript type when submitting. Articles must be original and not exceed 4,700 words including figures and tables, which count for 200 words each. IEEE prohibits discrimination, harassment and bullying: For more information, visit www.ieee.org/web/aboutus /whatis/policies/p9-26.html.

See www.computer.org /software-multimedia for multimedia content related to this article.

|

I E E E S O F T WA R E

Promoting Sustainable Forestry SFI-01681

19

PRACTITIONERS’ DIGEST

Editor: Jeffrey C. Carver University of Alabama [email protected]

Trends in Agile Perspectives from the Practitioners Rafael Prikladnicki, Casper Lassenius, Evelyn Tian, and Jeffrey C. Carver

THE AGILE CONFERENCE (www .agilealliance.org/agile2016) is the largest global conference on agile software development, catering particularly to practitioners. Agile 2016 had a record 2,500 participants. Here, we report on two keynotes and a new IEEE Software conference initiative.

In the fi rst keynote, Jurgen Appelo, known for his work on agile leadership, including Management 3.0 and the Management 3.0 Workout, discussed “managing for happiness,” based on research showing that happy workers are more productive. He shared the following concrete practices for happier organizations. Personal maps is an exercise to better understand people by capturing what you know about them into a personal mind map. It improves collaboration by helping people get closer to others and better understand their work. Delegation boards and delegation poker build on situational leadership and a responsibility assignment matrix containing seven steps to empower through delegation. Delegation boards provide an overview of the current delegation situation, focusing on moving forward. Delegation poker helps people understand how others handle the same

situation. These two tools let management clarify the difficult task of delegation and empower both management and workers. Merit money is an alternative to traditional compensation. Paying people for work without destroying their motivation is one of the most difficult management challenges. Merit money is based on real merit instead of imagined performance. For example, earnings can be based on collaboration as measured by peer feedback during performance reviews. Celebration grids visually report successes and failures in a positive atmosphere to foster learning from practices, experiments, and mistakes. All too often, organizations live day by day, from one crisis to another, and forget to take note of the good things that have happened. Celebration grids help focus on the positives, even in mistakes and failures. Figure 1 illustrates a celebration grid. Appelo believes that managing for happiness is relevant for managers and everyone concerned about the organization. Organizations have a happier environment when people manage themselves and lead by example through experiments and learning. All creative workers are expected to be servant leaders and systems thinkers. For more information, see www.slideshare .net/AgileME/managing-for-happiness

PUBLISHED BY THE IEEE COMPUTER SOCIETY

0740-7459/16/$33.00 © 2016 IEEE

Keynotes

20

IEEE SOFTWARE

|

PRACTITIONERS’ DIGEST



Experiments

Practices

Success

You lucky so-and-so!

Yay, you succeeded and you learned!

Yay, you succeeded by doing the right things!

Failure

Outcome

Mistakes

Dude, you screwed up! Where’s your brain?

No learning

OK, you failed but you learned!

Argh, bad luck!

Learning

Failure

• Make people awesome. Ask how you can make people in your ecosystem, including those who fund, make, sell, buy, or use products or services, awesome. Then, discover and deliver what makes them happy. • Make safety a prerequisite. Safety is a basic human need and a key to unlocking high performance. Establish safety before engaging in any work, and endeavor to make collaborations, products, and services resilient and safe. • Experiment and learn rapidly. Learn rapidly through frequent experiments that are safe to fail, so that there’s no fear of conducting more experiments. Being stuck or not learning indicates the need to experiment more. • Deliver value continuously. Anything valuable that hasn’t been delivered isn’t helping anyone. Try to discover small pieces

Behavior

Success

-by-jurgen-appelo or Appelo’s book Managing for Happiness.1 In the second keynote, Joshua Kerievsky, CEO of Industrial Logic, talked about Modern Agile (http:// modernagile.org), which emphasizes the need for agile principles rather than practices. Over the past decade, innovative companies, software industry thought leaders, and lean or agile pioneers have discovered simpler, sturdier, and more streamlined ways to be agile. The focus has shifted from following rituals to producing meaningful outcomes. He argued that although there’s timeless wisdom in agile, practitioners would do well to bypass outmoded agile practices in favor of modern approaches. Modern Agile has four guiding principles (see Figure 2):

No learning

FIGURE 1. A celebration grid visually reports successes and failures in a positive atmosphere to foster learning from practices, experiments, and mistakes. (Figure based on an idea by Jurgen Appelo.)

that might be delivered safely now rather than later. Ask, “How could we deliver the right outcomes faster?”

The Future of Scrum

Dave West from Scrum.org gave a talk on Scrum’s future. Noting that Scrum forms the basis of most agile implementations in industry, he Companies such as Google, Ama- identified several pervasive probzon, Airbnb, and Etsy are proof of lems related to both practical Scrum these principles’ power. Kerievsky implementation and enterprise-level also discussed how Modern Agile agility. In practice, many Scrum im­ addresses key risks while targeting plementations become trapped in results over rituals. He concluded traditional organizational processes, by revealing how to update the 2001 turning into “water-Scrum-falls” Agile Manifesto to reflect Modern rather than real agile Scrums. Agile’s four guiding principles. To aid organizations in Scrum and enterprise implementations, Scrum’s creators have recently pubThe Practitioner Conference lished several improvements and Outreach Initiative At Agile 2016, IEEE Software inau- additions. These include the addigurated its practitioner conference out- tion of values to Scrum, the Nexus reach initiative to increase the maga- framework for scaling Scrum up to zine’s visibility and recognition among nine teams working on the same practitioners. In collaboration with product, and a set of metrics for the Agile Alliance (www.agilealliance​ evaluating Scrum implementations. .org), IEEE Software chaired the Fu- In the near future, they’ll release ture of Agile Software Development a Scrum software developer’s kit, track. Here we report on two of the which will provide help for Scrum track’s five presentations, which drew implementations in areas such as the definition of “done,” practices, more than 700 participants. NOVEMBER/DECEMBER 2016

|

I E E E S O F T WA R E

21

PRACTITIONERS’ DIGEST

T

he software industry has benefitted tremendously from the adoption of agile methods and practices. Agile has changed how organizations provide products and services. The Agile Conference is a great venue for current practices, trends, and knowledge related to the area.

Make people awesome

Modern Agile Experiment and learn rapidly

Deliver value continuosly

Acknowledgments We thank Joshua Kerievsky, Dave West, and Robert Woods for their valuable review of and feedback on this article. They also thank the Agile Alliance and IEEE Software for the opportunity to collaborate on the magazine’s new initiative.

Make safety a prerequisite

FIGURE 2. Modern Agile emphasizes the need for agile principles rather than practices. (Figure based on an idea by Joshua Kerievsky.)

tools, development standards, and environments. Finally, Scrum Studio provides a new approach to enterprise agility by separating agile products from the traditional IT ­organization to free them from existing organizational values and processes. Scrum Studio can be seen as complementary to Gartner’s bimodal IT and the ideas in John ­Kotter’s book Accelerate (XLR8). 2

Digital Disruption Robert Woods described the digital disruption that has emerged in organizations trying to become adaptive, collaborative, agile, and innovative without fear of failure. This disruption includes innovations that change the landscape of successful modern businesses. Conversely, there appears to be a troubling lack of ability to adapt and change when digital disruption occurs. You could argue that the agile mind-set created digital disruption that’s forcing people to be more agile. Woods described several agile 22

I E E E S O F T WA R E

|

trends that will compensate for digital disruption, including • malleable frameworks that adapt to the teams using them, • tools that adapt to how a team works as opposed to dictating it, • a focus on short-term metrics because rapid change results in obsolete metrics, • globally dispersed teams that can collaborate and function just as well as collocated teams, and • agile financials that focus more on quickly delivered value rather than year-long or multiyear financial commitments. In summary, he believes that although digital disruption has been considered a new trend, soon it won’t be considered disruption at all. It will be how business is done. The world just has to be more agile to keep up with it. For more information, visit www.matrixres.com /resources/ blogs/2016 - 01/digital -disruption-the-future-of-agile.

W W W. C O M P U T E R . O R G / S O F T W A R E

|

References 1. J. Appelo, Managing for Happiness: Games, Tools, and Practices to Motivate Any Team, John Wiley & Sons, 2016. 2. J. Kotter, Accelerate (XLR8), Harvard Business Rev. Press, 2014. RAFAEL PRIKLADNICKI is an associate

professor at the Computer Science School and the director of the Science and Technology Park (Tecnopuc) at the Pontifical Catholic University of Rio Grande do Sul, where he also leads the MuNDDoS research group. He’s also on IEEE Software’s editorial board. Contact him at [email protected]. CASPER LASSENIUS is a professor of soft-

ware engineering at Aalto University. He’s also on IEEE Software’s editorial board. Contact him at [email protected]. EVELYN TIAN is the head of Ericsson’s Global Transformation Support Center. She’s also on IEEE Software’s advisory board. Contact her at [email protected]. JEFFREY C. CARVER is an associate profes-

sor in the University of Alabama’s Department of Computer Science. Contact him at carver@ cs.ua.edu.

@ I E E E S O F T WA R E

Editor: Michiel van Genuchten VitalHealth Sof tware genuchten@ ieee.org

IMPACT

Editor: Les Hatton Oakwood Computing Associates [email protected]

When Software Impacts the Economy and Environment Edleno Silva de Moura, Mauro Rojas Herrera, Leonardo Santos, and Tayana Conte

With this issue’s column from Amazonia, the Impact department has now covered software from six continents in seven years. This column is the first to look specifically into environmental impact. —Michiel van Genuchten and Les Hatton WHEN CUSTOMERS VISIT a Brazilian e-commerce site and search for a product, they’re likely using software developed by Neemu, a start-up created in Manaus, a city in the heart of the Amazon rainforest. Nowadays, millions of people throughout Brazil use this software, which demonstrates alternative economic development in Amazonia that has a low impact on the environment. Neemu’s flagship product is a search tool that uses the software-as-a-service model. Clients pay a monthly fee according to the number of queries the system processes. At fi rst glance, search looks like a commodity solution that’s easily acquired and that doesn’t aggregate that much value to an e-commerce operation. Several low-cost or even free solutions are available. However, e-commerce site operators know that search systems are a key enabling technology. The software’s quality directly affects sales. Neemu software confi rms this perception; it has significantly increased sales in all the stores that have adopted its search services. 0740-7459/16/$33.00 © 2016 IEEE

This software is an example of how knowledge produced in Brazilian universities has evolved. Neemu comes from a research group that has made academic contributions to data management, search, and information retrieval over the past decades.1–3

What Distinguishes E-commerce Search The problem of e-commerce search looks similar to that of Web search. However, e-commerce search has requirements that make the solution and fi nal software considerably different.

Faceted Search One such requirement is faceted search. Whereas the input to the system is a textual description of a product, the indexed products usually have structured attributes (which store multiple related values) such as brand, size, or dimensions and can have attributes specific to their category. For instance, notebooks have attributes such as the type of CPU

NOVEMBER/DECEMBER 2016

|

IEEE SOFTWARE

23

IMPACT

Decision support information

Dashboard system

Administrator

Queries Neemu big data indices

Neemu search indices

Query processor

Final user Results

Behavior information

Behavior crawling and cataloging system

Indexer

ion

Navigation and shipping

ormat

ior inf

Behav

E-commerce service

Database information (prices, descriptions, updates, ...) Additional behavior and catalog information

FIGURE 1. The Neemu search suite. The four rectangles indicate the main modules. After adopting the system, Neemu clients have experienced an average sales increase of more than 20 percent.

chip, the amount of RAM, and the number of USB ports. Websites can use this information to provide users with faceted-­search options that let them select groups of products. For instance, a user could choose to see only notebooks with 8 Gbytes or more of RAM. To allow such an option, the search algorithms must compute the whole set of matches in the product database for each user query. This restriction eliminates using the stateof-the-art algorithms normally used for Web search, which compute only the top-ranking results to accelerate query processing. Computing faceted search options presents a challenge. During query processing, the system should compute the available attributes and the total number of items matching each attribute. The number of attributes found is usually so high that the system should use a heuristic to select only those attributes expected to be useful to the user. 24

I E E E S O F T WA R E

|

Ranking Information

The Suite

A second important difference between Web search and e-­commerce search is the set of information available for ranking the answers to provide to users. For e-commerce, the system has access to information such as the users’ navigational behavior on the website, the sales occurring after each query, and the list of products each user bought previously. Such information can be important sources of relevant evidence when the system computes the final ranking, and its correct use might improve sales performance when the search system changes.

The Neemu search suite comprises the behavior crawling and cataloging system, the indexer, the query processor, and the dashboard system (see Figure 1). The first step to integrate the suite into an e-commerce service is to install the behavior crawling and cataloging system. This system continuously gathers and processes data from the user and e-commerce service (an app or a website). This data includes user behavior, products, stocking levels, prices, and any other important attributes the system can use to rank results. The behavior crawling and cataloging system sends this information to the indexer. The indexer then creates an index for the query processor and for the dashboard system. The search system takes the information from its index to process queries, compute each query’s ranking, and provide autocompletion of user input. The dashboard monitors the

Neemu and Its Search Suite Neemu’s team comprises 70 employees. The main development team (48 people) is in Manaus, and a commercial team in São Paulo provides technical support to clients. The Neemu team comprises mostly young alumni of undergraduate and graduate programs.

W W W. C O M P U T E R . O R G / S O F T W A R E

|

@ I E E E S O F T WA R E

IMPACT

query results and user behavior to provide feedback to the e-commerce administrator. Feedback can include statistics about high- and lowperforming queries, general information about search performance, and other information that helps support administrative decisions about the ecommerce operation. The administrator can also provide further feedback to the system—for instance, suggesting an autocompletion that complements the ones the system has automatically inferred. We implemented the software system core in C++, and we used PHP and Python to develop the APIs and other interfaces, which comprise more than 300 KLOC. To complement the software solution, we’ve adopted a large set of tools, including Hadoop, Storm, Kafka, Flume, and HBase. The development process includes practices from Scrum, Kanban, testdriven development, code review, continuous integration, and continuous delivery. The team adopts pair programming, with expert–novice pairing, to mentor the novices. We’re continuously concerned with software quality and generation of value for clients. Any technical debt is prioritized at the next sprint planning.

Technological Advances and Results Neemu’s autocompletion solution exemplifies the software’s technological advances. Brazilian e-commerce services receive many queries with spelling or typing errors. For instance, the word “notebook” has appeared in more than 50 forms. Also, each initial text typed by a user might match many possible queries, and the system needs to choose just a small set to present to the user. So, for example, if the user types “notebuque 4gb,” the system suggests changing the query to “notebook

4gb.” Neemu also lists the products best matching the user’s input. In addition, the search software analyzes user behavior to periodically learn new ranking functions, which not only increases sales but also makes the system more attractive to e-commerce clients. Another important aspect is efficiency. Reducing computational costs saves money and reduces the company’s environmental impact, through reduced energy consumption and reduced infrastructure and maintenance costs for processing millions of queries daily. The choice and development of efficient data structures and algorithms can highly

the combination of this information, resulting in better rankings. Neemu’s clients can access this state-of-the-art technology without needing expensive in-house development teams. Neemu’s software has had a considerable impact on Brazilian ecommerce. It has more than 100 clients and processes more than 10 million queries daily. On the last Black Friday, a promotion day for e-commerce sales, Neemu systems supported more than 360 million queries, resulting in more than US$130 million in sales. Also, after adopting the system, Neemu clients have experienced an average sales increase of more than 20 percent.

Reducing computational costs saves money and reduces the company’s environmental impact.

affect a company’s fi nances. For example, a recent change in the basic algorithms for computing the fi nal ranking reduced the computational costs for processing each query by half at the beginning of 2016. Neemu’s search solution is on a par with top e-commerce search solutions such as those of Amazon and eBay, presenting similar search features (such as faceted search and autocompletion) and high-quality ranking. One differentiator is that Neemu’s ranking algorithms provide a very low response time for searching millions of items, while considering information such as navigation patterns, product images, product sales, trends, and user history. Neemu employs machine learning to improve

These results show that search tools shouldn’t be considered just simple commodities. Improvements in search services significantly affect e-commerce operations, considering that Neemu clients sell more than $7 billion in products annually.

N

eemu plans to continuously invest in developing its search tools, providing high-quality results while always trying to reinvent its data structures and algorithms to reduce computational costs. Neemu also plans to diversify its products and enter the international market. Its products have already reached other Latin American

NOVEMBER/DECEMBER 2016

|

I E E E S O F T WA R E

25

IMPACT

markets, including Argentina, Chile, Colombia, Peru, and Mexico. To face the challenges of continued growth, the company recently merged with Linx, a larger Brazilian company (2,800 employees) that’s a leader in software for physical retailers, and Chaordic, an ecommerce software company that also has emerged from academia. Together, Chaordic and Neemu have approximately 200 employees. The Brazilian software industry in has grown approximately 8 percent annually over the last five years.4 Approximately 600,000 people work in this industry, which represents roughly 1.5 percent of Brazil’s gross domestic product.4 According to Softex (Association for Promoting Brazilian Software Excellence), the Manaus area has now approximately 3,800 people directly working with software, out of a

population of about two million. Although this number is quite low, we see indications of future growth. In the past, finding a software start-up in Manaus would have been hard. Nowadays, creating new software companies has become part of the agenda for university students. Neemu’s success points at how the development of a strong software industry could improve Amazonia’s economy. Such an industry will have a low environmental impact. Also, product distribution won’t require sophisticated logistics, allowing the industry to be competitive even considering its geographical isolation and distance to the main market centers. So, we believe that Neemu, and the other companies that have emerged recently in the region, represent an example of how computer science and the

software industry can contribute indirectly to preserve the Amazon forest, by providing alternatives to bring economic and social development to the local population. References 1. E. Cortez et al., “Lightweight Methods for Large-Scale Product Categorization,” J. Am. Soc. Information Science and Technology, vol. 62, no. 9, 2011, pp. 1839–1848. 2. M.R. Herrera et al., “Exploring Features for the Automatic Identification of User Goals in Web Search,” Information Processing & Management, vol. 46, no. 2, 2010, pp. 131–142. 3. C. Rossi et al., “Fast Documentat-a-Time Query Processing Using Two-Tier Indexes,” Proc. 36th Int’l ACM SIGIR Conf. Research and Development in Information Retrieval (SIGIR 13), 2013, pp. 183–192. 4. “Intelligence,” Activity Report, Softex (Association for Promoting Brazilian Software Excellence), 2015, pp. 84–93 (in Portuguese); www .softex.br/book2015. EDLENO SILVA DE MOURA is a professor of

Call for Papers | General Interest

I

EEE Micro seeks general-interest submissions for publication in upcoming issues. These works should discuss the design, performance, or application of microcomputer and microprocessor systems. Summaries of work in progress and descriptions of recently completed works are most welcome, as are tutorials. IEEE Micro does not accept previously published material.

www.computer.org/micro

26

I E E E S O F T WA R E

|

W W W. C O M P U T E R . O R G / S O F T W A R E

|

database/information retrieval at the Institute of Computing at the Federal University of Amazonas and a cofounder of Neemu. Contact him at [email protected]. MAURO ROJAS HERRERA is the director of Neemu’s Search Technology Department. Contact him at [email protected]. LEONARDO SANTOS is the director of

Neemu’s Big Data Department. Contact him at [email protected]. TAYANA CONTE is a professor of software engineering at the Federal University of Amazonas, where she leads the USES research group (Grupo de Usabilidade e Engenharia de Software; http://uses.icomp.ufam.edu.br). Contact her at [email protected].

@ I E E E S O F T WA R E

Editor: Giuliano Antoniol Poly technique Montréal

INVITED CONTENT Editor: Phillip Laplante Pennsylvania State University

Editor: Steve Counsell Brunel University

Cyclomatic Complexity The cyclomatic complexity (CC) metric measures the number of linearly independent paths through a piece of code. Although Thomas McCabe developed CC for procedural languages, its popularity has endured throughout the object-oriented era. That said, CC is one of the most controversial metrics, shunned for the most part by academia for certain theoretical weaknesses and the belief that it’s no more useful than a simple “lines of code” metric. However, most metrics collection tools support its collection, and, paradoxically, industry uses it extensively (certainly in my experience). So, why is this the case? This question also leads to fundamental perennial questions about industry’s exposure to academic opinion (and research) and whether academic research fails to take account of software development’s daily practicalities. Maybe industry is simply looking for straightforward, widely understood metrics? In this instalment of Invited Content, Christof Ebert and James Cain provide compelling reasons why CC is a valuable metric that’s still used extensively. — Steve Counsell

A Groundbreaking Contribution Christof Ebert

SOFTWARE’S CRITICALITY AND risk are defi ned by its complexity. Forty years ago, Thomas McCabe introduced his famous cyclomatic complexity (CC) metric. Today, it’s still one of the most popular and meaningful measurements for analyzing code. Measuring CC has great benefit for projects to predict software components that likely have a high defect rate or that might be difficult to test and maintain. It’s of even more 0740-7459/16/$33.00 © 2016 IEEE

value having a simple indicator that can provide constructive guidance on how to improve the code’s quality. This is what CC gives us. CC is simple to calculate and intuitive to understand. It can be taught quickly. Too many nested decisions make code more difficult to understand, owing to the many potential flows through it. In addition, a module’s CC value correlates directly with the number of test cases necessary for path coverage, so even a rough indication given by the CC metric is of high value to a developer or project manager. A high CC thus implies high criticality, and the code will have a

NOVEMBER/DECEMBER 2016

|

IEEE SOFTWARE

27

INVITED CONTENT

higher defect density (vis-à-vis code with a relatively lower CC); test effort is higher and maintainability severely reduced. These relationships are intuitive for students as well as experts and managers, which is another appealing feature of CC. It’s no surprise that CC, unlike many other metrics that have been proposed over the past decades, is still going strong and is used in almost all tools for criticality prediction and static code analysis. CC, together with change history, past defects, and a selection of design metrics (for example, the level of uninitialized data, method overriding, and God classes) can be used to build an effective prediction model. On the basis of a ranked list of module criticality used in a build, developers can then apply different mechanisms—refactoring, redesign, thorough static analysis, and unit testing with different coverage schemes. So, CC gives us a starting point for remedial maintenance. Moreover, instead of predicting the number of defects or changes (algorithmic relationships), we consider assignments to classes (for example, “defect prone”). The first goal is more or less achievable with regression models or neural networks mainly in finished projects. In contrast, the latter goal seems adequate for predicting potential outliers in running projects, in which precision is too expensive and not really necessary for decision support. Although CC’s benefits are clear, it does need clear counting rules. For instance, these days we don’t count simple switch or case statements as multiplicities of “if, then, else” decisions. Moreover, the initial proposal to limit CC to 7 ± 2 per entity is no longer a hard rule because defect-prone components’ bound28

I E E E S O F T WA R E

|

aries are fuzzy and multifactorial. Despite these nuances, many solid empirical studies have demonstrated that a high decision-to-decision path coverage or C1 coverage will find more than 50 percent of defects. Static control-flow-analysis tools incorporating CC can also find security vulnerabilities such as dead code, often used as back doors for hijacking software. Four decades of validity and use are a tremendous accomplishment in software, and I congratulate McCabe for such a ground-breaking contribution. (For more on CC’s value for improving code quality and maintainability, see my blog.1) Reference 1. C. Ebert, “Cyclomatic Complexity—40 Years Later,” Software Technologies blog, 2016; www.computer.org/portal​ /web/Software-Technologies. CHRISTOF EBERT is the managing director of Vector Consulting Services. He is on the IEEE Software editorial board and teaches at the University of Stuttgart and the Sorbonne in Paris. Contact him at [email protected].

Simple, Effective, and Fits the Bill James Cain

IN ANSWERING WHY cyclomatic complexity (CC) is so widely employed in industry but widely criticized in academic research, we must first answer the question, what parts of the software industry are even aware of current software research? As a professional programmer, I often receive marketing emails from many sources. They normally com-

W W W. C O M P U T E R . O R G / S O F T W A R E

|

pete for my attention by offering insights into my development experience or offering education on some of the latest hot topics in large-scale software deployment. I subscribe (for free) to InfoQ (www.infoq.com), an organization that hosts many software development conferences and records all session presentations for later Web streaming. The presentations tend to be by professional programmers who work for large commercial organizations on interesting open source projects. They have little marketing content and are highly technical, but they rarely reference academia. So, to put it bluntly, a divide exists between academic interests and those of day-to-day development. What industry might find useful, academia struggles to find useful, and vice versa. This underpins both parties’ views on metrics such as CC. As a developer working in business, I also have little time to add to my education, and there’s a constant balance to maintain between the urgent and the important. A fundamental part of my skill set is keeping it relevant. So, refreshing skills by constant learning is of paramount importance. If half my (technical) knowledge becomes obsolete every five years, I need to double my knowledge every five years, just to stay up to date. Industry thus looks for simple, effective metrics (such as CC) that take very little time to understand, collect, and interpret. Of course, development teams face another pressure—­accountability. Se­ nior (maybe nontechnical and definitely not computer science academic) management have been taught that they need to measure. If you’re not measuring, how do you know whether you’re improving? So, well-meaning programs are

@ I E E E S O F T WA R E

INVITED CONTENT

decreed from on high: Thou shalt measure! But what should we measure, and how do we measure it? The following quote is from the McCabe homepage (www.mccabe.com): McCabe IQ has been used to analyze the security, quality, and testing of mission, life, and business critical software worldwide. How vulnerable is your code? What is the quality of your code? How well tested is the code? If you are responsible for the development, security, reengineering,

or testing of software applications that must not fail, you need answers to these questions. If you can’t answer them with certainty, you need McCabe IQ.

This is a compelling message. But it’s not aimed at software developers. It’s aimed at the people responsible for development. McCabe’s offering solves a different problem than a simple “lines of code” metric would. It lets managers tell senior directors that there’s a metrics program in place with plenty of industrial evidence about its efficacy. And, given the industrial–academic divide, no one in the company has

the knowledge to argue with the management’s decision. This suggests that industry looks for metrics that can be communicated between the different management levels and across the levels of the development stakeholders. CC fits this bill. JAMES CAIN is the Principal Architect— Software at Snell Advanced Media and a Visiting Researcher at Brunel University. Contact him at [email protected].

Selected CS articles and columns are also available for free at http://ComputingNow.computer.org.

IEEE-CS Charles Babbage Award CALL FOR AWARD NOMINATIONS Deadline 15 October 2016

ABOUT THE IEEE-CS CHARLES BABBAGE AWARD

Established in memory of Charles Babbage in recognition of significant contributions in the field of parallel computation. The candidate would have made an outstanding, innovative contribution or contributions to parallel computation. It is hoped, but not required, that the winner will have also contributed to the parallel computation community through teaching, mentoring, or community service.

CRITERIA

This award covers all aspects of parallel computing including computational aspects, novel applications, parallel algorithms, theory of parallel computation, parallel computing technologies, among others.

AWARD & PRESENTATION

A certificate and a $1,000 honorarium presented to a single recipient. The winner will be invited to present a paper and/or presentation at the annual IEEE-CS International Parallel and Distributed Processing Symposium (IPDPS 2017).

NOMINATION SUBMISSION

Open to all. Nominations are being accepted electronically at www. computer.org/web/awards/charles-babbage. Three endorsements are required. The award shall be presented to a single recipient.

NOMINATION SITE awards.computer.org

AWARDS HOMEPAGE www.computer.org/awards

CONTACT US

[email protected]

NOVEMBER/DECEMBER 2016

|

I E E E S O F T WA R E

29

FOCUS: GUEST EDITORS’ INTRODUCTION

The Software Architect’s Role in the Digital Age Gregor Hohpe, Allianz SE Ipek Ozkaya, Carnegie Mellon Software Engineering Institute

Reversing Irreversible Decision Making

Uwe Zdun, University of Vienna Olaf Zimmermann, University of Applied Sciences of Eastern Switzerland, Rapperswil

TRADITIONALLY, SOFTWARE architects were entrusted with making 30

IEEE SOFTWARE

|

be made early in the project, architects drew on their experience and ability to abstract to get them right. Repeated project cost and timeline overruns have demonstrated, though, that trying to plan all features and decide the system structure early in a project is difficult at best. This insight, coupled with the increasing demand for delivering high-quality software more quickly, has changed how development teams approach architectural decision making.

“decisions that are costly to change.”1 Because these decisions often had to

PUBLISHED BY THE IEEE COMPUTER SOCIETY

Software teams are increasingly embracing tools and practices that help them avoid, decouple, or break down big, up-front decisions. For example, agile practices have reduced the need to make irreversible decisions at a 0740-7459/16/$33.00 © 2016 IEEE

project’s very beginning, by starting development based on a simple architecture that focuses on delivering customer value quickly.2 As teams learn more about customer needs and the system’s behavior, they focus development on smaller local decisions, restructuring the system through refactoring to retain development velocity. Lean methods have taken this approach one step further by collecting user feedback not only during development but also from a productive system in a continuous build–measure–learn cycle.3 At the same time, rapid technology evolution has made it more difficult for architects to make decisions based solely on experience. Evidence from the field suggests that most successful architectures and their decisions are created through a collaborative team effort, rather than relying only on architects.4 Architectural decision making has become a collective, continuous discovery-andlearning process, as opposed to being one person’s responsibility.

The Code Is the Architecture With fewer big decisions to be made, are fewer architects needed? Looking at job roles in digital companies such as Google or Spotify, we indeed find hardly any jobs titled architect. Still, these companies boast some of the planet’s most innovative software application and infrastructure architectures. So, they’re doing architecture, but apparently without architects. Many architects are tasked with depicting a system’s structure and behavior and conveying them to a broad audience to assure conceptual integrity.5 However, instead of architectural decisions being documented in stacks of binders, Internet-scale companies’ architectures live in the code.

Discovering, discussing, and evolving the architecture are aided by structuring the code in a single, searchable repository and documenting decisions in version control systems or code review tools. Where pictures are helpful, they can be generated from code in real time using visualization techniques. Wherever a textual explanation is needed that can’t be expressed in source code comments, a community wiki explains architectural decisions (for example, see the Chromium Design Documents page, www.chromium.org/developers /design-documents). Even companies with safety- and mission-critical products, which rely heavily on architecture documentation and locked-in decisions, are increasingly moving to architecting approaches that can be integrated in tools and assisted by simple decision-making processes.6

Architecture as a Service Most Internet-scale companies’ products and services are available in the cloud as Web APIs in a platform-­asa-service (PaaS) or software-as-aservice (SaaS) model. Such offerings are ready to be used without much consumer-side architectural considerations or the need to build up a complex application runtime environment. For example, PaaS middleware frameworks let architects and developers focus on the application domain while the platform manages most aspects of software deployment, scaling, and resilience. Serverless architectures, such as the one implemented by Amazon Lambda, provide a complete execution environment for application functionality. Such environments are sometimes called functions as a service (FaaS).7 Thus, today’s software frameworks and middleware platforms further reduce the need for architectural

decision making by encapsulating many architectural decisions.

Architecture without Architects? So, you could argue that ample resources assist teams in making and documenting architectural decisions, and recovering more quickly from bad ones, relieving architects of some of their traditional tasks. As collaborative development environments’ capabilities increase, software tools appear to have further reduced the need for architects. Martin Fowler and Erik Dörnenburg underlined this perception with their recent observation that “most of what architects have done traditionally should be done by developers, or by tools, or not at all.”8 However, architects won’t become redundant anytime soon— many new, even more challenging aspects of software development await architects in the digital age.

The Impact of Internet Architectures Internet-scale systems have made software systems’ architecture more important than ever. Ten years ago, developers were excited to build a distributed system; today there’s hardly a system that isn’t distributed or interconnected. Modern systems are expected to be horizontally scalable to thousands of machines, automatically deployable just about anywhere, observable, upgradable with zero downtime, resilient against failure, self-adapting, and antifragile. Chaos monkeys organized into simian armies put these systems to the test by randomly disabling components in production.9 Systems without well-thought-out architecture surely won’t withstand such torture. Simple architectures that deploy a single application onto a large server

NOVEMBER/DECEMBER 2016

|

I E E E S O F T WA R E

31

FOCUS: GUEST EDITORS’ INTRODUCTION

no longer meet today’s demand for rapid deployment and instant scalability. “Vertical scaling” and “monolith” have even become dirty words replaced by microservices architectures, which feature a much more dynamic, but also more complex, runtime behavior. So, modern software architecture not only concerns itself with structuring system functionality into objects and components but also emphasizes design for automated deployment, dynamic scaling, automated failover, predictive monitoring, and many other advanced runtime considerations. Further adding to the complexity, Internet architectures blur system context boundaries, replacing single software applications with interconnected ecosystems of services in an API economy. No longer having control over all system components makes it difficult for teams to freeze designs, rendering design flexibility a top architectural quality. Finally, deploying software into a connected world and onto a variety of devices elevates architectural concerns previously confined to specialized domains. For example, any system that’s exposed to the Internet or an internal network becomes a target for cyberattacks, requiring today’s architects to be well versed in security architecture. Likewise, applications running on mobile devices must minimize power consumption, a concern once limited to battery-operated embedded systems. Finally, the virtualization of network, computing, and storage components into softwaredefined infrastructure has provided development teams new flexibilities for runtime configuration and automation but also has expanded the average software architect’s purview to include hardware infrastructure. “You build it, you run it” approaches 32

I E E E S O F T WA R E

|

such as DevOps10 have augmented an architect’s job to not only design systems but also monitor and continuously update them.

The Architect Elevator Whereas the rapidly evolving technology landscape challenges developers, new digital business models challenge company leadership. Hardware companies must reinvent themselves as software companies, and product companies must turn into service providers. Product innovation cycles accelerate as customer expectations for speed and scale rise. New architectures and approaches, such as the cloud and Dev­ Ops, which help traditional companies compete with digital disruptors, necessitate changes to organizational structures and working cultures. Architecture has therefore evolved from a mostly technical discipline to include even more business, social, and cultural aspects. As technical capability becomes a critical success factor for almost any business, company strategy and technology strategy must be aligned much more closely. So, someone needs to “ride the elevator from the penthouse to the engine room of the organization” to forge this connection.11 Architects must also transport and combine knowledge from what used to be isolated domains, such as embedded systems, analytics, or datacenter infrastructure design, into mainstream software development teams, playing a horizontal connector role. Architects are best equipped to play this role because they typically combine a technical foundation with business acumen and communication skills. Times of rapid change require architects who can act as mentors and bridge builders among project

W W W. C O M P U T E R . O R G / S O F T W A R E

|

teams, across domains, and between different layers of the organization. Although the digital age has diminished some aspects of a traditional architect’s role, such as up-front decision making and system documentation, it has placed a new critical importance on the architect’s role as a linking element.

From the Golden Age to the Platinum Age? In 2006, Mary Shaw and Paul Clements envisioned that software architecture would soon attain the status of all truly successful technologies: people would take it for granted.12 The increasing availability of techniques, processes, and tools assisting with representing architectures, decision making, and other architecting tasks has enabled significant progress toward this vision.13 On the other hand, rapid technology evolution and new business models have shifted the target further away. Having been involved with the evolution of software architecture for about two decades in varying roles, we’ve witnessed a consolidation and, in some areas, simplification of the architect’s toolbox in recent years, but also the desire to add items to it. These trends can be illustrated along three dimensions: notation, process and practices (including decision making), and knowledge. (For a general retrospective, see the sidebar “The Evolution of Software Architecture.”)

Notation The IEEE 1471 standard for architecture descriptions has evolved into ISO/IEC/IEEE 42010:2011, now covering additional aspects such as viewpoints, frameworks, and decision rationale.14 However, the notation landscape has become more

@ I E E E S O F T WA R E

fragmented. It includes not only informal rich pictures and UML profiles but also novel architecture description languages such as ArchiMate (www.archimatetool.com) and AADL (Architecture Analysis & Design Language; www.aadl.info/aadl /currentsite), motivating practitioners to mix notations in a best-of-breed strategy. Nevertheless, tool support for reasoning about runtime behavior still is weak. See Grady Booch’s article “Draw Me a Picture” for a general tooling vision and user wants and needs.15 Recently, researchers and practitioners have articulated a desire for pragmatic modeling, and the first building blocks have been proposed— for example, by Simon Brown and George Fairbanks (see www.wicsa .deib.polimi.it/invited.html).

community’s current focus includes group decision making and its cognitive, behavioral, and social aspects. A movement toward lightweight, flexible, and aligned approaches became apparent.21 This trend continues: for example, the theme of the 2017 IEEE International Conference on Software Architecture (http://icsa -conferences.org/2017) is “Continuous architecting—exploring the role, importance, and characteristics of architecture in continuous software engineering development processes.”

Knowledge

Capturing architectural knowledge in a single, definite software architecture handbook, which codifies knowledge to make it widely available, has remained an unrealized ideal.13 In its absence, architectural tactics and patterns have been published for Process and Practices Architecture design processes are many application genres and technow aligned better with each other nical domains, such as mobile and and with other practices such as cloud computing. Architectural styles technical-debt management, con- such as SOA (service-oriented architinuous delivery, and refactoring. tecture) and REST (representational Quality attributes continue to play state transfer), as well as supporting a central role in architectural anal- implementation approaches such as the ysis, with context as an important microservices variant of service-based complement.16 For instance, the development and deployment, have beSoftware Engineering Institute’s come popular. Despite this progress and the Attribute-­ Driven Design method has been recently updated to include field’s increased maturity, many arplatform-specific design.17 Practitio- chitecting challenges lie ahead owing ners have also proposed lightweight to the need for speed in the digital methods for architectural evalua- age. This need is being driven by new business models, virtual products tions (reviews).18 Architectural decisions have and services, more staffing options, evolved into a major research and increased automation and intetopic. The architecture-knowledge-­ gration; it calls for additional skills. For instance, increasing system management community has proposed a decision-centric view of complexity will require architects to software architecture. For instance, be engaged in not just development it has come up with metamodels, but also operations and maintemethods, and tools for decision nance. This will challenge architects capturing and sharing that are in- even more to manage systems’ struccreasingly used in practice.19,20 The ture, behavior, rationale, technical

debt, and quality concerns. To successfully ride the architect elevator, architects will need to strengthen their business, financial, communication, and educator skills. In recent years, we’ve also seen an inversion of specialization and division of labor—a trend that contrasts with many other fields’ evolution. For instance, responsibility for a particular microservice or feature requires a full-stack developer, who combines database, integration, domain logic, and user interface design skills. Architectural analysis, synthesis, and evaluation are no longer performed by individual architects but have become shared team responsibilities; architect is a virtual role on many teams now. Underlying technologies’ increasing complexity challenges this trend, so time will tell whether the pendulum will swing back toward specialization. General problem-solving and complexity management strategies such as decomposition, abstraction– refinement cycles, and asset reuse continue to be essential architect competencies. They also remain the most difficult ones to teach owing to their “experience factor.” (For a discussion of software architect training, see the related sidebar. For a discussion of other information resources, see the “Trendspotting (Staying Current)” sidebar.)

In This Theme Issue The five articles in this theme issue include two surveys and three case studies from diverse domains such as vehicle software, telecommunications, and embedded systems. These articles are by practitioners, joint teams of practitioners and academics, and academics studying the practice’s state of the art. Their articles provide evidence for our claims and illustrate our observations.

NOVEMBER/DECEMBER 2016

|

I E E E S O F T WA R E

33

FOCUS: GUEST EDITORS’ INTRODUCTION

THE EVOLUTION OF SOFTWARE ARCHITECTURE

TABLE A

IEEE Software devoted theme issues to the state of the art of software architecture in November 1995 and March/April 2006.1 In Mary Shaw’s keynote at the 2015 Software Engineering Institute Architecture Technology User Network Conf. (SATURN), she emphasized that progress has been made through the process of basic research, concept formation, development and extension, internal

exploration, external exploration, and popularization. 2 However, she also observed that software engineering still doesn’t have all the characteristics of an engineering discipline. For example, it lacks reference material carrying codified knowledge. To put the software architecture field’s evolution into context, Table A lists major additions to the architect’s knowledge set and toolbox, starting

Architectural dimensions and the evolution of the software architecture field. The state of the art Aspect

At the field’s inception (1990s)3

After a decade (mid 2000s)1

Today

Context and requirements

Not an explicit part of the early definition3

Quality attributes (QAs) and constraints

QAs plus explicit representation of context;4 more emphasis on business speed and value, cost and risk, architectural principles, and technical-debt management for strategic architecting

Structure

Elements • Processing • Data • Connectors

4+1 views, components and connectors in UML and architecture description languages, informal box-and-line diagrams created by following processes and guidance in architecture design methods, and general architectural patterns; and first domain-specific architectural tactics and patterns (for example, for enterprise application architectures)5

More notations, such as domainspecific languages (for example, context maps in domain-driven design); more emphasis on data (for example, information viewpoints) and on architecting runtime relationships (for example, in cloud deployments); design by composition through frameworks; and many more domain-specific architectural tactics and patterns

Form • Properties (of elements) • Relationships (between elements)

34

from an early definition.3 (Many other definitions of software architecture exist; for a collection, see www.sei.cmu .edu/architecture/start/glossary/​ community.cfm.) In summary, software architecture today spans five aspects: context, elements, form, rationale, and realization. The architect in the digital age must be well versed in all of them. (See the sidebar “Software Architect Training.”)

Design decisions (reasoning behind chosen structures)

Rationale

Architectural decisions recognized as a key architectural concept in many articles and books, but no detailed coverage in most methods and tools6

Architecture knowledge management and decision making as a major research field and early adoption in practice (for example, inclusion in ISO/ IEC/IEEE 42010:2011)

Realization

Not an explicit part of the early definition

Architecture design often embedded into end-to-end software engineering methods, International Federation for Information Processing (IFIP) subarea “realization,” and modeldriven software engineering and code generation attempts

Agile practices, continuous delivery, and DevOps; increased emphasis on the time dimension; better enactment and enforcement of architectural decisions (for example, architecturally evident coding styles); and continuous feedback cycles7

I E E E S O F T WA R E

|

W W W. C O M P U T E R . O R G / S O F T W A R E

|

@ I E E E S O F T WA R E

References 1. P. Kruchten, H. Obbink, and J. Stafford, “The Past, Present, and Future for Software Architecture,” IEEE Software, vol. 23, no. 2, 2006, pp. 22–30. 2. M. Shaw, “Progress toward an Engineering Discipline of Software,” keynote at the 2015 Software Eng. Inst. Architecture Technology User Network Conf. (SATURN 15), 2015; http://resources​ .sei.cmu.edu/asset_files/Presentation​ /2015_017_101_438724.PDF. 3. D.E. Perry and A.L. Wolf, “Foundations for the Study of Software Architecture,” ACM SIGSOFT Software Eng. Notes, vol. 17, no. 4, 1992, pp. 40–52. 4. P. Kruchten, “Contextualizing Agile Software Development,” J. Software Evolution and Process, vol. 25, no. 4, 2013, pp. 351–361. 5. C. Hofmeister et al., “A General Model of Software Architecture Design Derived from Five Industrial Approaches,” J. Systems and Software, vol. 80, no. 1, 2007, pp. 106–126. 6. M. Fowler, Patterns of Enterprise Application Architecture, Addison-Wesley Professional, 2002. 7. M. Erder and P. Pureur, “What’s the Architect’s Role in an Agile, CloudCentric World?,” IEEE Software, vol. 33, no. 5, 2016, pp. 30–33.



In “How Software Architects Drive Connected Vehicles,” Sören Frey, Lambros Charissis, and Jens Nahm observe that the software architect’s role as a single expert is often challenged in the literature and in practice. This is especially true in the context of agile methods, which were used by 80 percent of the professionals in Rainer Weinreich and Iris Groher’s study, which we discuss later. Frey and his colleagues’ observations from projects in the connected-­vehicle domain show the importance of bundling responsibilities in the software architect role, particularly to efficiently manage complexity and spread knowledge. In “Software Architects in LargeScale Distributed Projects: An Erics­ son Case Study,” Ricardo Britto, Darja Šmite, and Lars-Ola Damm report on their experience in a traditional setup. To deal with the challenges of scale, team distribution, and monolithic legacy applications, Ericsson defers decisions to a centralized team of architects. The authors observe that the less mature a distributed team is, the more effort architects spend guarding the system’s integrity and evolvability. Here, the architect’s connecting or coordinating role is interpreted as a centralized role that coaches the various teams. In “Embedded-Software Architects: It’s Not Only about the Software,” Pablo Antonino, Andreas Morgenstern, and Thomas Kuhn observe that many embedded-­system architects have an engineering background but limited experience in software design, leading to serious deficiencies in architectural designs. In turn, experienced software architects often have little knowledge about embedded-system architectures. This article reflects well our

observations that architects must keep pace with broader and more complex software architecture concerns, including aspects formerly limited to specialized domains. In “The Architect’s Role in Practice: From Decision Maker to Knowledge Manager?,” Weinreich and Groher discuss results from a survey of 25 software architects, software team leads, and senior developers from 10 countries. They provide insights into how, when, and by whom architectural decisions are made. They also investigate the factors influencing decision making and the roles and responsibilities for different types of decisions. They observe that the architect’s role is changing from being primarily a decision maker to being a coordinator, advisor, and knowledge manager. They view the architect as a central knowledge hub in the future. Much in line with that thread, Damian Tamburri, Rick Kazman, and Hamed Fahimi examine “The Architect’s Role in Community Shepherding.” They observe that architects involved in technical or organizational changes, such as a move to DevOps or agile methods or a corporate merger, need to guide and harmonize a community of project stakeholders. The authors summarize issues that can surface as “community smells” and negatively influence system development. They position the architect’s role as detecting and resolving these smells. Several of these articles reflect the connecting or coordinating role for the architect that we’ve observed. All the articles discuss the architect’s shifting role and responsibilities, citing reasons of increasing development speed, higher flexibility in requirements, organizational change, or the

NOVEMBER/DECEMBER 2016

|

I E E E S O F T WA R E

35

FOCUS: GUEST EDITORS’ INTRODUCTION

SOFTWARE ARCHITECT TRAINING Software architect typically isn’t an entry-level position or responsibility. So, software architecture curricula can be found both in academia and as part of continuing education delivered through classroom and distance-learning programs. Such education might also come as on-the-job training based on mentor–protégé (or master–apprentice) relationships.

BOOKS Many introductory and more advanced software architecture books exist that can help structure a curriculum to teach (parts of) the architect’s skill sets. A number of book recommendations are online. For instance, George Fairbanks reviewed a comprehensive set of essential books in a June 2015 blog post and video (http://georgefairbanks.com/blog​ /software-architecture/book-recommendations).

ACADEMIC CURRICULA In Computer Science Curricula 2013, the use of components in design and basic software architecture concepts and standard architectures (for example, client-server, n-layer, transformation centered, and pipes and filters) are Core Tier-2 topics.1 (Core Tier-1 topics should be in all computer science programs; individual programs choose which Core Tier-2 topics to cover.) Furthermore, architecture patterns

introduction of agile methods. Another common theme is that architecting modern systems requires broader and deeper knowledge of various types, including software areas other than design and architecture, hardware, and domain-related knowledge. In addition, several articles feature sidebars envisioning how the software architect’s role might evolve. Two of the departments in this issue also tie in with our theme. In the Insights department, consulting IT architect Eltjo Poort makes the case for an explicit representation of architectural evolution along the time axis. He also reports on his IT architect community’s experiences 36

I E E E S O F T WA R E

|

and specialized architectures such as parallel architectures are considered elective topics. Computer Science Curricula 2013 covers only undergraduate education; graduate programs can and should cover architecture topics more deeply. Furthermore, graduate courses on other topics should pay specific attention to architectural concerns. For instance, requirements classes should cover architecturally significant requirements, and courses on software evolution and maintenance should cover topics such as DevOps, monitoring and improving systems at runtime, and architectural refactoring. For instance, the University of Vienna has developed a curriculum that follows many suggestions from Computer Science Curricula 2013. The required undergraduate course Software Engineering 2 features an introduction to software architecture, including topics such as architecture disciplines and basic component-and-connector modeling. The required master’s course Advanced Software Engineering includes architecture topics such as domain-driven design, advanced component-and-connector modeling, architectural views, architectural styles and patterns, design decisions, modeldriven development, domain-specific languages, architecture analysis, architecture in the organization, and architecture in the development process. Additionally, the elective course Distributed Systems Engineering covers distributed-system

with architecture roadmapping. His approach supports the modern architect’s connector role, assisting both project and product managers with strategic planning and risk management. Finally, in the Pragmatic Architect department, Eoin Woods pre­ sents his view on the evolution of software architecture’s past, present, and future, which complements the analysis in this article. He identifies five ages of software systems and five corresponding stages of software architectures. He also calls out six future trends for architecting practices, including more focus on data and algorithm design, emergent

W W W. C O M P U T E R . O R G / S O F T W A R E

|

runtime structure, and operational policy and automation.

S

oftware architecture has become broader and more complex, presenting students and practitioners with the challenge to stay up to date and hands-on, with not only an ever-faster stream of new technologies and open source projects but also new concepts and concerns. Whereas being conversant in object-oriented design was once largely sufficient to design systems, it’s now but one of many aspects. Thought leadership, mentoring, and conveying complex concepts in

@ I E E E S O F T WA R E

patterns, including architectural patterns. Other elective courses cover specific kinds of architectures, such as cloud, parallel, process-driven, cooperative-systems, or game architectures. All these courses dedicate 40 to 50 percent of their time to delivering conceptual knowledge, supplemented with practical hands-on exercises, including programming, designing, studying architectures, and reviewing case studies. The University of Applied Sciences of Eastern Switzerland, Rapperswil balances theory and practice in a similar way. For instance, the advanced undergraduate course Application Architecture offers 14 lessons accompanied by exercises and self-study assignments on quality attributes, architectural principles and patterns (such as loose coupling and layers), context and component modeling, architectural decisions, dependency injection containers, enterprise integration patterns, service orientation, and domain-driven design. Case studies and examples illustrate the abstract concepts and refine them for domains and application genres such as information systems (also known as enterprise applications), distributed control systems, and cloud services. Other courses that cover architectural topics include Distributed Software Systems, Advanced Patterns and Frameworks, and Cloud Solutions.

ricula. Examples include the Software Engineering Institute’s Professional Software Architecture Certificate (www.sei.cmu​ .edu/training/certificates/architecture/professional.cfm), IASA Software Architect Certification (http://iasaglobal.org/certifications), and the Open Group Certified Architect (Open CA) Program (www.opengroup.org/openca/cert). A variety of corporate programs also provide architect training and certification—for example, at ABB, GE, IBM, Raytheon, and Siemens.2 In addition, online courses are available through massive open online course platforms, such as Doug Schmid’s Pattern-Oriented Software Architectures courses (www.dre​ .vanderbilt.edu/~schmidt/Coursera). Continuing-education programs face the same challenges as academic programs, having to balance current, easily applicable content and timeless, universal problem-solving competencies. Just as in software architecture design, trade­offs are inevitable. References 1. Computer Science Curricula 2013: Curriculum Guidelines for Undergraduate Degree Programs in Computer Science, ACM and IEEE, 2013; www.acm.org/education/CS2013-final-report.pdf. 2. F. Buschmann, “What an Architect Needs to Know: Experiences from the Siemens Curriculum for Software Engineers,” 2016;

INDUSTRY TRAINING

http://gotocon.com/dl/jaoo-aarhus-2010/slides/FrankBuschmann_

A number of education and certification programs targetting professionals feature topics similar to those in academic cur-

WhatArchitectsNeedToKnowExperiencesFromTheSiemens

approachable terms has therefore become more important than ever. Architects are uniquely qualified to play this role. Being relieved of some traditional tasks, such as centralized decision making and documenting architectures, is a welcome break for architects who navigate not only a more complex technical environment but also visit the corporate penthouse more frequently to align business and technical strategy. Isn’t it a great time to be an architect? Acknowledgments Ipek Ozkaya’s contribution to this article is based on work funded and supported by

CurriculumForSoftwareEngineers.pdf.

the US Department of Defense under contract FA8721-05-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. This material has been approved for public release and unlimited distribution.

References 1. G. Booch, “Architecting the Unknown,” keynote at the 2016 Software Eng. Inst. Architecture Technology User Network Conf. (SATURN 16), 2016; www.youtube.com/watch ?v=RJ3v5cSNcB8. 2. P. Abrahamsson, M.A. Babar, and P. Kruchten, “Agility and Architecture: Can They Coexist?,” IEEE Software,

vol. 27, no. 2, 2010, pp. 16–22. 3. E. Ries, The Lean Start-Up, Crown Business, 2011. 4. M.P. Robillard and N. Medvidovic´, “Disseminating Architectural Knowledge on Open-Source Projects,” Proc. 38th ACM/IEEE Int’l Conf. Software Eng. (ICSE 16), 2016, pp. 476–487. 5. J. Klein, “What Makes an Architect Successful?,” IEEE Software, vol. 3, no. 1, pp. 20–22. 6. R.L. Nord et al., “Missed Architectural Dependencies: The Elephant in the Room,” Proc. 13th Working IEEE/IFIP Conf. Software Architecture (WICSA 16), 2016, pp. 41–50. 7. M. Roberts, “Serverless Architectures,” 4 Aug. 2016; http://martin

NOVEMBER/DECEMBER 2016

|

I E E E S O F T WA R E

37

FOCUS: GUEST EDITORS’ INTRODUCTION

TRENDSPOTTING (STAYING CURRENT) The following sources can help keep you up to date on software architecture and related subjects.

ONLINE RESOURCES Many online resources and communities can help developers and architects educate themselves about basic concepts and emerging trends. Popular community websites include these:

tracks. Similarly, the hybrid industry–­academia PLoP ­(Pattern Languages of Programming) worldwide conferences and their regional counterparts (for example, EuroPLoP) also cover software architecture, although they have a broader scope. Major academic conferences are ICSA (International Conference on Software Architecture) and ECSA (European Conference on Software Architecture).

PERIODICALS • arc42, http://arc42.org. This site offers templates and checklists for architectural descriptions. • DZone, https://dzone.com. This site offers refcards for many concepts and technologies. • InfoQ, www.infoq.com. This site offers e-magazines compiling articles on popular topics. In particular, see www.infoq.com/architecture. • Microsoft’s Patterns & Practices, https://msdn .microsoft​.com/en-us/library/ff921345.aspx. • The SATURN (Software Engineering Institute Architecture Technology User Network) Blog, http://insights.sei .cmu.edu/saturn.

Architecture articles appear regularly in major journals, such as the Journal of Systems and Software, IEEE Transactions on Software Engineering, or Information and Software Technology. Also, magazines such as IEEE Software often publish architecture-related articles and theme issues.

STANDARDS BODIES Relevant de jure or de facto standards bodies include • the ISO (International Organization for Standardization) and IEC (International Electrotechnical Commission), which, for example, jointly provide SQuaRE (Systems and Software Quality Requirements and Evaluation) and Committee Draft (CD) 42020. Systems and Software Engineering—Architecture Processes; • the Open Group, which, for example, provides TOGAF (The Open Group Architecture Framework) and ArchiMate; and • the OMG (Object Management Group), which provides UML, SPEM (Software & Systems Process Engineering Metamodel), and RAS (Reusable Asset).

A number of personal websites and blogs also cover software architecture topics regularly—for example, ­M artin Fowler’s, http://martinfowler.com/design.html, and Phil­ippe Kruchten’s, https://philippe.kruchten.com /category/architecture. In addition, many episodes of Software Engineering Radio investigate architectural concerns, either explicitly (see www.se-radio.net/tag/architecture) or under related topics such as the cloud, distributed systems, and DevOps.

CONFERENCES Practitioner conferences come in many forms. For instance, the SATURN conference is in its 13th year (www.sei.cmu.edu /saturn/2017), and O’Reilly launched a software architecture conference series in 2015 (http://conferences.oreilly.com /software-architecture). Developer conferences such as QCon typically include software architecture topics in dedicated

fowler.com/articles/serverless.html. 8. M. Fowler and E. Dörnenburg, “Architecture without Architects,” presentation at 2016 Craft Conf., 2016; 38

I E E E S O F T WA R E

|

Such standards and specifications typically define terms, metamodels, and notations and sometimes methods, techniques, and tool interfaces for architectural content creation and processing. Occasionally, supporting material such as primers and templates are available—for example, a template exists for the ISO/IEC/IEEE 42010:2011 standard for architecture descriptions (see www.iso-architecture.org/ieee -1471/templates/42010-vp-template.pdf).

www.ustream.tv/recorded/86152575. 9. Y. Izrailevsky and A. Tseitlin, “The Netflix Simian Army,” blog, 19 July 2011; http://techblog.netflix.com

W W W. C O M P U T E R . O R G / S O F T W A R E

|

/2011/07/netflix-simian-army.html. 10. L. Bass, I. Weber, and L. Zhu, DevOps: A Software Architect’s Perspective, Addison-Wesley, 2015.

@ I E E E S O F T WA R E

ABOUT THE AUTHORS

11. G. Hohpe, 37 Things One Architect Knows about IT Transformation: A Chief Architect’s Journey, 2016; https://leanpub.com/37things. 12. M. Shaw and P.C. Clements, “The Golden Age of Software Architecture,” IEEE Software, vol. 23, no. 2, 2006, pp. 31–39. 13. M. Shaw, “Progress toward an Engineering Discipline of Software,” keynote at the 2015 Software Eng. Inst. Architecture Technology User Network Conf. (SATURN 15), 2015; http://resources.sei.cmu.edu/asset _fi les/Presentation/2015_017_101 _438724.PDF. 14. 42010-2011—ISO/IEC/IEEE Systems and Software Engineering— Architecture Description, Int’l Org. for Standardization, Int’l Electrotechnical Commission, and IEEE, 1 Dec. 2011; http://ieeexplore.ieee.org /document/6129467. 15. G. Booch, “Draw Me a Picture,” IEEE Software, vol. 28, no. 1, 2011, pp. 6–7. 16. F. Torres, “Context Is King: What’s Your Software’s Operating Range?,” IEEE Software, vol. 32, no. 5, 2015, pp. 9–12; http://doi.ieeecomputer society.org/10.1109/MS.2015.121. 17. H. Cervantes and R. Kazman, Designing Software Architectures: A Practical Approach, Pearson, 2016. 18. E. Woods, “Industrial Architectural Assessment Using TARA,” Proc. 9th Working IEEE/IFIP Conf. Software Architecture (WICSA 11), 2011, pp. 56–65. 19. M.A. Babar et al., eds., Software Architecture Knowledge Management: Theory and Practice, Springer, 2009. 20. Z. Li, P. Liang, and P. Avgeriou, “Application of Knowledge-Based Approaches in Software Architecture: A Systematic Mapping Study,” Information and Software Technology, vol. 55, no. 5, 2013, pp. 777–794. 21. M. Keeling, “Lightweight and Flexible: Emerging Trends in Software

GREGOR HOHPE is the chief IT architect at Allianz SE. His interests include large-scale IT transformation and the role of architects and architecture in large enterprises. Gregor received a master’s in computer science and a master’s in engineering management, both from Stanford University. He’s the author of 37 Things One Architect Knows about IT Transformation: A Chief Architect’s Journey and is on the IEEE Software advisory board. Contact him at [email protected] or follow him on Twitter @ghohpe.

IPEK OZKAYA is a principal research scientist at the Carnegie Mellon Software Engineering Institute. Her interests include development and application of techniques for improving software architecture practices and practices to manage technical debt in large-scale, software-intensive systems. Ozkaya received a PhD in computational design from Carnegie Mellon University. She’s on the IEEE Software advisory board. Contact her at [email protected] or follow her on Twitter @ipekozkaya.

UWE ZDUN is a full professor of software architecture at the University of Vienna. His research interests include software patterns, software architecture, language engineering, service-oriented architecture, distributed systems, and object orientation. Zdun received a doctorate in computer science from the University of Essen. He’s on the IEEE Software editorial board. Contact him at [email protected].

OLAF ZIMMERMANN is a professor of software architecture and an institute partner at the Institute for Software at the University of Applied Sciences of Eastern Switzerland, Rapperswil. His research interests include service-oriented computing and architectural knowledge management. Zimmermann received a doctorate in computer science from the University of Stuttgart. The Open Group has awarded him a Distinguished IT Architect (Chief/Lead) Certification. And he’s on the IEEE Software editorial board. Contact him at [email protected].

Architecture from the SATURN Conferences,” IEEE Software, vol. 32, no. 3, pp. 7–11.

Selected CS articles and columns are also available for free at http://ComputingNow.computer.org.

NOVEMBER/DECEMBER 2016

|

I E E E S O F T WA R E

39

Focus on Your Job Search IEEE Computer Society Jobs helps you easily find a new job in IT, software development, computer engineering, research, programming, architecture, cloud computing, consulting, databases, and many other computer-related areas. New feature: Find jobs recommending or requiring the IEEE CS CSDA or CSDP certifications! Visit www.computer.org/jobs to search technical job openings, plus internships, from employers worldwide.

http://www.computer.org/jobs

The IEEE Computer Society is a partner in the AIP Career Network, a collection of online job sites for scientists, engineers, and computing professionals. Other partners include Physics Today, the American Association of Physicists in Medicine (AAPM), American Association of Physics Teachers (AAPT), American Physical Society (APS), AVS Science and Technology, and the Society of Physics Students (SPS) and Sigma Pi Sigma.

FOCUS: THE ROLE OF THE SOFTWARE ARCHITECT

How Software Architects Drive Connected Vehicles Sören Frey, Lambros Charissis, and Jens Nahm, Daimler TSS

// There are two reasons why successful connected-vehicle projects often assign architecture-related responsibilities to individual experts acting as software architects. First, the experts help effectively manage complexity; second, they act as knowledge multipliers when development must scale up. //

CONNECTING VEHICLES to the Internet of Things is a fascinating field of activity for software architects. Introducing connectivity into vehicles pushes the door wide open for a broad spectrum of potential use cases.1,2 For example, consider receiving immediate warnings from other vehicles about traffic jams and black ice on the road ahead. Or, you might want to remotely unlock your car doors with a smartphone to allow temporary access for 0740-7459/16/$33.00 © 2016 IEEE

family members. Figure 1 depicts the high-level process flow for controlling the door lock state via mobile devices. A mobile application lets the user issue control commands over a mobile Internet connection to a cloud-based connected-vehicle backend system. For example, the backend system might receive an “unlock doors” command and forward it to the connected car. After the car has received and executed the command, it reports the new door lock state

back to the mobile device via the same communication path. However, designing a viable solution isn’t as straightforward as this process flow might suggest. The design must take into account a plethora of additional concerns, such as a car manufacturer’s various models, certain regional markets’ technological and legal peculiarities, and security aspects across all the involved systems. For example, the design must often consider secure communication channels and identity and access management. Owing to the large number and variety of those concerns, the architecture design process has an inherent complexity that requires management. To get started, project teams often deliberately limit the scope. For example, they might restrict the door lock functionality to a specific vehicle model in a pilot phase, using our platform for prototyping telematics services.3 If such pilots prove successful, the need often exists to quickly scale to full production while expanding to new regional markets and covering more of the manufacturer’s vehicles. For example, a pilot that started for a specific car model in Germany might have to be scaled to additional models and standard operation in the overall European market. To enable rapid scaling to multiple project teams, a way is needed to efficiently transfer gained experience among project teams. Managing the connected-­ vehicle solution space’s complexity and efficiently supporting cross-­ project communication and knowledge exchange require a corresponding expert role. We believe that the software architect role is a perfect fit for that expert role, despite the vivid arguments over what software

NOVEMBER/DECEMBER 2016

|

IEEE SOFTWARE

41

FOCUS: THE ROLE OF THE SOFTWARE ARCHITECT

4. Execute command Driver

Connected car

1. Issue command (for example, “unlock doors”)

3. Forward command 2. Send command

Mobile-device application 6. Forward new vehicle status

5. Send new vehicle status (for example, “doors unlocked”)

Cloud-based connected-vehicle back end

FIGURE 1. The high-level process flow for a remote door lock function. Designing a viable solution isn’t as straightforward as this process flow might suggest.

architecture actually is, the blurred profi le of the software architect role,4 and even the absence of a dedicated software architect role in popular process frameworks such as Scrum. Here, we offer our consolidated observations from five years’ experience in the connected-vehicle domain, which covered seven largescale projects with tens of thousands of customers. In successful projects, the responsibilities regarding software architecture were concentrated in individual experts. These experts, acting as software architects, were crucial to designing complex software systems and scaling the corresponding development. However, these experts’ business cards often didn’t overtly disclose their software architecture activities.

Architects Manage Complexity Designing a production-ready solution for the remote door lock function involves several dimensions of complexity and many architectural challenges. Figure 2 gives an overview. A basic remote vehicle function such as door locking should be reusable by many potential users in a variety of applications and use cases, 42

I E E E S O F T WA R E

|

such as in-car delivery, car sharing, or a concierge service. Figure 2 depicts examples of the potential users, such as vehicle owners, other drivers, and call centers that need the ability to perform vehicle commands on a vehicle owner’s behalf. Whereas a call center agent might use a proprietary application, vehicle drivers use the functionality on devices such as smartphones, tablets, or smart watches. An exposed Web API integrates both the call center case management software and the mobile applications. This context involves architectural considerations such as Web API design, message data formats, and Web security technologies. Moreover, the remote-door-lock solution must support a variety of vehicles that entail different controller area network5 (CAN) signals and network architectures and different telematics control unit (TCU) hardware types and software versions. (CAN is a widespread bus standard for in-vehicle communication; TCU is an embedded system providing a mobile communication interface for vehicles.) One of the most difficult architectural challenges is to provide an abstraction of the many vehicle

W W W. C O M P U T E R . O R G / S O F T W A R E

|

idiosyncrasies and offer a single interface to other components relying on remote vehicle functions. This is similar to an anticorruption layer.6 In Figure 2, the Virtual Vehicle component accomplishes this task. The design of an architectural concept for remote vehicle communication can employ two fundamentally different approaches: putting the application logic inside or outside the vehicle. This decision has an enormous architectural impact. When the Virtual Vehicle component sends a remote door lock command to the vehicle, the built-in TCU forwards the command to the CAN, from where the command reaches its target electronic control unit (ECU, an embedded system for controlling a vehicle subsystem).7 However, when the application logic is inside the vehicle, the TCU doesn’t necessarily send feedback to the Virtual Vehicle component about whether the subsequent door status is what the function call intended. The message might never have reached the vehicle because of a lost connection between the Virtual Vehicle component and the TCU. Alternatively, the TCU might have failed when processing the request, or the door might simply be open and therefore can’t be locked. In all cases, the logic of checking the door status after the command has been sent, and retrying the command where required, might be passed through to the user. This example indicates the need for a technical role that understands the overall system chain, all the way from the user front end to the vehicle’s control units. A TCU might have to be updated over the air to not only fi x bugs but also add features. If we consider the TCU as a key part of the overall system chain that’s under

@ I E E E S O F T WA R E

Scrum model

Software development domain

Connected-vehicle back end

V-model

Identity & Access

Service Context

Legacy Systems

Application Logic

Customer Context

Vehicle Master Data

Web API

Secure Web protocol (for example, HTTPS)

Virtual Vehicle

Automotive-engineering domain

Secure channel (for example, VPN)

TCU Bus systems (CAN) iOS, Android, Windows, ...

Call centers Drivers or vehicle owners

ECU

Product series: 574 TCU type: A TCU version: 1.4

ECU

ECU

Product series: 574 TCU type: A TCU version: 2.0

Product series: 345 TCU type: C TCU version: 1.0

FIGURE 2. The dimensions of complexity in designing a production-ready solution for the remote door lock function. VPN stands for virtual private network, CAN stands for controller area network, TCU stands for telematics control unit, and ECU stands for electronic control unit.

an architect’s control, then this role also requires understanding topics that abut the automotive-engineering domain, such as CAN signal encoding and distribution or TCU memory and performance restrictions. Between the Web API and Virtual Vehicle component is a large system landscape that provides common platform services. Together, these systems constitute the connected-vehicle back end in Figure 2. On one hand, this landscape contains dozens of systems that were developed a long time ago. On the other hand, it includes new back-end systems being developed to

enable vehicle-connectivity use cases, such as the Service Context component in Figure 2. For building end-to-end solutions, a technical role is needed that also understands the systems and dependencies in the connected-vehicle back end. For example, the back end includes these components: • The Identity & Access component handles user authentication and authorization. • The Customer Context and Service Context components hold the information about which

user owns which vehicle and has bought which services. • The Vehicle Master Data component determines which vehicle can provide which services (for example, remote door locking). Performing this capability check requires leveraging the vehicle master data. Typically, the system holding this data was in place long before the connected-vehicle features came onto the market and wasn’t built to be accessed for thousands of vehicles simultaneously. This is also often the case for other vehicle systems

NOVEMBER/DECEMBER 2016

|

I E E E S O F T WA R E

43

FOCUS: THE ROLE OF THE SOFTWARE ARCHITECT

scattered over several organizational units. So, another architectural challenge we’ve come across consistently is how to scale and integrate legacy systems from various organizational units that weren’t built to be integrated with the connected-­ vehicle back end. Similar architectural challenges of integrating legacy systems in new environments occur in many other industrial sectors.8 Further challenges arise from the various process models that different organizational units and engineering domains use. Typically, the highly safety-sensitive automotiveengineering discipline employs sequential development processes such as the V-model 9 —for example, by following the widespread ISO 26262:2011 standard.10 Often, the time between the specification phase and final product’s completion can be months or years. In contrast, new connected-vehicle back-end services and front ends are often built according to agile, iterative software development methods, such as Scrum or Extreme Programming. Designing a system whose components are built according to completely different process models, release cycles, and engineering mentalities is a major architectural challenge. From our experience in an enterprise context, it takes a lot of time to • align with many component representatives regarding overarching technical-integration details, • request interface extensions according to formal change management processes, or • reach consensus regarding the deployment details for different staging environments. We found that concentrating these activities in individual experts who 44

I E E E S O F T WA R E

|

therefore acted in the software architect role reduced friction. (These experts performed this role formally or informally and sometimes with a varying scope; see the sidebar “The Many Faces of a Software Architect.”) It’s also an efficient way to manage the end-to-end design of connected-vehicle functionalities and adequately cope with multiple levels of complexity.

Architects Facilitate Team Scalability Another aspect of the architect’s role deals with knowledge propagation and sharing, which is especially important in a fast-paced domain such as connected-vehicle software. Factors such as the widespread availability of built-in and retrofitted TCUs that let vehicles connect to the Internet, steadily accelerating mobile connection speeds, and users’ increasing familiarity with near-ubiquitous connectivity have sparked the automotive industry. Everybody is striving to find wellsuited use cases. Some people claim the next big thing is infotainment for drivers and passengers, some claim it’s in increasing vehicle utilization through sharing concepts such as car2go (www.car2go.com), and others are following different routes in this vibrant environment. These product ideas start as a small proof of concept (POC) to attract early as many users as possible. As soon as a POC emits positive signals, companies run a pilot with more users. They then run a scaled pilot with many users before rapidly transitioning to series production. The reference for speed of implementation is often successful Internet companies such as Apple, Google, and Facebook. New agile development teams—say, Scrum teams—must be

W W W. C O M P U T E R . O R G / S O F T W A R E

|

created rapidly to enable quick time to market. In this process, ensuring adequate knowledge transfer among the teams is important. Figure 3 sketches a possible growth path. The two software engineers involved in the POC have a comprehensive overview of the overall architecture and technologies. They act as knowledge multipliers when the new connected-vehicle service becomes a pilot and a Scrum team is staffed for the implementation. The pilot Scrum team (labeled 1 in Figure 3) is in charge of building a more complex solution with deeper integration in the automotive-­e nterprise-application landscape. For the scaled pilot, new software engineers are added, and a second Scrum team (labeled 2 in Figure 3) is created to handle additional work. Series production (for example, involving additional vehicle models) requires even more development teams (labeled 3, 4, and 5 in Figure 3). The development teams must cooperate and align when implementing an integrated product together. How should knowledge transfer and alignment among teams be organized? If all the teams use Scrum, a method for scaled Scrum development, such as the Nexus framework, 11 is appropriate. The Nexus framework defines a Nexus Integration Team consisting of a dedicated product owner, a Scrum master, and one or more members who might also be in several Scrum teams. The framework matches well with the staged scaling approach in Figure 3. The experts acting as a development team’s software architect are a perfect fit for the Nexus Integration Team. The Nexus Integration Team must manage integration of a connected-­ vehicle function built from separate

@ I E E E S O F T WA R E

THE MANY FACES OF A SOFTWARE ARCHITECT In the domain of connected-vehicle software, software experts in an enterprise context act within a wide spectrum of responsibilities and configurations of the software architect role. The following five dimensions broadly characterize how individuals formally and informally carry out this role.

THE JOB TITLE’S RELATION TO THE SOFTWARE ARCHITECT ROLE The job title adorning an individual’s business card might or might not indicate that person’s relation to software architecture activities. Besides the straightforward job title of software architect, a wealth of job titles cover a similar scope and include the term “architect,” such as solution architect, IT architect, enterprise architect, and system architect. However, the relation to software architecture becomes blurrier when you consider titles that don’t include “architect,” such as IT consultant, software engineer, and solution developer.

THE AMOUNT OF SOFTWARE ARCHITECTURE ACTIVITIES PERFORMED From day to day, architects might have to perform software architecture activities that are more or less typical. For example, in our context, solution architects are concerned almost entirely with software-architecture-related activities, such as system decomposition, modeling, and interface definition. In contrast, agile software development frameworks such as Scrum often transfer these activities to whole software development teams. So, individual developers might be involved in such activities in varying degrees.

THE NUMBER AND GRANULARITY OF COMPONENTS IN SCOPE The software architect role also differs regarding the number and granularity of components with which an architect is concerned. For example, enterprise architects usually design and govern large IT landscapes consisting of many applications. In contrast, some architects might be concerned with only a subset of those applications and their exposed interfaces, to design specific functionalities. The door lock scenario described in the main article falls in this category. On a lower level of abstraction, application architects are typically concerned with designing one or a few applications.

THE PROXIMITY TO PROGRAMMING ACTIVITIES Software architects perform different amounts of programming. For example, enterprise architects hardly ever program. Furthermore, differences exist among architects with identical job titles. For example, some IT architects might rarely program; instead, they design technical solutions for specific business processes. In contrast, other IT architects might daily contribute source code for one or more applications.

SPECIALIZATION Software architects frequently specialize. Specializations often occur in specific industrial sectors (such as the automotive industry) and functional domains (such as vehicle connectivity, powertrain optimization, and fabrication). Moreover, specializations frequently focus on specific technologies. This often becomes apparent from the corresponding job titles, such as automotive software architect, Java EE (Java Platform, Enterprise Edition) architect, and cloud architect.

subproducts. To do this, it ensures that each sprint produces an integrated increment. The team members should be software professionals experienced in systems engineering.11

The Nexus Integration Team must also propagate architectural knowledge among Scrum teams on both the interstage level (for example, pilot to scaled pilot) and intrastage

level (for example, scaled pilot to scaled pilot). To do this, it coaches and guides the Scrum teams to acquire, implement, and learn systemsengineering practices and tools.11 It

NOVEMBER/DECEMBER 2016

|

I E E E S O F T WA R E

45

FOCUS: THE ROLE OF THE SOFTWARE ARCHITECT

Proof of concept

Pilot

Time

1

Scaled pilot

1

2

2 Series production

1

4 3

5

FIGURE 3. Quickly scaling development teams from a few software engineers for a proof of concept to many tens or even hundreds of software engineers is common when companies implement connected-vehicle services. To enable adequate knowledge transfer, software architects (circled in the figure) act as knowledge multipliers and nuclei for new teams. The numbers in the figure indicate the various development teams.

also coaches them on the organizations’ development, infrastructural, or architectural standards. These tasks can be handled well by individual experts with a strong software architecture background (that might possibly be blended with knowledge from different architectural flavors such as system or solution architecture). These tasks match seamlessly with the tasks software architects typically perform. So, how should a project split the work among the Scrum teams when it scales up? The most obvious approach would be to build a 46

I E E E S O F T WA R E

|

front-end team, a back-end team, an embedded-vehicle team, and so forth. This satisfies the specialization found in the labor market and often in organizational structures. However, the teams would lose their independence. We often observed deadlocks and waiting periods when there were more than three or four teams. Another approach is to build feature teams such that each team develops a specific feature from end to end.12 Each team must possess the necessary skills, which can be quite challenging. In our experience, each

W W W. C O M P U T E R . O R G / S O F T W A R E

|

team must have at least one person with a functional and technical overview and thorough conceptual skills: the software architect. If a team had no architect role, we observed deteriorated code quality and a blurred component structure.

I

n software development projects, the need still exists for someone with strong conceptual skills, a deep knowledge of the problem domain, and good communications skills—that is, a software architect. Whether we’re talking

@ I E E E S O F T WA R E

ABOUT THE AUTHORS

about a Scrum team member who focuses on prioritizing technical stories in the backlog, a product owner advisor, an external coach, or many other possible roles with influence, the tasks of an architect remain. Digitalization as a megatrend reinforces IT’s importance. For the automotive sector, the next big trends are autonomous driving and cars as part of the Internet of Things. These trends further increase the underlying IT systems’ scope, reach, and complexity. That’s why we expect the software architect role to remain a major cornerstone of most complex automotive IT projects in the coming years.

SÖREN FREY is a senior IT architect of connected-vehicle software at Daimler TSS. His research interests are connected vehicles, cloud computing, software architectures, and machine learning. Frey received a PhD in computer science from Kiel University. He’s a member of the IEEE Computer Society, ACM, and the German Informatics Society. Contact him at soeren [email protected].

LAMBROS CHARISSIS is an IT architect of connected-vehicle

software at Daimler TSS. His research interests are connected vehicles, software architectures, and cloud computing. Charissis received a master’s in computer science from the University of Stuttgart. Contact him at [email protected].

Acknowledgments

JENS NAHM is the manager of the Enterprise Architecture

We thank Olaf Zimmermann and the anonymous reviewers for their valuable suggestions and comments on an earlier version of this article.

Team at Daimler TSS. His research interests are connected vehicles, software architectures, and cloud computing. Nahm received a Dipl. Inform. in computer science from the University of Stuttgart. Contact him at [email protected].

References 1. M. Alam, “The Top Five Trends for the Connected Car in 2016,” TechCrunch, 2 Jan. 2016; http://tech crunch.com/2016/01/02/the-top -five-trends-for-the-connected-car -in-2016. 2. D. Hardawar, “Buckle Up: The Connected-Car Revolution Is Almost Here,” Engadget, 13 Jan. 2015; www.engadget.com/2015/01/13 /connected-car-revolution. 3. T. Haberle et al., “The Connected Car in the Cloud: A Platform for Prototyping Telematics Services,” IEEE Software, vol. 32, no. 6, 2015, pp. 11–17. 4. M. Fowler, “Design—Who Needs an Architect?,” IEEE Software, vol. 20, no. 5, 2003, pp. 11–13. 5. ISO 11898, Road Vehicles— Controller Area Network (CAN), Int’l Org. for Standardization, 2015. 6. E. Evans, Domain-Driven Design:

7.

8.

9.

10.

Tackling Complexity in the Heart of Software, Addison-Wesley Professional, 2004. C. Ebert and C. Jones, “Embedded Software: Facts, Figures, and Future,” Computer, vol. 42, no. 4, 2009, pp. 42–52. W. Hasselbring, “Information System Integration,” Comm. ACM, vol. 43, no. 6, 2000, pp. 32–38. J. Weber, “Vehicle Development Projects—an Overview,” Automotive Development Processes: Processes for Successful Customer Oriented Vehicle Development, Springer, 2009, pp. 1–15. ISO 26262:2011, Road Vehicles— Functional Safety, Int’l Org. for Standardization, 2011.

11. K. Schwaber, Nexus Guide v1.1; www.scrum.org/Resources/The -Nexus-Guide. 12. C. Larman and B. Vodde, Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum, Addison-Wesley Professional, 2008.

Selected CS articles and columns are also available for free at http://ComputingNow.computer.org.

NOVEMBER/DECEMBER 2016

|

I E E E S O F T WA R E

47

FOCUS: THE ROLE OF THE SOFTWARE ARCHITECT

Software Architects in Large-Scale Distributed Projects An Ericsson Case Study Ricardo Britto and Darja Šmite, Blekinge Institute of Technology Lars-Ola Damm, Ericsson

// This story is about Ericsson architects, their roles and responsibilities, and the effort they spent guarding and governing a large-scale product developed by distributed teams. Instead of trendy approaches, a centralized approach was necessary to deal with legacy and distribution. //

closely collaborating with the developers. Philippe Kruchten summarized software architects’ responsibilities, including defi ning the architecture; maintaining its architectural integrity; and consulting with, helping, and coaching development teams.1 Paul Clements and his colleagues described architects’ skills and knowledge, such as communication and learning skills.10 Grady Booch11 and Frank Buschmann12 have written on aspects of architects’ daily work. However, most of the vast literature on software architects has focused on the architect as a “onesoldier army.” This seems reasonable in small projects but infeasible in large-scale projects, which require teams of architects.1 Because many large-scale projects are spread across multiple locations, we raise three questions: What are software architects’ roles and responsibilities? How are they organized in large-scale distributed software projects? How does adding new teams in remote locations influence the architects’ role? Here, we share our results from studying the development of a large, distributed software product at Ericsson, a global leader in telecommunications with sites worldwide. We focus on the architects steering this product’s development.

Roles and Responsibilities

MUCH HAS BEEN written about software architects, their roles,1–5 their responsibilities, 6–8 and how they’re “made.”9 Martin Fowler proposed this classification of software architects:4 48

IEEE SOFTWARE

|

• Architectus Reloadus makes important decisions early on, ensuring a system’s conceptual integrity. • Architectus Oryzus addresses problems in a project by

PUBLISHED BY THE IEEE COMPUTER SOCIETY

The architectural paradigm employed in a software product’s architecture affects how software architects carry out their work.13 Whereas most new products at Ericsson have a modular or serviceoriented architecture, legacy products, such as the case we describe here, have a monolithic architecture. 0740-7459/16/$33.00 © 2016 IEEE

A prioritized business use case is assigned to a system architect. System

Product

Development team

The system architect performs impact analysis and forms a virtual team with representatives from the impacted products to define the solution.

System-level architects (guardians, Architectus Reloadus)

1

Product-level architects (guardians and mentors, Architectus Reloadus and Architectus Oryzus )

2

The product architect specifies the product-level design with the design lead from the employed development team (team members are included in the design work when applicable).

Design leads or team-level architects (guardians and mentors, Architectus Oryzus )

3

The development team performs the detailed design and implementation with the product architects’ support.

FIGURE 1. The organization and workflow of Ericsson’s software architects. This centralized approach aims to ensure cross-team and cross-location alignment and to guard the complex system architectures.

The scale and complexity of Ericsson’s software products, together with the distribution of development teams across multiple locations, also impact how architects perform their work. When teams and development locations are added to a project, it requires extra support to guard product integrity and mentor the teams while they climb the learning curve. In distributed environments, this introduces several challenges. One Ericsson software architect referred to communication overhead: “It would be much easier to explain to the developers things about the product’s architecture if they were in Sweden, because most of the time we only communicate via the code review tool and email.” Another architect pointed out the necessity of guarding and control: “When multiple teams work together on a task, the developers across teams do not communicate as well as within a team. Therefore, they often introduce task confl icts that we fi nd in their code, which otherwise the teams would not identify themselves.” To ensure cross-team and crosslocation alignment and to guard the

complex system architectures, Ericsson architects are organized in three levels (see Figure 1). At the system level, a team of architects of the type Architectus Reloadus ensures that the products included in a system can communicate with each other. They closely collaborate with product-level architects and coordinate the design of the features, interfaces, and protocols used in the system—that is, the system architecture. They also review product-level solutions and guard the system’s evolvability. These architects are mostly in Sweden. At the product level, a team of architects fulfi ls the Architectus Reloadus and Architectus Oryzus roles. These architects, who are experienced, skillful developers, lead the design of technical solutions and guard the integrity and evolvability of the product and the system architecture. They collaborate closely with system-level architects and software development teams throughout solution implementation. They steer software design, ensure that design rules are followed, promote the use of design patterns, and ensure code

quality through code reviews. They help guard the architecture and the deliverables’ quality. They also mentor the software teams by sharing their knowledge, providing feedback through code reviews, suggesting improvements, and helping out in urgent situations to speed up development. These architects are also mostly in Sweden, and they’re this article’s main focus. At the development team level, senior developers called design leads (or team-level architects) support the design of technical solutions. They ensure that their team follows the design rules and design patterns, which generally are defi ned by product-level architects. They also help productlevel architects guard a product’s architectural integrity and evolvability and help ensure the quality of deliverables through code and documentation reviews. The more expertise and experience design leads have, the more autonomous their teams are; they can provide more support to product-level architects with mentoring and guarding. The product and development team levels might vary slightly among

NOVEMBER/DECEMBER 2016

|

I E E E S O F T WA R E

49

FOCUS: THE ROLE OF THE SOFTWARE ARCHITECT

Area of product-level architects’ responsibility

rve

Design reviews

ng

an

dm en

tor

ing

cu

Design of technical solutions

Te

am

lea

rni

Code reviews

Task implementation

Area of team responsibility A

B C Level of team maturity

D

FIGURE 2. The authority matrix. For a description of the maturity levels, see the main article. As a team matures, it should get more independent and require less support from the product-level architects.

different Ericsson products. In our case, the product level was “thicker” and centralized almost all responsibility for the overall design of the technical solutions to be implemented in the product. The overall responsibility for guarding the product architecture’s integrity and evolvability was also centralized. This means that even the more experienced teams were never fully autonomous. More recent products with a service-oriented architecture have a much thinner product level. That is, they have approximately 50 percent fewer architects, and the teams shoulder much of the responsibility.

How Many Product-Level Architects Do You Need? In our case study, the main factor affecting the extent of the product-level 50

I E E E S O F T WA R E

|

architects’ involvement was the development teams’ maturity. To visualize the product-level architects’ amount of work and area of responsibility, we designed an authority matrix (see Figure 2). The curve in the matrix shows that as a team matures, it should get more independent and require less support from the product-level architects. The four activities on the y-axis are those that concerned the product-level architects the most. The x-axis indicates the four levels of team maturity. At level A, an immature team has no or very basic knowledge about the product’s code and architecture. Level-A teams require much mentoring and support from the architects, even when implementing (coding, testing, and documenting) noncomplex technical solutions.

W W W. C O M P U T E R . O R G / S O F T W A R E

|

Product-level architects guide the teams during the implementation and are actively involved, with both reviewing and approving code. At level B, teams have sufficient knowledge to implement noncomplex technical solutions without much guidance. More knowledgeable team members and design leads review the implemented code, but product-level architects still review most of the design and code. At level C, experienced, mature teams with good knowledge of the product architecture implement complex technical solutions that have significant architectural impact. These teams review and approve their own code. Product-level architects are involved only in approval when the architecture’s critical components are affected. (A critical component contains core functionality that executes key operations.) Level-C teams also perform more solution design. Productlevel architects support these teams by mentoring the design of technical solutions and providing on-demand guidance in the initial implementation stages. At level D, very experienced and rather autonomous teams implement complex technical solutions independently, even ones affecting the product architecture’s critical components. The code they implement doesn’t need product-level architects’ approval. Level-D teams also drive the design and review of technical solutions. Product-level architects are involved only in the technicalsolution design. Our authority matrix is based on the product-level architects’ experience and the data we collected and analyzed in our case study (see the sidebar “The Ericsson Case Study” and Figure 3). In particular,

@ I E E E S O F T WA R E

THE ERICSSON CASE STUDY

Our case study (see the main article) investigated the development of a telecom product that has evolved for more than 15 years. At the time of our investigation, the product employed more than 150 employees (including 15 productlevel architects, 20 design leads, 100 developers working in 22 teams, and 15 other supporting roles) in Sweden, India, Italy, the US, and Turkey. One team comprised only productlevel architects; each of the other teams consisted of a design lead and five to eight developers. The results presented here are based on the data from 240 tasks carried out from January 2014 to June 2016. We employed the following data collection methods. First, we performed archival research. We analyzed managerial documents (plans and reports) related to 26 product customization tasks (PCs), measuring the effort architects expended for development and support. Twelve teams participated in these PCs (for more on these teams, see the main article). We also surveyed the Gerrit code review repository to determine the number of defects identified through code reviews completed for a random selection of tasks: 10 PCs, 188 trouble reports (TRs), 9 product improvements (PIs), and 11 standardizations of market features (MFs). We manually categorized the defects using the ISO/IEC 25010:2011 standard.1 The product’s unit manager validated the collected archival data.

our statistical analysis of the performance data confi rmed that the more immature teams required more support from the product-level architects. Figure 3a shows the teams’ distribution. The Turkish team was classified as level A. The five recently onboarded Indian teams started at level A; four of them progressed to level B during our study. The four Swedish teams and the US team were classified as level C. One Swedish team temporarily reached level D (productlevel architects joined the team), and a temporary level-D team comprised product-level architects, developers, and design leads from Sweden and India.

Next, we conducted unstructured interviews with the unit manager and product-level architects. We collected their knowledge about how the architects were organized, the architects’ roles and responsibilities, and the development teams’ maturity. Finally, we held four workshops with the unit manager and product-level architects to measure the 26 PCs’ task complexity—the difficulty of performing them. We selected one of the PCs as the baseline and had participants measure the other PCs in relation to it. Using planning poker, they attributed a positive integer (complexity points) to each PC. To check the assigned measures, the architects consulted technical-solution specifications whenever needed. The PCs, PIs, and MFs resembled independent projects because they had start and end dates, a responsible team, and expected results. In general, PCs took 1 to 3 months, PIs took 1 to 2 months, and MFs took 2 to 6 months.

Reference 1. ISO/IEC 25010:2011—Systems and Software Engineering— Systems and Software Quality Requirements and Evaluation (SQuaRE)—System and Software Quality Models, Int’l Org. for Standardization, 2011; www.iso.org/iso/catalogue_detail.htm?csnumber=35733.

The Effort Needed to Guard and Mentor The teams’ maturity also determined the number of required product-level architects. In our case study, the rule of thumb seemed to be that each level-C team needed approximately one-half of a product-level architect and that each level-A or level-B team needed one product-level architect. As we mentioned before, no permanent level-D teams were in our case study. In cases involving critical work demanding specific architectural knowledge and quick development, product architects might temporarily join a team to engage in coding and testing. Such teams can qualify as level-D teams.

Figure 3b shows the effort that product-level architects spent supporting 12 teams (the teams we mentioned earlier, except the temporary Swedish team) performing 26 product customization tasks. The less mature teams (levels A and B) received significant support from the product-level architects. In contrast, mature teams (levels C and D) worked more autonomously. We verified these results’ statistical significance using the Kruskal-Wallis one-way analysis of variance (significance level = 0.01, p-value = 0.008493). Part of the effort involved mentoring, which the product-level architects provided though meetings

NOVEMBER/DECEMBER 2016

|

I E E E S O F T WA R E

51

FOCUS: THE ROLE OF THE SOFTWARE ARCHITECT

4 teams reached level B after one year

Teams in India Teams in India Teams in Sweden

A team in Turkey

(a)

Level A

A team in the US Level B

Level C

A temporary team in Sweden A temporary multisite team Level D

2.58 1.92

0.62

Level A

1,250

58

94

16

6

11

459

606

477

24

28

6

3

10

176

230

Maintainability— modifiability

3 2,944.33 h 39.00 h 233.33 0.51

Reliability

5 1,957.60 h 68.60 h 221.00 0.43

Performance

4 1,747.25 h 73.25 h 42.50 0.88

Portability

Level D

Compatibility

Level C

Functional

Level B

Total

No. of tasks 14 Mean total effort 2,547.50 h Mean support effort (SE) 160.50 h 77.86 Mean complexity (CP) 1.18 (b) Std. deviation (SE/CP)

0.59

Teams

(c)

Maintainability— analyzability

Product-level architects

FIGURE 3. Evidence supporting the authority matrix in Figure 2. (a) The distribution of the teams in our case study. (b) The effort the architects spent supporting the teams. The curve shows the mean ratio between the support effort and task complexity. (c) The proportion of different defects the product-level architects and the teams found. The more immature teams required more support from the product-level architects. 52

I E E E S O F T WA R E

|

W W W. C O M P U T E R . O R G / S O F T W A R E

|

(videoconferences or teleconferences with remote teams) or synchronous chat. Most of the effort involved code reviews, which also provided mentoring opportunities and involved clarification of architectural principles and improvement recommendations. In some cases, support included detailed instructions that even contained code samples to facilitate the understanding of the design.

Problems That Product-Level Architects Prevented To ensure the product architecture’s integrity and evolvability, productlevel architects review new and modified code to identify defects that might harm the product architecture, induce technical debt, and complicate the architecture’s evolvability. Although Ericsson devotes much attention to rigorous regression tests, not all defects can be caught automatically, especially nonfunctional maintainability defects.14 Maintainability defects can lead to code entropy,15 affecting the architecture’s integrity. At Ericsson, new developers working on legacy products often have problems understanding the code’s structure, which leads to the fear of changing existing code and the tendency to duplicate code.16 This behavior is common in immature teams, and architects play a vital role in detecting such defects through code reviews, making code review a crucial asset. Figure 3c contains results about defects revealed through code reviews performed on 220 tasks. We focused on two subcategories of maintainability defects closely related to Ericsson architects’ guardian role: modifiability and analyzability.17 The code reviews revealed 1,727 defects; product-level architects dis-

@ I E E E S O F T WA R E

covered 72.38 percent of those defects, and the teams discovered 27.62 percent. Of those defects, 85.18 percent were maintainability defects, and the product-level architects revealed 72.40 percent of them. Considering that testing techniques don’t easily reveal maintainability defects, the productlevel architects’ active participation helped in early detection of defects that otherwise could have affected the product architecture’s integrity and evolvability.

A

lthough the software architects’ hierarchy, roles, and responsibilities we described aren’t unusual,1,18 they aren’t trendy, either. So, in this case study, why didn’t Ericsson fully embark upon trendier approaches such as microservices19 and agile ways of working? The answer is, because of legacy code and distributed development. Although this case study implemented many agile practices such as continuous integration, continuous

delivery, and DevOps, certain limitations prevented fully exploiting the new approaches. The product’s monolithic architecture made relying on coordination by mutual adjustment problematic.20 However, this doesn’t automatically mean that Ericsson applied traditional coordination and control. The architects’ hierarchy wasn’t traditional in the sense that people higher up in the hierarchy could overrule the ones further down. Rather, it was a network of architects with

CSI-IEEE CS Joint Education Award CALL FOR AWARD NOMINATIONS Deadline 15 October 2016 CRITERIA

The Computer Society of India (CSI) / IEEE Computer Society Education Award is a joint CSI-IEEE national society award that recognizes educators who have made significant contributions to computer science and engineering education.

ELIGIBILITY • • •

Nominees should be teaching in India, preferably for a least the past three years. Nominators must be either CSI, IEEE or IEEE CS members. Self-nominations are not accepted.

NOMINATION REQUIREMENTS

The nomination form must include at least two endorsements.

AWARD

The CSI/IEEE-CS Education Award will consist of a certificate and US $500 honorarium.

PRESENTATION

The award will be presented at the CSI 2016: Annual Convention of CSI to be held between 8–10 December 2016 at Le Méridien Coimbatore, India.

SUBMISSIONS

Nomination forms should be sent to [email protected] by the 15 Oct. deadline.

NOVEMBER/DECEMBER 2016

|

I E E E S O F T WA R E

53

FOCUS: THE ROLE OF THE SOFTWARE ARCHITECT

THE PRESENT AND FUTURE OF SOFTWARE ARCHITECTS AT ERICSSON

The speed with which new technologies are introduced has compelled Ericsson’s software architects to adapt quickly. For example, cloud computing forces architects to rethink existing architectures and use different approaches to design new ones. It’s no longer only about designing software to conform to a particular hardware specification, because virtual environments hide the underlying infrastructure. At the same time, many new technologies and methods have reduced Ericsson architects’ workload. For example, continuous-integration and continuousdelivery tools require less manual effort to ensure that code changes don’t harm a product architecture’s behavior. To implement continuous integration and continuous delivery in our case study (see the main article), we adapted the product’s architecture to maintain full backward compatibility despite the frequent releases—for example, through strict version control of interfaces. Ericsson also employs DevOps. In our case study, two product-level architects were dedicated to ensuring smooth collaboration between Ericsson’s development team and one customer’s operation team. This shortened feedback loops, which led to better interaction with Ericsson’s customers. Another trend influencing the role of Ericsson architects is the agile transformation. To be able to benefit from agile ways of working, teams are expected to have more autonomy, and architects serve primarily as mentors supporting the teams. Although Ericsson has tried to increase team autonomy for the case study’s product, the company has focused on increasing autonomy for more recent products not limited by legacy architectures. Finally, Ericsson architects must be prepared to work on products developed at multiple locations. As in many other large organizations, corporate cultures and ways of working differ among Ericsson’s distributed units. So, software architects are often expected to possess strong leadership skills and the ability to align the philosophy, traditions, and attitudes toward quality and maintainability across all development locations.

different focus areas who were involved in decisions related to their competences. On the product level, the architects and other experienced developers had designated approval rights based on their competences. They governed this approval structure and process as they saw fit. This governance structure was similar to large distributed open source projects such as Eclipse and Android. That is, the open-source 54

I E E E S O F T WA R E

|

community has also concluded that large development projects sometimes require a centralized approach to secure the software’s quality. Finally, the architects’ hierarchy was also an answer to the challenges of distribution. Ericsson is no exception to the trend of offshoring parts of development to low-cost regions; much of its product development has become global. However, many offshore sites are infamous for high

W W W. C O M P U T E R . O R G / S O F T W A R E

|

attrition rates. This means that employee turnover results in continuous loss of expertise and the neverending demand for mentoring and steering. Knowledge loss also occurs from frequently moving resources in and out of products because of rapidly changing business needs. In such situations, the centralization of architectural decisions such as we described here secures the architectural knowledge’s stability and its availability for new developers and teams. For a look at the present and future of Ericsson software architects, see the related sidebar. References 1. P. Kruchten, “The Architects—the Software Architecture Team,” Proc. 1st Working IFIP Conf. Software Architecture (WICSA 99), 1999, pp. 565–583. 2. J.F. Hoorn et al., “The Lonesome Architect,” J. Systems and Software, vol. 84, no. 9, 2011, pp. 1424–1435. 3. M.B. Romney, “The Software Architect,” Comm. ACM, vol. 50, no. 5, 2007, pp. 75–81. 4. M. Fowler, “Who Needs an Architect?,” IEEE Software, vol. 20, no. 5, 2003, pp. 11–13. 5. S. Sherman and I. Hadar, “Toward Defining the Role of the Software Architect,” Proc. 8th Int’l Workshop Cooperative and Human Aspects of Software Eng. (CHASE 15), 2015, pp. 71–76. 6. P. Kruchten, “What Do Software Architects Really Do?,” J. Systems and Software, vol. 81, no. 12, 2008, pp. 2413–2416. 7. A.B. Bondi, “The Software Architect as the Guardian of System Performance and Scalability,” Proc. ICSE Workshop Leadership and Management in Software Architecture (LMSA 09), 2009, pp. 28–31. 8. A. Tang et al., “On the Responsi­bilities

@ I E E E S O F T WA R E

10.

11.

12.

13.

14.

15.

16.

17.

18.

ABOUT THE AUTHORS

9.

of Software Architects and Software Engineers in an Agile Environment: Who Should Do What?,” Proc. 4th Int’l Workshop Social Software Eng. (SSE 11), 2011, pp. 11–18. B. Correa, “How Are Architects Made?,” IEEE Software, vol. 30, no. 5, 2013, pp. 11–13. P. Clements et al., “The Duties, Skills, and Knowledge of Software Architects,” Proc. 6th Working IEEE/IFIP Conf. Software Architecture (WICSA 07), 2007, pp. 20–22. G. Booch, “The Architect’s Journey,” IEEE Software, vol. 28, no. 3, 2011, pp. 10–11. F. Buschmann, “Value-Focused System Quality,” IEEE Software, vol. 27, no. 6, 2010, pp. 84–86. J. Lewis and M. Fowler, “Microservices: A Defi nition of This New Architectural Term,” 25 Mar. 2014; http://martinfowler.com/articles /microservices.html. M.E. Fagan, “Design and Code Inspections to Reduce Errors in Program Development,” IBM Systems J., vol. 15, no. 3, 1976, pp. 182–211. C.E. Ebeling, An Introduction to Reliability and Maintainability Engineering, 2nd ed., McGraw-Hill, 2009. G. Hanssen et al., “Software Entropy in Agile Product Evolution,” Proc. 43rd Hawaii Int’l Conf. System Sciences (HICSS 10), 2010, pp. 1–10. ISO/IEC 25010:2011—Systems and Software Engineering—Systems and Software Quality Requirements and Evaluation (SQuaRE)— System and Software Quality Models, Int’l Org. for Standardization, 2011; www.iso .org/iso/catalogue_detail.htm?cs number=35733. J.Y. Bang et al., “How Software Architects Collaborate: Insights from Collaborative Software Design in Practice,” Proc. 6th Int’l Workshop Cooperative and Human Aspects of

RICARDO BRITTO is a PhD candidate in the Blekinge Institute of Technology’s Department of Software Engineering. His research interests include large-scale agile software development, global software engineering, search-based software engineering, and software process improvement. Britto received an MSc in electrical engineering from the Federal University of Rio Grande do Norte. Contact him at [email protected].

DARJA ŠMITE is a professor in the Blekinge Institute of Technology’s Department of Software Engineering and a part-time research scientist at SINTEF Information and Communication Technology. Her research interests include the effect of globalization and offshoring on software companies, large-scale agile software development, and software process improvement. Šmite received a PhD in computer science from the University of Latvia. Contact her at [email protected].

LARS-OLA DAMM works at Ericsson, where he manages soft-

ware development teams working on large distributed projects. His main research interest is software process improvement. Damm received a PhD in software engineering from the Blekinge Institute of Technology. Contact him at lars-ola.damm@ ericsson.com.

Software Eng. (CHASE 13), 2013, pp. 41–48. 19. A. Balalaie, A. Heydarnoori, and P. Jamshidi, “Microservices Architecture Enables DevOps,” IEEE Software, vol. 33, no. 3, 2016, pp. 42–52. 20. H. Mintzberg, Mintzberg on Management: Inside Our Strange World of Organizations, Free Press, 2007.

F O LLOW US

Selected CS articles and columns are also available for free at http://ComputingNow.computer.org.

@s e cu rit y p riv a c y

NOVEMBER/DECEMBER 2016

|

I E E E S O F T WA R E

55

FOCUS: THE ROLE OF THE SOFTWARE ARCHITECT

EmbeddedSoftware Architects It’s Not Only about the Software Pablo Oliveira Antonino, Andreas Morgenstern, and Thomas Kuhn, Fraunhofer Institute for Experimental Software Engineering

// Computer scientists’ knowledge of embeddedsystems concepts such as controllers and actuators is usually limited. So, the role of embedded-software architect is often played by engineers from other fields who have a limited education in software architecture. //

IN THE MID-1990S, software architecture had its boom, triggered mainly by the Software Engineering Institute’s work, Rational’s 4+1 views, and Siemens’ four views.1 From that point on, software architecture gained great visibility in the computer science community. Consequently, many of the mature architecture-centered methodologies 56

IEEE SOFTWARE

|

and tools have been developed mainly by the computer science community.2 Computer scientists have been— and the great majority still are— educated with a mind-set concentrating on the structure of information systems. These systems traditionally rely on • standard infrastructures to

PUBLISHED BY THE IEEE COMPUTER SOCIETY

support a software platform, which provide commonly used base services and abstractions from the hardware, and • virtualization to separate independent software systems from each other and improve robustness and availability through live migration. 3 However, with the advent of embedded systems, which has been followed by the emergence of cyberphysical systems,4 a tremendous demand has arisen for professionals who understand both software and hardware specifications. Because of computer scientists’ traditional education, they have difficulty reasoning on aspects such as communication bus capacity, how delays and jitter affect control loop behavior, and functions realized by solenoids and other electromechanical devices.5 Because computer scientists generally lack knowledge of embedded systems’ nonsoftware properties, electrical and mechanical engineers are assuming roles that computer scientists exclusively used to play, such as the role of architect. This wouldn’t be a problem if these engineers had an architecture-related formal education or had developed this competence throughout their career. But in companies for which we provide architecture consultancy, we’ve observed that the architects have limited architecture knowledge. This has been the case in the automotive and transportation, automation and plant-engineering, and medical-device domains. (The average teams for which we provide consulting have more than 150 engineers, are globally distributed, and deal with systems of approximately 10 MLOC.) Here, we look in detail at the 0740-7459/16/$33.00 © 2016 IEEE

problems we’ve observed with embedded-software architects, the problems’ causes, and possible ways to deal with them.

Recurring Problems In our projects, we’ve identified the following two main problems.

Incompleteness and Inconsistencies Due to Missing Traceability The development of software-based systems, regardless of whether or not they’re embedded, involves different stakeholders, such as the project manager, developers, and users. They all have different concerns to be understood, prioritized, and realized. One main responsibility of the architect is to identify core aspects that will drive the architecture design, which centers on identifying concerns that are risky and expensive to change—the architecture drivers (see Figure 1). In industry projects, we’ve observed that embedded-software architects neglect the fundamental traceability that should exist between the architecture drivers and architecture design. Instead, they tend to focus on isolated parts of the architecture design. Other scientists have also observed this situation in cases involving medical devices submitted for US Food and Drug Administration approval.6 For example, we’ve often encountered architects—usually noncomputer scientists—who focus on only the hardware and network specifications and assume that the software engineers will deliver the software in an optimal state. On the other hand, we’ve observed experienced architects—mainly computer scientists—who focus on only the software and assume that the electrical and mechanical engineers are aware of all the assumptions and

Architecture design Architecture drivers Business drivers

Function networks

Functional requirements

Realize Drive

Stakeholders Quality requirements

Realize

Software entities Deploy

Constraints

Hardware entities

FIGURE 1. Architecture drivers and architecture perspectives as the main building blocks of architecture specifications. Architecture drivers are critical aspects that are risky and expensive to change.

constraints necessary to properly deploy a complex piece of software in the hardware. So, the whole architecture specification is often incomplete and inconsistent, which results in an intense effort to properly integrate the embedded system’s various aspects.

Architectural Smells Martin Fowler introduced the term “bad smells” in the software context.7 He related them to characteristics in source code snippets that negatively affect quality aspects such as testability and reusability. Similarly, an architectural smell is a “commonly used architectural decision that negatively impacts system quality.”8 Here are two examples: • An Extraneous Connector occurs when two connectors of different types connect a pair of components. • A Scattered Functionality occurs when multiple components realize the same high-level concern and some of them are responsible for orthogonal concerns.

Our intention isn’t to present a catalog of architectural smells but to discuss how the profi les of embeddedsystems architects have contributed to these smells’ occurrence. For example, in Figure 2a, the vehicle sensor processor computes sensor measures and makes them available on the CAN (Controller Area Network) bus. Despite this architecture practice being common, an Extraneous Connector often occurs because of the additional direct connection between two components deployed on the same ECU (Electronic Control Unit), as indicated in Figure 2a by the obstacle distance request sent from the cruise control to the vehicle sensor processor. This additional dependency might result in challenges for evolving that processor. This architectural smell also implies a deployment constraint because the vehicle speed control and cruise control must be deployed on the same ECU. In this context, one possible solution to the Extraneous Connector involves the AUTOSAR (Automotive Open System Architecture; www

NOVEMBER/DECEMBER 2016

|

I E E E S O F T WA R E

57

FOCUS: THE ROLE OF THE SOFTWARE ARCHITECT

Wheel rotation speed sensor

Front ultrasonic distance sensor

Wheel rotation

Wheel rotation speed sensor

Distance sensor value

Front ultrasonic distance sensor

Wheel rotation

Distance sensor value

Vehicle control unit Vehicle sensor processor

Vehicle control unit

Obstacle distance request Cruise control

+ Vehicle speed: int + Obstacle distance: int – ... : int

Obstacle distance

Vehicle speed, obstacle distance, ...

Vehicle sensor processor

Cruise control

+ Vehicle speed: int + Obstacle distance: int – ... : int Vehicle speed, obstacle distance, ...

Vehicle speed, ...

> AUTOSAR VFB interface

CAN driver interface

AUTOSAR virtual functional bus

CAN bus

Vehicle speed, obstacle distance, ...

CAN messages CAN driver interface

CAN driver interface Vehicle speed

Transmission control

Vehicle speed, obstacle distance

> AUTOSAR VFB interface

CAN bus Transmission control unit

Vehicle speed

Transmission control

(a)

CAN driver interface

Transmission control unit

(b)

FIGURE 2. Dealing with an architectural smell. (a) An Extraneous Connector smell, which is often found in embedded software. (b) A mitigation strategy using the AUTOSAR (Automotive Open System Architecture) architecture. Architectural smells are architectural decisions that negatively impact system quality. CAN stands for Controller Area Network.

.autosar.org) reference architecture. Figure 2b shows this solution, in which every information exchange between software components is through an AUTOSAR Virtual Function Bus. Had the embedded-software architects taken computer science courses, they would have learned such strategies for overcoming architectural smells. For example, some courses teach architecture tactics such as multilayers and microkernels. 58

I E E E S O F T WA R E

|

Other courses teach the “Gang of Four” design patterns9 not only as a way to improve low-level design but also to mold the students’ mind-set to consider these patterns at the architecture level. The consequence of having architects who aren’t familiar with these best practices is the enormous frequency of architectural smells, such as those we’ve often found in the embedded architectures we’ve reviewed. We’ve received several

W W W. C O M P U T E R . O R G / S O F T W A R E

|

requests to assess an architecture’s quality because of the difficulties companies faced in evolving their systems when system complexity increased beyond a certain limit. In many cases, a key reason for these difficulties was well-known architectural smells. Also, in most of these cases, the architects had no computer science education and were barely familiar with architecture best practices. So, they designed the architecture to address only a

@ I E E E S O F T WA R E

particular set of features and not to cope with evolutionary processes. Information systems architectures aren’t completely free of architectural smells, either. However, our discussions with colleagues who work exclusively on information systems led us to conclude that embeddedsoftware architectures suffer from architectural smells more than information systems architectures do.

The Problems’ Sources The recurring problems we just described have the following two sources.

Misunderstood Responsibilities A recurring question is, what’s the architect’s role in the development team? Peter Eeles and Peter Cripps understood that architects not only are software project technical leads but also are responsible for the success or failure of the project as a whole.10 Eeles and Cripps argued that, to achieve these goals, architects must • lead software design teams, monitoring code quality and test coverage and ensuring that the system works as expected; • understand the development process and ensure that the teams involved in development will follow it; • understand the business domain— its concepts and terminologies; • be good communicators; and • be decision makers. Our experience has shown that embedded-software architects must also • lead hardware development teams and monitor the

hardware’s architecture-relevant properties and • understand, as much as is necessary, the development process for all relevant portions of the system’s subsystems (software, hardware, electrical, and their integration). In the companies for which we provide consulting, we never found an architect with these seven characteristics. Rather, the architects focused only on the system’s technical aspects that were closest to their strengths. For example, architects with a computer science background tended to focus on only the software artifacts, making unrealistic hardware assumptions. Electrical and mechanical engineers tended to go in the opposite direction, focusing mostly on sensors, actuators, communication buses, fieldprogrammable gate arrays, and other hardware artifacts and neglecting the importance of sound software structures. This technical experience is important because architects are supposed to make critical, long-term technical decisions. In addition, successful architects must have leadership and social skills. We’ve observed that some of our customers assigned the architect role to people who didn’t fit the architect’s profile. In spontaneous interviews with embedded-software architects, we discovered that most of them got their role because they were great engineers and had been working for the company for years. But we also found that many of them fit the profile of a senior engineer, not an architect. Obviously, architects need communication skills, as Eeles and Cripps also highlighted. An embeddedsystems architect might not have the

technical capabilities to approach software and hardware artifacts equally. So, besides a general notion of both groups of artifacts and how they relate to each other, an architect should know who can dig into detail in each group of artifacts, assess the risks, and make the appropriate architecture decisions.

Aversion to Models or Inadequate Abstraction Skills A considerable number of computer scientists are still skeptical about using models to document softwarebased systems. Often, engineers with a computer science education have told us that the architects were “those who make more money than we do and whose main duty is to draw boxes and lines that represent a system that will soon become outdated.” They claimed that the software being implemented was so subject to changes that investing time in coding was more worthwhile than investing in documenting or modeling the architecture. Some of them even claimed that if the software is written well, the source code is the only documentation needed. On the other hand, we’ve observed that electrical and mechanical engineers who were either involved in pure implementation tasks or had the role of architect saw the value of detailed model-based architecture documentation. However, we’ve also observed their limited ability to think on multiple abstraction levels. One reason for this is that their education didn’t prepare them properly. In contrast, many computer scientists have this abstracting capability. Nevertheless, as we mentioned before, many of them didn’t see the value in documenting or modeling the architecture because the source code was all that mattered. At this point, a dissonant

NOVEMBER/DECEMBER 2016

|

I E E E S O F T WA R E

59

FOCUS: THE ROLE OF THE SOFTWARE ARCHITECT

situation existed. Some professionals had the skills to perform the task but didn’t see its value; the other group saw the value but wasn’t educated to do the task properly. When comparing these two groups, we understand that because mechanical and electrical engineers are used to electrical, hydraulic, and other models necessary to their domain, they see value in architecture models. They have this mind-set because the systems they usually build have something to do with tangible artifacts such as valves, pumps, and printed circuits, which must be well understood and analyzed before realization. Regarding pure software, which is the main (and usually the only) artifact that traditional computer scientists manipulate, they have, in a certain sense, too much freedom to realize their products. For example, if an information system performs an erroneous operation, in many cases a rollback followed by a code fix, recompilation, and software redeployment is enough to recover from a critical software failure. However, when the software controls safety-critical embedded systems such as those in airplanes, cars, and medical devices, more is required than the usual architecture practice as defended by some of the computer scientists we mentioned. We’ve actually observed widespread adoption of models in the embedded-systems domain. For instance, our customers in the transportation domain have made these comments: Ninety percent of the software embedded in our systems is generated from models. For the critical parts of our system, 60

I E E E S O F T WA R E

|

we completely generated the code. I do not trust code written by humans. Engineers who do not welcome model-based engineering are not welcome in our company.

Two important reasons to adopt architecture specification of embedded systems are to • communicate the software properties to the engineers responsible for the nonsoftware artifacts and • make the embedded system architecture specification as a whole (software plus hardware) consistent. In this case, the architecture documentation fulfills one of its purposes: to facilitate communication among the different stakeholders in development. We don’t claim that the whole architecture model should be created before implementation starts. Rather, the architecture documentation created before implementation should contain just enough to document and communicate the system aspects that are risky and expensive to change.

Using Adequate Tools and Methodologies Several approaches offer guidance for performing architecture activities. One such approach is the elicitation and documentation of architecture drivers using scenarios. Another is architecture evaluation using Fraunhofer’s RATE (Rapid Architecture Evaluation) and the Software Engineering Institute’s ATAM (Architecture Tradeoff

W W W. C O M P U T E R . O R G / S O F T W A R E

|

Analysis Meth­od). Both approaches offer great support and have been used around the world for both embedded systems and information systems. A strong tendency exists to associate specification of the architecture design with UML (www.uml.org) or SysML (Systems Modeling Language; www.sysml.org), which are strongly influenced by the computer science community. Unfortunately, these approaches by themselves aren’t specific enough for properly architecting embedded systems. But approaches exist that have been successfully used for this, which we describe next. AADL (Architecture Analysis and Design Language; www.aadl.info), which the Society for Automotive Engineers defined in 2012, offers tailored support for dependability aspects such as safety and security in architecture specifications.11 It also provides the means to capture architecture concepts from different abstraction levels. AADL has been widely used in the development of safety-critical systems—for example, by the SAVI (System Architecture Virtual Integration; http://savi.avsi .aero) initiative (which includes companies such as Airbus, Boeing, and Embraer), many other industries in Europe and Asia, and the US Army. SCADE is part of the SCADE Suite (www.esterel-technologies.com /products/scade-suite). It supports the specification of control flows and state machines for control logic, which are important architecture principles of safety-critical systems. SCADE has been successfully used in the aerospace, defense, and railways industries, such as in the design of safety-critical systems of the Airbus A380 and Boeing 787.

@ I E E E S O F T WA R E

EAST-ADL (Electronics Archi­ tecture and Software Technology—­ Architecture Description Language) is an architecture description language for automotive embedded systems.12 It was designed in the context of several European research projects. EAST-ADL defines architecture views, which support specifying the structure and behavior of vehicle features and their realization through software and hardware. It does this with precise traceability between the elements. The PREEvision (www.vector .com/preevision) tool also supports architecting automotive embedded systems, using the SPES (Software Platform Embedded Systems) 2020 methodology.5 Many of our customers from the transportation industry in Europe and the US have adopted PREEvision. We’ve seen how it helps architects with different educational backgrounds design complex embedded systems. The Fraunhofer Embedded Modeling Profile also centers on SPES 2020.13 It continues to evolve through its use in architecture consultancy services in various embedded domains such as the automotive domain, agriculture, avionics, and astrophysics. In the astrophysics domain, the architects are physicists who are using the profile to architect gamma-ray telescope controller systems’ software and hardware.14 The Fraunhofer Embedded Modeling Profile is available for the Enterprise Architect (www .sparxsystems.com) and MagicDraw (www.nomagic.com) tools. One front that still requires thorough investigation is the modeling of architectures of embedded systems that are tightly integrated into information systems—the cyber-physical systems we discussed earlier. Owing to the level of integration needed to

INDUSTRY PRACTITIONERS BECOMING ARCHITECTS— LOOKING FORWARD Before an industry practitioner is assigned the role of software architect, it’s important to identify whether that person has an architect’s required characteristics, such as those we discuss in the main article. For those who fit the profile, it’s crucial to tailor their capabilities with complementary education that addresses traditional architecture activities such as architecture construction and assessment. Regarding those who provide such coaching, it’s important to consider that many companies that offer architecture consultancy services have a hard time supporting embedded-systems companies. This is because these consultancy companies normally consist of computer scientists with little or almost no knowledge of architecting embedded systems. The need exists for professionals with knowledge of not only architecture but also embedded systems.

ensure that a cyber-physical system works properly, it’s necessary to represent concepts from both types of systems with the appropriate degree of abstraction. Methodologies exist that support the architecture activities of information and embedded systems, but they’re most likely disjoint and often conflict with each other. So, they must be evolved into a more cohesive methodology.

W

e’ve identified the need to address architecture in the formal education of not only computer science students but also students in the other domains most likely involved in embedded-­ system development, such as electrical and mechanical engineering. We’re not proposing how to update the university curriculum to integrate architecture-related courses; we simply wish to indicate measures that should be considered to educate embedded-software

architects. (For more on educating practitioners, see the sidebar.) First, universities should consider teaching software architecture in non-computer science courses covering such topics as electrical engineering, mechanical engineering, and mechatronics and in other courses that deal mainly with artifacts that have a close relationship with software. Second, computer science courses should emphasize the architecture discipline, not just molding computer scientists to think beyond the source code but also teaching them how to better architect software-based systems. We’re not talking about teaching design patterns, which is also a fundamental topic. Rather, we’re focusing on the architect’s role and on educating students in high-level architecture design and assessment. Finally, computer science courses should also teach embedded-system basics such as controllers, sensors, actuators, and buses. Someone might

NOVEMBER/DECEMBER 2016

|

I E E E S O F T WA R E

61

ABOUT THE AUTHORS

FOCUS: THE ROLE OF THE SOFTWARE ARCHITECT

PABLO OLIVEIRA ANTONINO is a senior engineer and

5.

project manager at the Fraunhofer Institute for Experimental Software Engineering. He constructs and analyzes architectures of dependable embedded systems for domains such as the automotive domain, agriculture, medical devices, and avionics. Antonino received a PhD in computer science from the University of Kaiserslautern. Contact him at pablo.antonino@ iese.fraunhofer.de.

6.

7. ANDREAS MORGENSTERN is an engineer at the Fraunhofer

Institute for Experimental Software Engineering. His research interests include behavior modeling in software architecture models and integrating formal methods such as static analysis into software engineering. Morgenstern received a PhD in computer science from the University of Kaiserslautern. Contact him at [email protected].

8.

9. THOMAS KUHN heads the Fraunhofer Institute for Experimental Software Engineering’s Embedded Software Engineering department. His research interests include the virtual development of embedded systems and the substantiating of architecture decisions on the basis of measureable facts obtained by architecture prototypes. Kuhn received a PhD in computer science from the University of Kaiserslautern. Contact him at thomas [email protected].

10.

11.

12.

claim that computer-engineering courses, not computer science courses, are the ones intended to prepare such professionals. If this is the case, computer-engineering courses should address software architecture principles, following the same recommendations we’ve given for electrical and mechanical engineering. Nevertheless, with the advent of cyber-physical systems, computer scientists who have at least a basic knowledge of embedded systems will have an advantage in industry over those lacking this knowledge. 62

I E E E S O F T WA R E

|

References 1. M. Shaw and P. Clements, “The Golden Age of Software Architecture,” IEEE Software, vol. 23, no. 2, 2006, pp. 31–39. 2. P. Kruchten, H. Obbink, and J. Stafford, “The Past, Present, and Future of Software Architecture,” IEEE Software, vol. 23, no. 2, 2006, pp. 22–30. 3. P. Liggesmeyer and M. Trapp, “Trends in Embedded Software Engineering,” IEEE Software, vol. 26, no. 3, 2009, pp. 19–25. 4. “Cyber-Physical Systems,” Program Solicitation NSF 16-549, US Nat’l

W W W. C O M P U T E R . O R G / S O F T W A R E

|

13.

14.

@ I E E E S O F T WA R E

Science Foundation, 2016; www.nsf .gov/pubs/2016/nsf16549/nsf16549.htm. K. Pohl et al., Model-Based Engineering of Embedded Systems: The SPES 2020 Methodology, Springer, 2012. P. Maeder et al., “Strategic Traceability for Safety-Critical Projects,” IEEE Software, vol. 30, no. 3, 2013, pp. 58–68. M. Fowler, Refactoring: Improving the Design of Existing Code, Addison-Wesley Longman, 1999. J. Garcia, D. Popescu, and G. Edwards, “Toward a Catalogue of Architectural Bad Smells,” Architectures for Adaptive Software Systems, LNCS 5581, Springer, 2009, pp. 146–162. E. Gamma et al., Design Patterns: Elements of Reusable ObjectOriented Software, Addison-Wesley Longman, 1995. P. Eeles and P. Cripps, The Process of Software Architecting, AddisonWesley Professional, 2010. Architecture Analysis & Design Language (AADL)—SAE AS 5506, SAE Int’l, 2012. P. Cuenot et al., “Managing Complexity of Automotive Electronics Using the EAST-ADL,” Proc. 12th IEEE Int’l Conf. Eng. Complex Computer Systems (ICECCS 07), 2007, pp. 353–358. T. Kuhn and P.O. Antonino, “ModelDriven Development of Embedded Systems,” Proc. 2014 Embedded Software Eng. Congress, 2014, pp. 47–53. I. Oya et al., “The Software Architecture to Control the Cherenkov Telescope Array,” Proc. SPIE, vol. 9913, 2016; http://proceedings .spiedigitallibrary.org/proceeding .aspx?articleid=2540562. Selected CS articles and columns are also available for free at http://ComputingNow.computer.org.

FOCUS: THE ROLE OF THE SOFTWARE ARCHITECT

The Architect’s Role in Practice From Decision Maker to Knowledge Manager? Rainer Weinreich and Iris Groher, Johannes Kepler University Linz

// Interviews with European and US software

Study Description

architects show not only a diverse practice of architecting but also the architect’s transformation from primary decision maker to coordinator, advisor, and knowledge manager. //

TRADITIONALLY, THE S ­ OFTWARE architect is viewed as the primary decision maker in architecture design. Seminal literature on software architecture describes the architect as responsible for designing, documenting, and leading software system construction.1,2 In a 2006 survey of practitioners with experience in architecture design, more than 80 percent of the participants reported that system design was their primary task. 3 Despite software architects’ central role as designers, it’s well known that their job is much more than 0740-7459/16/$33.00 © 2016 IEEE

To gain insights into the work of today’s software architects, we interviewed software architects, project leads, and senior developers with architecting responsibilities from 10 countries in Europe and the US. As you would expect, the resulting picture is diverse. However, despite differences in company sizes, domains, development processes, and architects’ tasks and roles, we saw an interesting shift in responsibilities in all the interviews. Software architects are transforming from primary decision makers to advisors, coordinators, and knowledge managers.

making technical decisions during a system’s initial design. Architects are involved in not only the early development phases but also system implementation and evolution, where they act as evaluators, extenders, and sustainers.4 In a survey on software architects’ duties and skills, Paul Clements and his colleagues identified more than 200 potential duties of software architects in requirements elicitation, design, implementation, evaluation, stakeholder communication, management, and education.5 Overall, this extensive set of duties requires a wide variety of skills.

In our interviews, 25 practitioners spoke openly about their architecting practices and experiences. The interviews lasted from approximately 30 minutes to more than one hour. In previous research, we analyzed the interviews regarding architectural decision making and influences on it.6,7 For this article, we reanalyzed the interview transcripts using qualitative data analysis. Besides influences on architecting, we looked at the software architect’s role in decision making, the role’s integration into organizational structures, and tools and practices used for managing architectural knowledge. The interviewees had more than 13 years of professional experience on average and had worked for more than 40 companies (most of them had worked in more than one company). Teams ranged from three to 200 developers; projects lasted from three months to 10 years. The interviewees worked in more than 20 areas and domains. Figure 1 shows the interviewees’ official roles in the projects they discussed.

NOVEMBER/DECEMBER 2016

|

IEEE SOFTWARE

63

FOCUS: THE ROLE OF THE SOFTWARE ARCHITECT

25

No. of people

20 15 10

17 14

5

9

5

0 Senior developer

Architect

4

2

2

Project Researcher Consultant Team lead manager

Other

FIGURE 1. The interviewees’ roles in projects. All the interviewees had architecting duties (duties related to architecture design, documentation, and management).

25

No. of people

20 15 10

24

19 12

5

11

11

10 7

0 Organizational Company factors size

Project factors

Business factors

Individual factors

Cultural factors

Technical factors

FIGURE 2. The interviewees mentioned these influences on architecting. The significant influence of organizational factors shows the close relationship between architecting and organization.

Architecting Is Diverse The interviews revealed that many factors influence the diverse ways architects work and how, when, and what they decide. The interviewees mentioned the following main potential influences (see Figure 2).6 Architecture and organization are closely related. So, it’s not surprising that established organizational 64

I E E E S O F T WA R E

|

structures and processes strongly influence architecting. Twenty-four interviewees (96 percent) mentioned organizational factors such as the established team organization (for example, global distribution of teams, team size, and external people), development processes and practices, and company standards. Nineteen interviewees (76 percent)

W W W. C O M P U T E R . O R G / S O F T W A R E

|

mentioned company size as an influence. This might be due to different organizational structures in smaller and larger companies. However, we couldn’t identify architecting practices that were obviously related to company size. (We discuss company size in more detail in the next section.) Twelve interviewees (48 percent) mentioned project factors such as the kind of project (for example, open source project or platform project). Eleven interviewees (44 percent) mentioned individual factors such as personal preferences, evangelism, passion, skills, education, and experience. Eleven interviewees (44 percent) mentioned business factors related to economic considerations. Companies in the same business domain might exhibit different organizational structures and processes for architecting, owing to different cultures or individual preferences and experience. But the domain still influences architecting. For example, participants from the health domain reported strictly planned processes with explicit requirements documentation to address security and safety issues. Participants from the banking domain mentioned the need to address regulatory requirements. Other business-related factors were the company’s business model, cost, risk, time to market, and business strategy. For example, in a company doing mainly custom development that competed with companies selling out-of-the-box solutions, cost analysis was integrated with architecting. Ten interviewees (40 percent) mentioned cultural factors such as company philosophy (for example, consensus driven, democratic, learning, dogmatic, or document driven).

@ I E E E S O F T WA R E

TABLE 1

The organizational models in our study. Model

The architect’s roles and responsibilities

Plan-driven development

Architects took a plan-driven approach adapted to the company’s context. The architecting roles and tasks were clearly defined.

Agile development with one team

There were no specific architecting roles. Development employed group decisions.

Agile development with architects as specialists

Architects were specialists and supported teams in their decision making.

Agile teams and cross-functional teams

Architects from the architecture team were also agile-development team members. They handled knowledge transfer and coordination.

Coordinated agile development with an escalation strategy

This model employed a hierarchical organization related to applications and domains. Different levels had specific architects and decision makers (for example, application architects and business stream architects). Global decisions spanned multiple teams and organizational levels.

Autonomous plan-driven or agile development with company-wide architectural guidance

Teams independently defined the development process and methodologies they used. Company or division architects approved the decisions to ensure they adhered to company-wide architecture strategies and guidelines.

Finally, seven interviewees (28 percent) mentioned technical factors (constraints imposed by technologies and standards).

Architecting and Organization Approximately 80 percent of the interviewees worked with agile processes, and 20 percent worked with plan-driven processes. The latter processes typically involved waterfallbased methods tailored to the organizational context. We found agile practices in larger companies and plan-driven processes in smaller companies, and team organization wasn’t related to company size. This result becomes even more apparent when we look at how the interviewees were distributed over company sizes. Approximately 30 percent worked in small companies (up to 50 employees), approximately 20 percent worked in mediumsized companies (up to 250 employees), and approximately 50 percent worked in large companies (up to several thousand employees).

Table 1 lists the organizational models with the architects’ related roles and responsibilities. Small companies often had one agile team. These teams usually had no explicit architectural role with defi ned responsibilities and tasks. Two interviewees, who had many years’ experience in multiple companies, had never encountered a dedicated architect in such teams. But sometimes specific team members took the lead on architectural decisions (aside from being developers). The role of architect was attributed to specialists in specific areas (for example, UIs, databases, and security) and technologies (for example, a specific middleware technology). Organizations with multiple agile teams had different additional organizational structures for crossteam coordination. One variant was the combination of agile and crossfunctional teams, which involved dedicated architecture teams. Architects from the architecture teams were also members of development teams and used their affi liation with

the architecture team for cross-team coordination and guidance. They ensured that the teams followed agreed-on strategies and guidelines, and they reported problems and issues of a more global scope back to the architecture team. In another variant, some companies built additional hierarchical structures on top of the agile development teams. Decisions of a more global scope might have been escalated to the responsible architects at higher organizational levels—for example, an application architect, a stream architect, or fi nally a chief technical architect. This approach represented a combination of mostly independent agile development teams and organizational structures and roles with clear responsibilities helping to coordinate and support the development teams. Finally, in some organizations, the development teams were largely autonomous and could freely decide which development process to follow, whether agile or plan-driven. These teams discussed decisions

NOVEMBER/DECEMBER 2016

|

I E E E S O F T WA R E

65

FOCUS: THE ROLE OF THE SOFTWARE ARCHITECT

with architects outside their team to ensure that the design followed company-­ wide API rules or service interaction strategies. The teams proposed a solution; the architects gave them feedback. In one case, architects also organized lunch meetings in which they presented their envisioned roadmap to the developers.

The Architect as Decision Maker Decision making is arguably the major task of software architecting, or as Philippe Kruchten put it, “Architecting is making decisions.”8 Decisions’ central role is reflected in definitions of software architecture (for example, architecture is the set of design decisions9,10) and in software architecture research, which has shifted its focus from the resulting design to the process of architecting and the rationale behind decisions. So, you might assume that an architect’s primary task is making design decisions. However, this wasn’t the case in our study. Of course, decision making is still the essence of architecting, but it’s interesting to see who makes those decisions. In our study, this task was mainly a group effort, which aligns with other studies.11 Whereas all the interviewees reported that individual developers made decisions with a local scope, the whole team typically discussed decisions with a global scope until it reached consensus. Indeed, 17 interviewees (68 percent) described architecting as a group effort, and three interviewees (12 percent) stated that teams primarily made the decisions, with architects making only some decisions. So, 20 interviewees (80 percent) reported that the architect wasn’t the final decision maker. In settings with cross-functional architecture teams, architects often didn’t even have the power to make decisions. 66

I E E E S O F T WA R E

|

Consensus-driven decision making occurred in both agile and plandriven development. In agile projects, discussions about architectural issues were often ad hoc (reported by 28 percent of the interviewees), issued by a developer as part of the daily stand-up meeting. One interviewee reported that a problem might have led to a “deep dive” with the whole team until it had explored the problem sufficiently to make a decision. Another interviewee reported that twice a week, people met to report on features on which they were working and to ask for feedback. In plan-driven processes, architecting activities typically followed the defined plan, but architectural issues were still often decided by consensus. Only when the team couldn’t reach consensus did the architect or team lead make the decision. As one interviewee said, “Sometimes someone has to take responsibility.” Some interviewees reported that the architect was responsible for certain types of decisions. For example, one interviewee reported that the team generally made the decisions but that the platform architect made the platform decisions. Another interviewee stated that architects decided on wide API rules and global division-­ service interaction policies. In both agile and plan-driven processes, teams consulted people from within or outside the team during decision making, and these people were often called architects. For specific problems, teams consulted specialists such as database architects and UI architects. If the team was embedded in a larger organizational structure, it consulted application or system architects on how the proposed design fit in this larger context. These architects were specialists in a particular domain (for

W W W. C O M P U T E R . O R G / S O F T W A R E

|

example, accounting or security) or specific infrastructure (for example, the service or network infrastructure). In 16 percent of the cases, organizational structures were in place to escalate a problem to higher organizational (cross-team) levels until a decision could be made.

The Architect as Knowledge Manager Besides providing advice to other team members, the architects in our study • guided team members through company-wide standards and constraints, • identified important architectural decisions (made by others), • asked developers to document those decisions, • collected and managed domainspecific patterns, • transferred knowledge to development teams, • collected and distributed important generic knowledge (for example, pattern catalogs and books), • documented principles and best practices, • explored technologies, and • explored potential solutions. The interviewees reported additional duties such as managing the development stack and reviewing architectural designs. In terms of managing architectural knowledge, the focus clearly seemed to be on collecting, providing, and transferring generic knowledge such as principles, patterns, and guidelines (reported by 68 percent of the interview partners). All the interviewees agreed on the importance of documenting project-specific decisions. However,

@ I E E E S O F T WA R E

the lack of available information on decisions and their rationale was still a problem, especially in teams with frequently changing personnel, in long-running projects, and in takeover and buyout scenarios. Knowledge vaporization affected 72 percent of the interviewees, and 20 percent had forgotten decisions they had made themselves. We found statements such as “We often miss why things are done,” “Often only the end result is documented,” and “We need to work in alignment with existing decisions.” The main reasons for the lack of this information were the costs involved in capturing it (reported by 40 percent of the interviewees) and the difficulty determining that decisions had been made in the first place (reported by 16 percent). One interviewee stated, “During the design process, decisions seem obvious and alternatives seem stupid, so documenting them is senseless at this point and very costly in the long term.” Another interviewee stated, “In order to document a decision, you have to realize that you are making a decision. Often you do not do that because you do not even know there are alternatives.”

Documenting Decisions and Their Rationale To capture project-specific decisions and their rationale, the interviewees used the following practices and tools.

On-Demand Documentation Interviewees mentioned the practice of creating documentation only when it’s needed—specifically, when someone asks for it more than once. This was especially true in agile teams that usually shared knowledge through communication.

Value-Based Documentation As one interviewee stated, “Ask for every piece of documentation, what is the value for whom?” A simple indicator of whether something is valuable to other people is that they keep asking for it. The recurrence of specific questions also indicates the need to keep documentation up to date. Another interesting take on value-based documentation concerns decision making itself. One professional stated, “Of course, we are documenting alternatives and why we make the final decision, but it’s not to document them. We do that to make the decisions. We do not write the documents for the purpose of the document. There must be a value in producing that.” This highlights an important point: documenting the various options and arguments during decision making actually supports, and might even be necessary for, decision making. The resulting documentation is more a byproduct of decision making than the product of a separate documentation activity.

The Truth Is in the Code Several interviewees emphasized code’s importance as the central location for documentation. A member of an agile team stated, “The internal architecture documentation is always the code. We do not write any other documentation than code. Everything we document is documented in code in terms of comments.” Code often seemed to be the source of trust, which was enriched with comments and tags (for structured documentation). Additional practices were links from the code to discussions in issue management systems, links to external documentation such as the patterns applied, and the reverse

engineering of documentation from code. Code-related documentation and reviews were mentioned by members of both small and large organizations.

Identifying Decisions and the Need for Documentation Interviewees also used source code management to identify decisions or the need for their documentation. One interviewee regularly used identified source code changes with no related documentation changes to initiate a discussion with the team on potential decisions and their documentation. Another interviewee used retrospectives in an agile-­development process to systematically identify and discuss the decisions made in the last iteration.

Maintaining Documentation Although some companies used the techniques we just outlined to keep their architecture documentation up to date, outdated documentation was the norm. Outdated documentation can paint the wrong picture of the actual situation. Interviewees mentioned that a simple, effective way to deal with this is to provide the creation date and creator for a particular kind of information. This way, people can judge the information’s relevance and value and acquire further information if necessary.

Tools None of the interviewees reported using knowledge or decision management tools to manage project-related architectural knowledge. In­­stead, they mentioned text documents (64 percent), source code (60 percent), wikis (56 percent), project diaries and meeting minutes (40 percent), and issue management systems (20 percent).

NOVEMBER/DECEMBER 2016

|

I E E E S O F T WA R E

67

FOCUS: THE ROLE OF THE SOFTWARE ARCHITECT

THE SOFTWARE ARCHITECT: QUO VADIS? Future architectural decisions will draw heavily on past architectural decisions. This makes effective knowledge management, including that of past decisions, indispensable. Architects already manage and provide generic knowledge such as patterns and guidelines. They’ve also developed a set of best practices for capturing project-specific knowledge such as past architectural decisions. Future challenges include managing this knowledge over time and turning project-specific knowledge quickly into domain-specific generic knowledge and vice versa. At the same time, software development is increasingly organized in autonomous teams in which everyone, instead of a single person, is responsible for architecture design. We imagine the software architect’s main role to be the central knowledge hub in this new era of software development.

Decisions with a local scope were often documented in the code and in issue or requirements management systems. Decisions with a global scope were documented in project diaries, meeting minutes, and wikis. Documents were usually stored in document management systems and were fully searchable. The interviewees regarded documenting decisions in the issue or requirements management system as beneficial because people who are searching for a decision tend to think about how a requirement has been addressed. In cases in which projects were often presented externally, presentations were a good information source that was frequently kept up to date.

S

o, are software architects still the main decision makers? From our interviews, we believe the answer is both yes and no. Yes, in that sometimes organizational structures were in place in which the architect still made the final decision. No, in that architecting was typically a group effort. 68

I E E E S O F T WA R E

|

In many cases, the architect was an advisor, a central coordinator, and a knowledge manager. Some interviewees reported positive aspects of this new central role, such as better education of team members due to knowledge transfer and less risk of the architect being the bottleneck in decision making. But can we really claim that architects are shifting from decision makers to knowledge managers? Our study is one of the largest interview studies about software architecture.12 Still, qualitative studies such as ours are subject to author interpretation, and we can’t provide enough evidence that this shift is global. Nevertheless, our study clearly shows architecture knowledge management’s growing importance. Architects are already dealing with this situation and have developed best practices for capturing and maintaining architectural knowledge. However, it’s also evident that both researchers and practitioners must provide better support to help architects deal with these additional challenges (for more on this, see the sidebar). We need to improve

W W W. C O M P U T E R . O R G / S O F T W A R E

|

knowledge management infrastructure and education. We especially need to train architects to effectively capture and manage architectural knowledge and distribute it throughout an organization. We also need to better investigate the interplay between knowledge management and architectural decision making and how to establish these responsibilities in organizational structures, taking into account the context and other influences. References 1. N. Rozanski and E. Woods, Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives, Addison-Wesley, 2011. 2. L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice, Addison-Wesley Professional, 2012. 3. A. Tang et al., “A Survey of Architecture Design Rationale,” J. Systems and Software, vol. 79, no. 12, 2006, pp. 1792–1804. 4. J. Klein, “What Makes an Architect Successful?,” IEEE Software, vol. 33, no. 1, 2016, pp. 20–22. 5. P. Clements et al., “The Duties, Skills, and Knowledge of Software Architects,” Proc. 2007 Working IEEE/IFIP Conf. Software Architecture (WICSA 07), 2007, p. 20. 6. I. Groher and R. Weinreich, “A Study on Architectural Decision-Making in Context,” Proc. 2015 Working IEEE/IFIP Conf. Software Architecture (WICSA 15), 2015, pp. 11–20. 7. R. Weinreich, I. Groher, and C. Miesbauer, “An Expert Survey on Kinds, Influence Factors and Documentation of Design Decisions in Practice,” Future Generation Computer Systems, June 2015, pp. 145–160. 8. P. Kruchten, “Where Did All This Good Architectural Knowledge Go?,” Software Architecture, LNCS 6285, Springer, 2010, pp. 5–6.

@ I E E E S O F T WA R E

ABOUT THE AUTHORS

9. J. Bosch, “Software Architecture: The Next Step,” Software Architecture, LNCS 3047, 2004, pp. 194–199. 10. P. Kruchten, The Rational Unifi ed Process: An Introduction, AddisonWesley Professional, 2000. 11. D. Tofan, M. Galster, and P. Avgeriou, “Diffi culty of Architectural Decisions—a Survey with Professional Architects,” Software Architecture, LNCS 7957, 2013, pp. 192–199. 12. M. Galster and D. Weyns, “Empirical Research in Software Architecture: How Far Have We Come?,” Proc. 2016 Working IEEE/IFIP Conf. Software Architecture (WICSA 16), 2016, pp. 11–20.

RAINER WEINREICH is an associate professor in the Department of Business Informatics—Software Engineering at Johannes Kepler University Linz. His research interests include software architecture engineering and software architecture knowledge management. Weinreich received a PhD in computer science from Johannes Kepler University Linz. Contact him at [email protected].

IRIS GROHER is an assistant professor in the Department

of Business Informatics—Software Engineering at Johannes Kepler University Linz. Her research interests include software architecture engineering and software product line engineering. Groher received a PhD in computer science from Johannes Kepler University Linz. Contact her at [email protected].

IEEE Computer Society | Software Engineering Institute

Watts S. Humphrey Software Process Achievement Award Nomination Deadline: October 15, 2016 Do you know a person or team that deserves recognition for their process-improvement activities? The IEEE Computer Society/Software Engineering Institute Watts S. Humphrey Software Process Achievement Award is presented to recognize outstanding achievements in improving the ability of an organization to create and evolve software. The award may be presented to an individual or a group, and the achievements can be the result of any type of process improvement activity. To nominate an individual or group for a Humphrey SPA Award, please visit computer.org/portal/web/awards/spa

NOVEMBER/DECEMBER 2016

|

I E E E S O F T WA R E

69

FOCUS: THE ROLE OF THE SOFTWARE ARCHITECT

The Architect’s Role in Community Shepherding Damian A. Tamburri, Politecnico di Milano Rick Kazman, University of Hawaii Hamed Fahimi, CGI

// Community shepherds guide development projects’ social and organizational structures, look for early warning signs of trouble, and help mitigate that trouble. Knowing community smells—ways in which software communities might be “buggy”—can help with this. //

cover image here

SOFTWARE ARCHITECTS DON’T just design architecture components or champion architecture qualities; they often must guide and harmonize the entire community of project stakeholders. The community-­shepherding aspects of the architect’s role have been gaining attention, given the increasing importance of complex “organizational rewiring” scenarios such 70

IEEE SOFTWARE

|

as DevOps, open source strategies, transitions to agile development, and corporate acquisitions. To help architects in their role as community shepherds, we pre­ sent guidance on how to tell when a community has problems and what to do about those problems. We also provide an overview of community types.

PUBLISHED BY THE IEEE COMPUTER SOCIETY

Interior Design for Software Architects What do you do when you want to reorganize the furniture in your room? You take pencil and paper and draw a blueprint of the room and its elements (the desk and wardrobes, that “exotic” table your partner got who-knows-where, and so on), including the most important properties (size, shape, fragility, and so on). Now let’s say your partner wants to keep that exotic table where it is without even removing the dreadful tapestry on top of it. What do you do? You get some counseling. Well, the same story happens in software architecture practice.1 Architects often must act as key community figures or counselors who bridge the gap between the development organization, including its subgroups, and the software architecture, including its properties and implementation details. Consequently, those software architectures (the blueprints in this case) are often augmented with views that express authority, 2 task divisions, elements, relations, and more. These characteristics reflect organizational and community types known to organizations and social-network researchers.3,4 (A community type is a social network in which social or organizational characteristics are constantly evident.3 For example, a project team is small [size], cross-functional [average cognitive distance], and time-bound [duration].) Returning to our room: Counseling isn’t going well, but you love your partner and decide to give in on the table—but you never forget. If this happens regularly, tension or even defiance might ensue. Well, the same story happens in software architecture practice.5 Architects have often reported trouble 0740-7459/16/$33.00 © 2016 IEEE

while participating in “smelly” (suboptimal, either organizationally or technically) communities. They’ve had to take on the role of intermediaries of the entire community. This has involved proposing mitigations for good-then-bad implementations that incur technical debt6 or goodthen-bad organizational and social decisions (for example, releasing a critical component as open source, which then incurs social debt 5). Returning to our story: Imagine you want to change not just the room but the type of house or even its location. The simple room blueprint won’t be enough, but it’s all you have as a starting point for planning the move. Well, the same story happens with software architecture practitioners.2 Software architects often must play a key role in organizational- or technical-­ change scenarios—for example, organizational mergers, outsourcing, process changes (such as shifting to Scrum or DevOps), or adopting a new technology stack. Such scenarios require that architects • adapt both the organization and architecture to accommodate the changes; • continuously change the organization and architecture to keep the two aligned; and • understand and mediate existing and new requirements (for example, continuous integration), stakeholders (for example, infrastructure engineers), and concerns (for example, integration speed and test coverage). In these scenarios, architects must strike a balance between community and architecture—for example, by adapting their architecture to support continuous improvement

while molding a community that welcomes a DevOps strategy. In these circumstances, the architect’s role is critical in balancing proposed technical solutions against challenging social and organizational issues: community smells 7,8 —ways in which software communities might be “buggy.” So, how do architects cope with their (largely implicit) role as community managers, counselors, and shepherds? Little literature or curriculum exists to prepare them for the strain of this role. Shepherding involves creating effective synergies

organizations of varying sizes. One organization was one of the world’s largest IT services firms, with more than 65,000 employees. Another was a medium-size software engineering consulting firm from Italy with more than 50 employees. Others were agile small-to-medium enterprises with dozens of employees who combined software architecting with community contributions. This study had three goals. First, we wanted to understand how software architects can know if their community smells. Toward that end, we discovered 12 community smells.

We wanted to understand how software architects can know if their community smells. between people such that development community goals are aligned with good-quality software architectures, their elements, and their properties. There are no proven techniques architects can employ to deal with their job’s social and organizational aspects. Most of their efficacy in organizational-change scenarios depends on their personal experience. Furthermore, this efficacy is even more critical with the IT industry’s increasing interest in the organizational-rewiring scenarios we mentioned before.

Our Study To ease architects’ lives and provide them strategies to cope with their role of community shepherd, we conducted an industrial study employing interviews, focus groups, and workshops with 51 software engineering professionals from four

These smells are recurrent—each was reported 10 times or more in our study, and architects will likely have to cope with them. Second, we wanted to identify what software architects should do if their community smells. So, we elicited and documented possible strategies to address the smells. Finally, we wanted to identify common community types and their features because these provide patterns for structuring a software engineering community. We indicated each feature’s importance to each community type3 because this helps architects determine how best to shepherd those communities.1

Know Your Community Smells Much like code smells, community smells are initially hunches that something might be going wrong.

NOVEMBER/DECEMBER 2016

|

I E E E S O F T WA R E

71

TABLE 1

FOCUS: THE ROLE OF THE SOFTWARE ARCHITECT

Community smells and what software architects should know about them. Smell*

Description

Context

Cause

Consequences

Time Warp (27)

A change in organizational structure and process that leads people to wrongly assume that communication will take less time and that explicit additional coordination isn’t needed

• Formal networks • Working groups • Communities of practice • Formal groups

Experience diversity

• Low software architecture quality • Malfunctioning software or code smells • Losing face in the community • Unsolved operations issues • Unsatisfied customers

Cognitive Distance (24)

The distance developers perceive on the physical, technical, social, and cultural levels regarding peers with considerable background differences10

• Formal networks • Working groups • Communities of practice • Formal groups • Project teams

Experience diversity

• Wasted time • Pitting newbies versus experts • Faulty or smelly code • Additional development costs • Wasted operations resources • Lack of an optimal understanding across different operations areas • Mistrust across the development network • Misinterpretation of expectations

Newbie FreeRiding (24)

Newcomers being left to themselves regarding understanding what to do and for whom, with the consequent freeriding of older employees (that is, the economic free-rider problem applied to software engineering)

• Formal groups • Project teams

—

• High work pressure • Irritation • Demotivation of non-senior members

Power Distance (24)

The distance that less powerful or less responsible members of a software development community perceive, accept, or expect with power holders

• Formal networks • Communities of practice

Lack of architecture knowledge sharing

• Additional project costs • Financial loss • Lost bids

Disengagement (24)

Thinking the product is mature enough and sending it to operations even though it might not be ready

• Communities of practice • Formal networks

• Lack of engagement in development • Lack of curiosity

• Missing software development contextual information • Wild assumptions

Priggish Members (13)

Demanding of others (for example, operations) pointlessly precise conformity or exaggerated propriety, especially in a selfrighteous or irritating manner

Communities of practice

—

• Additional project costs • Frustrated team members

The software development community “works,” but there’s smoke on the horizon, warning of problems arising in the near future. The architect is increasingly the one who uncovers community smells and associated social debt, just as he or she 72

I E E E S O F T WA R E

|

deals with code smells and technical (and architectural) debt.9 Table 1 showcases the community smells we found in our study, focusing on • previously unreported smells and

W W W. C O M P U T E R . O R G / S O F T W A R E

|

• smells directly related to architectures and the role of architects. For example, Table 1’s first row describes the Time Warp smell, which involves wrong assumptions

@ I E E E S O F T WA R E

TABLE 1 CONT.

Community smells and what software architects should know about them. Smell*

Description

Context

Cause

Consequences

Cookbook Development (13)

Developers who are stuck in their ways and who refuse innovative ideas or ways of working (for example, agile methods or DevOps)

Communities of practice

Thinking in an old framework—for example, the waterfall model

• Mismatched expectations between the customer and the rest of the community

Institutional Isomorphism (11)

The similarity of the processes or structure of one subcommunity to those of another, whether the result of imitation or independent development under similar constraints

• Formal networks • Communities of practice • Formal groups

• Excessive conformity to standards • Lack of innovation • Using a formal structure to achieve community goals • Rigid thinking from different parts of the community

• A negative impact on team spirit • A less flexible or static product • Lack of innovation • Stagnation • Lack of communication or collaboration

HyperCommunity (14)

A hyperconnected community that’s sensible of groupthink but also influences its subcommunities

• Communities of practice • Formal networks

—

• Increased turbulence • Buggy software

DevOps Clash (29)

Clashes in the mix between development and operations from multiple geographical locations, with contractual obligations to either development or operations

• Formal networks • Formal groups

Geographic dispersion

• Increased project costs • Lack of trust-building • The inability to bridge between different thought worlds across development and operations • “Stickiness” of knowledge transfer • Clashes between the development and operations cultures • Slower development • Ineffective operations

Informality Excess (10)

Excessive informality due to the relative absence of information management and control protocols

Project teams

—

• Low accountability of both development and operations staff • Information spillover

Unlearning (12)

A new technological or organizational advancement or best practice (for example, as part of training courses) that becomes infeasible when shared with older members

• Project teams • Formal groups

Experience diversity

• Lack of engagement • Gradual loss of the new knowledge or best practice

* The numbers in parentheses indicate the number of times that smell appeared in our study.

regarding the development and operations time frames after an organizational change—for example, outsourcing architecture elements. According to our data, Time Warp

likely occurs in four community types: formal networks, working groups, communities of practice, and formal groups. These four types share key features that might require

additional attention during organizational changes; we discuss these features in more detail later. Moreover, we found that Time Warp correlates with high experience

NOVEMBER/DECEMBER 2016

|

I E E E S O F T WA R E

73

FOCUS: THE ROLE OF THE SOFTWARE ARCHITECT

diversity across community members; this diversity might require the architect’s attention. This was the case in seven instances of Time Warp (approximately 26 percent of all occurrences of the smell). Finally, Time Warp leads to a hastily developed architecture, resulting in poor design, and hastily developed code, resulting in code smells. To give you an additional whiff of community smells and their relation to software architecture, let’s return to our story. You’re moving to a new town, and you hire a decorator to arrange your furniture. The Cognitive Distance smell represents the distance (in assumptions, attitudes, emotions, and knowledge) you perceive between yourself and your decorator (who finds your furniture distasteful). In a software development community, Cognitive Distance refers to the differences in technical knowledge and skills— and hence norms and ­assumptions— among developers. The Newbie Free-Riding smell refers to when your decorator is a novice and hasn’t received sufficient details about your furniture or decoration tastes. Similarly, during organizational rewiring, newcomers might suffer from a lack of awareness of project or architecture norms.11 So, additional time and effort must be invested in disseminating such knowledge. Moreover, remember when you were a young developer looking up to veteran colleagues, who made all the decisions without consulting you (or, at times, without even communicating them to you)? Well, the same story happens in software architecture practice. Researchers have studied how architects’ loneliness can disrupt software processes11 and decrease architecture 74

I E E E S O F T WA R E

|

quality. 5 This is the effect of the Power Distance smell. Architects can combat Power Distance’s negative consequences by reaching out to their communities— for example, by building architecture boards.7 Or, architects can rearrange architecture elements and their responsibilities to redistribute authority more homogeneously—for example, by increasing modularity and allocating new, smaller modules to smaller teams. Note here the architect’s crucial role in designing and shepherding the community, the architecture, or both to achieve better alignment. These community smells provide at least two benefits. First, they’re starting points for you to study. They help refine your understanding of the architect’s role in community shepherding. Second, they’re hints for caution that should be added to a software architect’s handbook.

Architects ... React! Table 2 presents the mitigations the architects in our study used to successfully tackle the community smells in Table 1. To give you a taste of these mitigations, we illustrate several examples from our study. These mitigations can help software architects tackle potentially hazardous circumstances arising around community smells. Furthermore, architects can proactively adopt these approaches to avoid the conditions in which smells emerge.

Buddy Pairing Our evidence suggests that modularizing architecture elements such that they can be arranged over multiple remote sites should engender the creation of boundary

W W W. C O M P U T E R . O R G / S O F T W A R E

|

spanners—people whose architecture knowledge spans not only development (or operations) sites but also components.7 For example, in our study, the architecture in three projects was modularized into (at most) two essential components per site. People were then bound in pairs across components and sites. These work buddies regularly updated each other on progress, incidents, or similar architecture knowledge. This architecture-based buddy-­pairing strat­egy aimed to mitigate Cognitive Distance, with positive results in all three cases, irrespective of the software process.

Sociotechnical-Risks Engineering Also, our evidence suggests that software architecture can be designed defensively from a sociotechnical perspective. Consequently, critical architecture elements remain tightly controlled by an organization and loosely coupled with respect to “outsiders.” That organization can then dedicate resources to mitigating architecture risks associated with these critical elements. This is particularly appropriate for architecting for development in networked organizations. 2 Some of our study participants adopted this architecture-based sociotechnical-­risk-engineering strategy to mitigate Time Warp. For example, seven interviewees in three organizations reported on four projects in which a (once colocated) software project became distributed and their organization changed to a (more expensive) bus-based architecture. The aim was to retain control over the bus while partner sites developed extensions on top of the bus. This eliminated Time Warp, which had been reported in dozens of prior projects that hadn’t adopted this strategy.

@ I E E E S O F T WA R E

TABLE 2

Smells and mitigations. Smell

Mitigation

Time Warp

Better syncing of coordination and communication of architecture decisions, and better time estimation or evidence-based scheduling Architect-as-a-coach Devoting more resources to risk engineering

Cognitive Distance

Professional communication intermediaries Designing an architecture on the basis of the perceived cognitive distance Stimulating engagement in newcomers, and designing architecture to accommodate buddy pairing Architecture knowledge exchange through redocumentation, workshops, and presentations Architect-as-a-coach Cross-functional and community-wide review of code, designs, and operations procedures

Newbie Free-Riding

Coordination management and engagement creation Architect-as-a-coach Explicit empowerment of architecture decision changes Organizational monitoring—for example, anonymous mood polling

Power Distance

—

Disengagement

A DevOps shift-left approach to address issues earlier during development, and having operations staff also be developers Designing a people-oriented rather than feature-oriented architecture

Priggish Members

Harmonizing responsibilities, and using Scrum and agile methods

Cookbook Development

Using agile methods—in particular, employing the protecting and interface role of Scrum master, who communicates the customer organization’s demands to the development and operations teams Expectation management, and managers and architects using knowledge brokers to disseminate and oversee expectations

Institutional Isomorphism

Open communication and informality, and model-based mediation of knowledge Daily stand-ups, and keeping track of actions, agreements, and expectations through work-division artifacts

Hyper-Community

Architect-as-a-coach Inciting doubt through discussion and reverse logic

DevOps Clash

Community-wide engagement, including operations staff, clients, and user panels Nearshoring (For example, Poland is closer to the Netherlands than China is.) Standardization of software design and implementation, then separation between development and operations, and then operations offshoring Knowledge brokers, and a new service or community coordinator for efficient working

Informality Excess

—

Unlearning

Ad hoc individual training for the more experienced developers A more active organizational approach and resources for architecture knowledge sharing



NOVEMBER/DECEMBER 2016

|

I E E E S O F T WA R E

75

FOCUS: THE ROLE OF THE SOFTWARE ARCHITECT

TABLE 3

Community types and their features.*

Community of practice

Informal network

Formal network

Informal community

Network of practice

Working group

Project team

Formal group

Problem-solving community

Learning community

Social network site

Knowledge community

Strategic community

Community type

Community structure

High

High

High

High

High

High

High

High

High

High

High

High

High

Situatedness

High

Low

Low

Low

Low

High

High

High

Low

Low

Low

Low

Low

Dispersion

Low

High

High

High

High

Low

Low

Low

High

Low

Low

High

High

Problem solving

Low

Low

Low

Low

Low

High

High

High

High

Low

Low

Low

High

Informality

High

High

Low

Low

High

High

High

High

High

High

Low

High

Low

Formality

Low

Low

High

Low

Low

High

High

High

Low

Low

Low

High

High

Engagement

High

High

Low

High

Low

High

High

Low

High

High

Low

Low

Low

Cohesion

Low

Low

High

Low

Low

High

High

Low

Low

Low

Low

Low

Low

Duration

High

High

High

High

High

High

Low

High

High

High

Low

Low

High

ROI tracking

Low

Low

Low

Low

Low

Low

High

Low

Low

Low

Low

Low

High

Governance

Low

Low

High

Low

Low

High

High

High

Low

Low

Low

Low

High

Culture

Low

Low

Low

Low

Low

High

Low

Low

High

High

Low

Low

Low

Visibility

Low

Low

Low

Low

Low

Low

Low

Low

Low

Low

Low

High

Low

Feature

* Low means the feature is unimportant or irrelevant; high means the feature is salient and primary. ROI means return on investment.

Mood Polling Moreover, our evidence suggests that constantly monitoring progress and organizational procedures on the basis of architecture elements can reduce the proliferation of socio­ technical problems or community smells.5,7 Any problems or smells will be reported as they emerge. For example, some of our study participants used architecture-based anonymous mood polling to mitigate Newbie Free-Riding. This provided two benefits: • Everyone could share their mood regarding the organizational 76

I E E E S O F T WA R E

|

scenario and its mapping onto architecture elements. • Architects could make further design decisions for improved organizational coordination— for example, by increasing modularization and empow­ ering developers to deal with “bad mood” architecture elements. This mitigation revealed both community and technical smells more than 20 times across several projects. Remarkably, we’ve seen start-ups emerge that aim to mitigate Newbie Free-Riding; examples include Celkee

W W W. C O M P U T E R . O R G / S O F T W A R E

|

(www.celkee.com) and HappyOrNot (www.happy-or-not.com/en).

Shift Left Finally, our evidence suggests it’s not enough to address organiza­ tional and operational concerns (for example, infrastructure configura­ tion) sooner, nor is it enough to use architectures just for division of work. The architecture must take into account key organizational con­ cerns (discussed in the next section) whose counter-effects would nor­ mally become apparent during deliv­ ery (such as handover procedures or developer-­to-operator coupling).

@ I E E E S O F T WA R E

For example, five projects in our study employed an architecturebased DevOps shift-left strategy.12 Such a strategy shifts organizational and operational concerns (for example, development-to-operations team mixing) to earlier (“left”) in the life cycle toward architecting and development. This approach effectively mitigated Disengagement, which was decreasing developer and operations staff engagement and limiting their interactions over joint operational procedures. With this strategy, the organizational structures were redesigned, creating a small DevOps team (including both development and operations people) for each architecture element.

Community Types Explained Given that the community types and their features might “bug” architectures and the architects’ efforts to communicate and maintain them, Table 3 lists 13 key community types investigated in social-network and organizational research, focusing on their features for comparison. The table indicates the features’ importance to the community types. Notably, many of these types are the ones in which we observed community smells. These community types and their features provide patterns for structuring (and shepherding) a software engineering community. For example, formality might be a primary characteristic in scenarios with well-defined rules and regulations, typically dictated by corporate governance. Conversely, informality or engagement might occur primarily in communities relying on informal communication—for example, open source communities. Moreover, cohesion and duration are primarily in

PURPOSE: The IEEE Computer Society is the world’s largest association of computing professionals and is the leading provider of technical information in the field. MEMBERSHIP: Members receive the monthly magazine Computer, discounts, and opportunities to serve (all activities are led by volunteer members). Membership is open to all IEEE members, affiliate society members, and others interested in the computer field. OMBUDSMAN: Email [email protected]. COMPUTER SOCIETY WEBSITE: www.computer.org Next Board Meeting: 13–14 November 2016, New Brunswick, NJ, USA

EXECUTIVE COMMITTEE President: Roger U. Fujii President-Elect: Jean-Luc Gaudiot; Past President: Thomas M. Conte; Secretary: Gregory T. Byrd; Treasurer: Forrest Shull; VP Member & Geographic Activities: Nita K. Patel; VP, Publications: David S. Ebert; VP, Professional & Educational Activities: Andy T. Chen; VP, Standards Activities: Mark Paulk; VP, Technical & Conference Activities: Hausi A. Müller; 2016 IEEE Director & Delegate Division VIII: John W. Walz; 2016 IEEE Director & Delegate Division V: Harold Javid; 2017 IEEE Director-Elect & Delegate Division V: Dejan S. Milojičić

BOARD OF GOVERNORS Term Expriring 2016: David A. Bader, Pierre Bourque, Dennis J. Frailey, Jill I. Gostin, Atsuhiro Goto, Rob Reilly, Christina M. Schober Term Expiring 2017: David Lomet, Ming C. Lin, Gregory T. Byrd, Alfredo Benso, Forrest Shull, Fabrizio Lombardi, Hausi A. Müller Term Expiring 2018: Ann DeMarle, Fred Douglis, Vladimir Getov, Bruce M. McMillin, Cecilia Metra, Kunio Uchiyama, Stefano Zanero

EXECUTIVE STAFF Executive Director: Angela R. Burgess; Director, Governance & Associate Executive Director: Anne Marie Kelly; Director, Finance & Accounting: Sunny Hwang; Director, Information Technology & Services: Sumit Kacker; Director, Membership Development: Eric Berkowitz; Director, Products & Services: Evan M. Butterfield; Director, Sales & Marketing: Chris Jensen

COMPUTER SOCIETY OFFICES Washington, D.C.: 2001 L St., Ste. 700, Washington, D.C. 20036-4928 Phone: +1 202 371 0101 • Fax: +1 202 728 9614 • Email: [email protected] Los Alamitos: 10662 Los Vaqueros Circle, Los Alamitos, CA 90720 Phone: +1 714 821 8380 • Email: [email protected] Membership & Publication Orders Phone: +1 800 272 6657 • Fax: +1 714 821 4641 • Email: [email protected] Asia/Pacific: Watanabe Building, 1-4-2 Minami-Aoyama, Minato-ku, Tokyo 1070062, Japan • Phone: +81 3 3408 3118 • Fax: +81 3 3408 3553 • Email: tokyo.ofc@ computer.org

IEEE BOARD OF DIRECTORS President & CEO: Barry L. Shoop; President-Elect: Karen Bartleson; Past President: Howard E. Michel; Secretary: Parviz Famouri; Treasurer: Jerry L. Hudgins; Director & President, IEEE-USA: Peter Alan Eckstein; Director & President, Standards Association: Bruce P. Kraemer; Director & VP, Educational Activities: S.K. Ramesh; Director & VP, Membership and Geographic Activities: Wai-Choong (Lawrence) Wong; Director & VP, Publication Services and Products: Sheila Hemami; Director & VP, Technical Activities: Jose M.F. Moura; Director & Delegate Division V: Harold Javid; Director & Delegate Division VIII: John W. Walz revised 10 June 2016

NOVEMBER/DECEMBER 2016

|

I E E E S O F T WA R E

77

FOCUS: THE ROLE OF THE SOFTWARE ARCHITECT

THE ARCHITECT AS ­COMMUNITY SHEPHERD IN THE FUTURE

The past two decades have seen the rise of three interrelated trends that have dramatically and, we believe, irreversibly changed software development: open source, outsourcing, and distributed development. Each of these trends has changed projects’ social and organizational structures. So, architects who are in charge of or interact with such projects must be aware of these trends’ implications. For nearly 50 years, developers have generally accepted Conway’s law: system designs should be congruent with an organization’s structure, or problems will ensue.1 In traditional system development, in which project members were largely colocated and systems were typically small compared with current practice, Conway’s law had immediate, salient consequences. Today, in the world of distributed development, misalignments between a project’s social or organizational structure and its architecture might be much harder to detect and more insidious. Consequently, architects will need to be aware of the misalignments they might face, so that they can quickly detect and correct those misalignments before they cause too much damage (for example, additional social or organizational costs2). This is a new role for architects. We’ve always claimed that architects are much more than just a “technical lead,”3 but now they must also be an active community shepherd. We chose the term “shepherd” because a shepherd guides and cares for a flock. In much the same way that shepherds keep watch over their flocks, architects must deftly guide the social and organizational structures of today’s increasingly distributed projects, looking for the early warning signs of trouble. Such signs include disengagement, institutional isomorphism, and priggishness (see Table 1 in the main article). After detecting those signs, architects must perform a series of appropriate and properly aligned mitigations (see Table 2 in the main article). So, the architect’s role is changing, which implies new duties and requires upgraded skills and knowledge. References

appears to be a consequence of Conway’s law: “Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.”14 Consequently, the software architect’s role is becoming increasingly entangled with community or “Conwayness” management duties. These duties include managing the relation between architectures and their surrounding organizational structures and protecting architectures (and projects) from suboptimal organizational and sociotechnical circumstances. Further research should concentrate on operationalizing these sociotechnical circumstances for proper quantitative appraisal and incident detection and mitigation. Also, with modern software systems’ increasing scale, speed, and sociotechnical impact, more insights into unknown community smells might be required. This could involve • reviewing research on subversive stakeholders15 or • investigating how well-known sociotechnical or societal phenomena such as the “tragedy of the commons”16 affect software communities and their relations to software architects and architectures.

1. M. Conway, “How Do Committees Invent?,” Datamation, Apr. 1968, pp. 28–31. 2. D.A. Tamburri et al., “Social Debt in Software Engineering: Insights from Industry,” J. Internet Services and Applications, vol. 6, no. 1, 2015, pp. 10:1–10:17. 3. L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice, 3rd ed., 2012, Addison-Wesley.

small-team scenarios, in which three to 10 people are bound to a time frame by contractual arrangements that establish a small, cohesive project team. 78

I E E E S O F T WA R E

|

N

ow more than ever, software architects have to supervise the synchronization between software architectures and community structures.13 This

W W W. C O M P U T E R . O R G / S O F T W A R E

|

Finally, research could look at operationalization of the community patterns reported in this article: transforming the smell patterns into automatically measurable quantities (for example, by mining data from software repositories). Using such operationalizations, we can estimate a project’s social debt (caused by community smells) as a way to reason about and manage its costs. Furthermore, we intend to empirically

@ I E E E S O F T WA R E

References 1. L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice, 3rd ed., 2012, Addison-Wesley. 2. D.A. Tamburri et al., “Architecting in Networked Organizations,” Proc. 11th Working IEEE/IFIP Conf. Software Architecture (WICSA 14), 2014, pp. 247–256. 3. D.A. Tamburri, P. Lago, and H. van Vliet, “Organizational Social Structures for Software Engineering,” ACM Computing Surveys, vol. 46, no. 1, 2013, article 3. 4. D.A. Tamburri, P. Lago, and H. van Vliet, “Uncovering Latent Social Communities in Software Development,” IEEE Software, vol. 30, no. 1, 2013, pp. 29–36. 5. D.A. Tamburri and E.D. Nitto, “When Software Architecture Leads to Social Debt,” Proc. 12th Working IEEE/IFIP Conf. Software Architecture (WICSA 15), 2015, pp. 61–64. 6. N. Brown et al., “Managing Technical Debt in Software-Reliant Systems,” Proc. FSE/SDP Workshop Future of Software Eng. Research (FoSER 10), 2010, pp. 47–52. 7. D.A. Tamburri et al., “Social Debt in Software Engineering: Insights from Industry,” J. Internet Services and Applications, vol. 6, no. 1, 2015, pp. 10:1–10:17. 8. C. McGoff, The Primes: How Any Group Can Solve Any Problem, John Wiley & Sons, 2012. 9. R. Kazman et al., “A Case Study in Locating the Architectural Roots of Technical Debt,” Proc. 37th Int’l Conf. Software Eng. (ICSE 15), 2015, pp. 179–188.

ABOUT THE AUTHORS

investigate the relationships between smells, architecture patterns, and community patterns.3,4 For our view of where the architects’ role in community shepherding is headed, see the sidebar.

DAMIAN A. TAMBURRI is a research fellow at Politecnico di Milano. His research interests include social software engineering, advanced software architecture styles, and advanced software-architecting methods. He’s on the IEEE Software editorial board and is secretary of the International Federation for Information Processing Working Group on Service-Oriented Computing. Contact him at [email protected] or [email protected].

RICK KAZMAN is a professor of information technology man-

agement at the University of Hawaii and a principal researcher at Carnegie Mellon University’s Software Engineering Institute. His research interests include software architecture design and analysis tools, software visualization, and software engineering economics. Kazman is the chair of the IEEE Technical Council on Software Engineering. Contact him at [email protected].

HAMED FAHIMI is an IT project manager and consultant at CGI. His research interests include communities of practice and knowledge engineering. Fahimi received an MSc in information studies—business information systems from Universiteit van Amsterdam. Contact him at [email protected].

10. D. Montello, “The Measurement of Cognitive Distance: Methods and Construct Validity,” J. Environmental Psychology, vol. 11, no. 2, 1991, pp. 101–122. 11. C. Manteli, B. van den Hooff, and H. van Vliet, “The Effect of Governance on Global Software Development: An Empirical Research in Transactive Memory Systems,” J. Information and Software Technology, vol. 56, no. 10, 2014, pp. 1309–1321. 12. L. Bass, I. Weber, and L. Zhu, DevOps: A Software Architect’s Perspective, Addison-Wesley, 2015. 13. R. Kazman and H.-M. Chen, “The Metropolis Model: A New Logic for the Development of Crowdsourced

Systems,” Comm. ACM, vol. 52, no. 7, 2009, pp. 76–84. 14. M. Conway, “How Do Committees Invent?,” Datamation, Apr. 1968, pp. 28–31. 15. J. Rost and R.L. Glass, “The Impact of Subversive Stakeholders on Software Projects,” Comm. ACM, vol. 52, no. 7, 2009, pp. 135–138. 16. G. Hardin, “The Tragedy of the Commons,” Science, vol. 162, no. 3859, 1968, pp. 1243–47.

Selected CS articles and columns are also available for free at http://ComputingNow.computer.org.

NOVEMBER/DECEMBER 2016

|

I E E E S O F T WA R E

79

FEATURE: SECURITY SOFTWARE

A Paradigm Shift for the CAPTCHA Race Adding Uncertainty to the Process Shinil Kwon and Sungdeok Cha, Korea University

// A proposed image-based CAPTCHA approach randomly excludes some images from a challenge’s decision process. However, later challenges might include these images in decisions. So, successful responses might differ between challenges even though the challenges use the same images. //

though computer vision algorithms are powerful, they’re still weak in answering semantic questions (for example, “Click on all images in which Bill Gates appears”). For image-based CAPTCHA systems to be effective, the challenges must defeat robot-launched attacks but be easy for humans. Internet companies have reported that robots try to create accounts several millions of times daily. We must assume that the robots employ heuristic-learning algorithms providing “infi nite neverfailing memory.” Should robots, through luck, pass the challenge, they can record all the relevant information for use in future attacks. Furthermore, robots could use commercial search engines to retrieve image tags or similar images. We’ve developed an approach that protects image-based CAP TCHA systems from heuristic attacks by injecting random and temporary uncertainty into the challenges. We implemented it as a Web-based application at http://dependable.korea .ac.kr/captcha. To evaluate it, we conducted experiments with the most sophisticated robots we could envision and with people. Our approach almost always beat the robots, whereas humans could easily pass the challenges.

Defeating Heuristic Attacks THE TEXT-BASED CAPTCHA (Completely Automated Public Turing Test to Tell Computers and Humans Apart), despite its widespread use, has become impractical. As Kumar Chellapilla and his colleagues lamented,1 the recognition problem has become easier for computers than humans. Deployed CAPTCHA systems (for example, 80

I E E E S O F T WA R E

| PUBLISHED

Gmail’s CAPTCHA, 2 Yahoo’s EZGimpy, 3–5 or Microsoft’s Live service6–7) have been compromised. Also, as the systems distort the text more, people become increasingly frustrated when it’s too distorted to correctly interpret. A promising alternative is imagebased CAPTCHA (for examples of this strategy, see the sidebar). AlBY THE IEEE COMPUTER SO CIE T Y

Our approach (see Figure 1) presents a collection of images, each internally labeled M (must be chosen) or MN (must not be chosen) with respect to a given challenge. When an image is part of a challenge, its selection or omission immediately affects the outcome. To introduce uncertainty, our approach randomly and temporarily selects some of the images to be 0 74 0 -74 5 9 / 1 6 / $ 3 3 . 0 0 © 2 0 1 6 I E E E

RELATED WORK IN IMAGE-BASED CAPTCHAS Image-based CAPTCHAs (Completely Automated Public Turing Test to Tell Computers and Humans Apart), proposed by Luis Von Ahn and his colleagues,1 generally are semantic- or pattern-based. An example of the former is Asirra, which shows images of cats and dogs.2 Users are supposed to click on the outlier image among 12 randomly chosen images. This approach’s scalability is questionable because all images in the database must be manually verified and tagged. This approach is also vulnerable to heuristic attacks. The penetration ratio will be higher if robots extract the images and analyze each of them using commercial search engines. If robots update their image databases whenever random guesses are successful, they’ll eventually pass the challenges. Yong Rui and Zicheng Liu developed ARTiFACIAL (Automated Reverse Turing Test Using Facial Features), a pattern-based system that doesn’t require manual tagging.3 The system asks users to click on six facial corner points (for example, four for the eyes and two for the mouth) from an array of 3D facial images. Unfortunately, users often find the challenges too difficult to pass owing to image deformation (for example, owing to shading or lighting). However, such challenges might not be difficult for robots with advanced vision algorithms. For example, using machinelearning algorithms that measured the distance between candidate facial components, Bin Zhu and his colleagues reported an 18 percent penetration ratio, making ARTiFACIAL practically useless.4 As an alternative, Zhu and his colleagues proposed the Cortcha system, which crops part of an image and fills the area with a decoy image.4 The system asks users to correctly locate the cropped image among eight candidates and drag it to the proper location. Although Cortcha can automatically generate unique challenges, it’s not robust enough against robots using powerful pattern-matching algorithms or search engines. If the original image used in the challenge can be retrieved on the Internet, beating Cortcha is trivially easy. Besides applying distortion (for example, object scaling, mesh warping, localized color shifting, or semiregular object clutter), researchers have proposed generating challenges for which successful responses require the semantic under-

“neutral” images, which are randomly placed among the challenge

standing of images. The IMAGINATION (Image Generation for Internet Authentication) system introduced a two-step process.5 The system dynamically generates eight images and asks users to select one. Upon selection, the system applies distortion, and users must provide the expected tag name (for example, “tiger”) for the distorted image. Unfortunately, excessive distortions will likely result in frequent failures by humans. Incorrect semantic interpretation can also cause failures; for example, some people have trouble distinguishing a wolf from a fox. Current CAPTCHA systems’ most serious vulnerability is the static decision process. For example, a system might display a group of images and ask users to choose all the images in which Bill Gates appears (see Figure 2 in the main article). Conventional image-based CAPTCHA approaches will have only one correct response that never changes. That is, there are only two types of images: those that must be chosen and those that must not be chosen. All of the former images must be chosen; none of the latter images must be chosen. If each image plays only one role in all challenges, robots can easily defeat the system with random guessing and simple heuristic learning. This is because an accidental passing of the test will completely reveal the participating images’ identities. References 1 L. Von Ahn, M. Blum, and J. Langford, “Telling Humans and Computers Apart Automatically,” Comm. ACM, vol. 47, no. 2, 2004, pp. 56–60. 2 J. Elson et al., “Asirra: A CAPTCHA That Exploits Interest-Aligned Manual Image Categorization,” Proc. 14th ACM Conf. Computer and Communications Security (CCS 07), 2007, pp. 366–374. 3 Y. Rui and Z. Liu, “ARTiFACIAL: Automated Reverse Turing Test Using FACIAL Features,” Multimedia Systems, vol. 9, no. 6, 2004, pp. 493–502. 4 B.B. Zhu et al., “Attacks and Design of Image Recognition CAPTCHAs,” Proc. 17th ACM Conf. Computer and Communications Security (CCS 10), 2010, pp. 187–200. 5 R. Datta, J. Li, and J.Z. Wang, “IMAGINATION: A Robust ImageBased CAPTCHA Generation System,” Proc. 13th Ann. ACM Int’l Conf. Multimedia (MM 05), 2005, pp. 331–334.

images. The system ignores the decisions made on these images. Robots

could select images labeled MN (for example, image B in Figure 2) and

NOVEMBER /DECEMBER 2016

| IEEE

S O F T WA R E

81

FEATURE: SECURITY SOFTWARE

No Change some M and MN to neutral

Generate challenge

Trap database

M database

Successful response?

Yes

Update trap database

MN database

FIGURE 1. Our CAPTCHA (Completely Automated Public Turing Test to Tell Computers and Humans Apart) mechanisms with neutral and trap images. Each image is internally labeled M (must be chosen) or MN (must not be chosen) with respect to a given challenge.

B

A

FIGURE 2. A sample challenge: “Select all images in which Bill Gates appears.” Image A (which must normally be chosen) and image B (which must normally not be chosen) are example images that our approach has labeled as neutral for a specific challenge. The system ignores the decisions made on these images for that challenge.

still accidentally pass the challenge if those images are neutral. Robots could also accidentally pass even if they don’t select the images labeled M (for example, image A in Figure 2) that are neutral. This idea is similar 82

I E E E S O F T WA R E

|

to jurors whose identities are known only to the judge. Although all the jurors’ votes appear to count, the judge secretly ignores certain jurors’ votes. The key idea is that such role switches are random. That is, given

W W W. C O M P U T E R . O R G / S O F T W A R E

|

any collection of images, a successful response will differ from one challenge to the next depending on each image’s roles. Because no advance information exists on those roles, robots can’t learn anything from success due to lucky guesses. Neutral images eliminate the threat of heuristic attacks. Another powerful mechanism that further reduces the chance of robots passing a challenge is the trap image database. Our system monitors the patterns of successful responses and maintains a list of the images most likely to defeat robot attacks. The trap database is initially empty; in a straightforward implementation, it would record information on the source IP address and maintain a list of images that would have resulted in failures had they not been neutral. It includes both images labeled M that weren’t selected and images labeled MN that were selected in successful responses. Humans sometimes make mistakes but are less likely to repeat them. Robots, however, will likely repeat the same decision, especially if they employ heuristic learning or search engines. So, using one or two images from the trap database will likely defeat robots because trap images serve as an effective, self-implemented, and permanent trap. We update the trap database only when challenges are passed, to minimize the possibility of robot-initiated sessions indirectly influencing our mechanism. The internal label (M or MN) of the images in the trap database never changes with respect to a challenge. Multiple IP addresses could exhibit similar patterns when using DHCP (Dynamic Host Configuration Protocol) or NAT (Network Address Translation). How-

@ I E E E S O F T WA R E

(a)

No. of challenges

(b)

7. 5 17 M .5 M 20 .0 M 22 .5 M 25 .0 M

5. 0M

0

2. 5M

0

7. 5 17 M .5 M 20 .0 M 22 .5 M 25 .0 M

5. 0M

0 0

0.1

No. of challenges

0

(c)

7. 5 17 M .5 M 20 .0 M 22 .5 M 25 .0 M

0.1

0.9

5. 0M

0.9

2. 5M

Success ratio

Success ratio

0.1

2. 5M

Success ratio

0.9

0

1.0

1.0

1.0

No. of challenges

FIGURE 3. The success ratio of attacks by robots using heuristic learning. (a) Without neutral images. (b) With neutral images. (c) With neutral images and the trap database. When employing the trap database, our system never missed the robots’ mistakes.

ever, the system could use a decision tree to identify and group them. Proper management of the trap database is critical. If the system detects confl icting behavior from the same IP address on some trap images, it could remove those images from the trap database. A challenge’s diffi culty can be easily adjusted. Each challenge must include at least one M and MN image. Otherwise, brute-force attacks would succeed. Including more images in a challenge will lower the likelihood of robots passing it by guessing.

Evaluating the Approach Evaluation of our approach involved the following two phases.

Robots First, we simulated the success (penetration) ratios of robots. We manually verified 12,388 images (4,033 images of Bill Gates and 8,355 other images) retrieved by the Google search engine and labeled them M or MN. Each challenge involved 22 images, up to eight of which were neutral. When the system deployed the trap mechanism, it took one or two images randomly from the trap database.

With heuristic learning. We simulated the behavior of robots using heuristic learning as follows:

1. If the system displayed previously unseen images, we assumed that the robots randomly chose whether to click on them. 2. When robots passed challenges, we assumed that the chosen images were stored in a “pirate” database of M images and that the other images were stored in a pirate MN database to enable heuristic-learning attacks. 3. When robots failed challenges, we assumed that the pirate databases weren’t updated. Although the likelihood of success in random guessing was slim, each success resulted in learning the true identity of up to 22 images. When the decision involved all 22 images, the robots took 24,510,000 attempts to learn the 12,388 images’ identities (see Figure 3a). When the system assigned neutral images, the robot achieved approximately a 0.023 success ratio after only 2,250,000 attempts (see Figure 3b). The robots took fewer attempts because fewer images actually participated in the decision

process. The success ratio remained at approximately 0.023 because the neutral images kept supplying potentially confusing and incorrect information to the heuristic-learning algorithm. Owing to random and temporal aspects of the neutral images, the pirate databases couldn’t maintain accuracy, and the robots never had opportunities to correct their misunderstanding. We discovered that 2,465 images (approximately 19.9 percent) were incorrectly labeled in the pirate databases. For example, some M images were stored as MN because they were neutral and the robot passed the challenge without clicking on them. Or, some MN images were stored as M because they were neutral and the robot clicked on them. In theory, we could have updated the pirate databases when “trusted” information proved incorrect. However, we had difficulty determining which of the 22 images caused rejection. When the system deployed trap images, the robots’ success ratio remained near zero (see Figure 3c). Our system never missed the robots’ mistakes, and later challenges included one or two such images to defeat nearly all the robot attacks.

NOVEMBER /DECEMBER 2016

| IEEE

S O F T WA R E

83

FEATURE: SECURITY SOFTWARE

1.0

0.9 0.1

1.0 Success ratio

Success ratio

Success ratio

1.0

0.9 0.1

0

0 0

20k

(a)

40k 60k 80k No. of challenges

100k

0.9 0.1 0

0 (b)

20k

40k 60k 80k No. of challenges

100k

0 (c)

20k

40k 60k 80k No. of challenges

100k

FIGURE 4. The success ratio of attacks by robots using search engines. (a) Without neutral images. (b) With neutral images. (c) With neutral images and the trap database. Again, the trap mechanism was powerful in defeating robots.

0.9

Success ratio

0.8

Without trap With trap

0.797

trieved 1,379 incorrect images with tags containing “Bill Gates” as a keyword, and those images’ inclusion always defeated the robots.

0.707

People

0.847

0.765

0.7

0.767

0.663 0.635

0.6

0.5

0.573

25

50 CAPTCHA sessions (%)

75

100

FIGURE 5. The human participants’ average success ratio for each quarter of the CAPTCHA sessions. The learning curves’ effects are apparent.

With search engines. When the robots used search engines, we assumed they could retrieve each image’s tags. Robots clicked on an image only if its tag contained a keyword used in the challenge. Our preliminary analysis of the Google image search engine using “Bill Gates” as the keyword reported approximately 80.5 percent accuracy. All the retrieved images were relevant, but some were incorrect (for example, photos of Bill Gate’s mansion or daughter). If a challenge involved all 22 images, the success ratio was approximately 0.0082 (see Figure 4a). The success 84

I E E E S O F T WA R E

|

ratio varied slightly, depending on which images the robots randomly selected in a challenge. When the system treated some images as neutral, the robots achieved and maintained a success ratio of approximately 0.0271 (see Figure 4b). Because the robots weren’t using heuristic learning, the neutral images didn’t introduce confusion. These images simply resulted in fewer images involved in the decision, and the success ratio was higher. Again, the trap mechanism was powerful in defeating robots (see Figure 4c). In our analysis, robots re-

W W W. C O M P U T E R . O R G / S O F T W A R E

|

Another experiment involved 26 people who weren’t computer science experts but knew who Bill Gates is. It used 17,356 images (5,191 M and 12,165 MN images), including the images from the robot simulation experiment. The participants performed 4,266 challenges. We divided the participants in two groups. Eleven participants performed the challenges with the trap database activated from the beginning. The database was initially empty; images mistaken by each participant were added to it along with the user’s IP address. Halfway through the sessions, we disabled the trap mechanism, making the challenges easier. For the other participants, we initially disabled the trap mechanism but activated it during the second half of the sessions. We wanted to investigate how the trap mechanism affected the participants’ success ratio in different settings. When the system randomly inserted neutral images without the trap mechanism, the average success ratio was approximately 0.793. Some

@ I E E E S O F T WA R E

O

ur approach aims to stop the never-ending race of distortions in which sophisticated robots compete with people. By introducing uncertainty into the challenges, our system demonstrates that robots, regardless of their sophistication, can be forced to play a guessing game in which the chance of random success is negligible. The correct response to a challenge rarely remains static, and robots must keep playing the guessing game. As we mentioned before, we can easily adjust the challenge’s difficulty by changing the number of participating and neutral images. The trap mechanism is another powerful tool that can virtually eliminate the threat of robots. The images most likely to result in rejection of robots are included when challenges are dynamically generated. We’re investigating scalability and resiliency issues in depth in close collaboration with researchers at Microsoft Research Asia. Acknowledgments This research was supported by the

ABOUT THE AUTHORS

participants failed to recognize Bill Gates in photos taken about 30 years ago. Some photos were of groups in which he didn’t visually stand out. In some cases, participants mistakenly selected cartoon images of him. With the trap mechanism, the average success ratio decreased to 0.645. When the system initially activated the mechanism, the success ratio was as low as 0.573. However, people began learning from earlier failures, and the success ratio climbed to 0.707 by the end. The learning curves’ effects are apparent in Figure 5, which shows the average success ratio for each quarter of the sessions.

SHINIL KWON is a PhD student in Korea University’s College

of Informatics. His research interests include image-based CAPTCHA and Web robot detection. Kwon received an MS in computer science from Korea University. Contact him at bluehven@ korea.ac.kr.

SUNGDEOK CHA is a professor in Korea University’s Computer Science and Engineering Department. His research interests include software safety and computer security. Cha received a PhD in information and computer science from the University of California, Irvine. Contact him at [email protected].

Okawa Foundation and by the Ministry of Science, ICT and Future Planning, Korea and Microsoft Research, under the ICT/SW Creative Research Program supervised by the Institute for Information & Communications Technology Promotion (IITP-2015-R2215-15-1011). References 1. K. Chellapilla et al., “Computers Beat Humans at Single Character Recognition in Reading Based Human Interaction Proofs (HIPs),” Proc. 2nd Conf. Email and Anti-spam (CEAS 05), 2005; www.ceas.cc/2005 /papers/160.pdf. 2. kdawson, “Gmail CAPTCHA Cracked,” 27 Feb. 2008; http:// it.slashdot.org/story/08/02/27 /0045242/gmail-captcha-cracked. 3. P. Simard, “Using Machine Learning to Break Visual Human Interaction Proofs (HIPs),” Advances in Neural Information Processing Systems 17, MIT Press, 2005, pp. 265–272. 4. G. Moy et al., “Distortion Estimation

Techniques in Solving Visual CAPTCHAs,” Proc. 2004 IEEE Computer Soc. Conf. Computer Vision and Pattern Recognition (CVPR 04), vol. 2, 2004, pp. 23–28. 5. J. Yan and A.S. El Ahmad, “Breaking Visual CAPTCHAs with Naive Pattern Recognition Algorithms,” Proc. 23rd Ann. Computer Security Applications Conf. (ACSAC 07), 2007, pp. 279–291. 6. J. Yan and A.S. El Ahmad, “A LowCost Attack on a Microsoft CAPTCHA,” Proc. 15th ACM Conf. Computer and Communications Security (CCS 08), 2008, pp. 543–554. 7. kdawson, “Windows Live Hotmail CAPTCHA Cracked, Exploited,” 15 Apr. 2008; http://tech.slashdot.org /story/08/04/15/1941236/windows -live-hotmail-captcha-cracked -exploited.

Selected CS articles and columns are also available for free at http://ComputingNow.computer.org.

NOVEMBER /DECEMBER 2016

| IEEE

S O F T WA R E

85

FEATURE: MOBILE APPS

Examining the Rating System Used in MobileApp Stores Israel J. Mojica Ruiz, McAfee Meiyappan Nagappan, Rochester Institute of Technology Bram Adams, École Polytechnique de Montréal Thorsten Berger, University of Waterloo Steffen Dienst, University of Leipzig Ahmed E. Hassan, Queen’s University, Canada

// Over one year, researchers mined the ratings of more than 10,000 mobile apps in Google Play. Many apps’ ratings rose or fell as a whole, but their overall store rating eventually became resilient to fluctuations. //

ample, Amazon.com) have analyzed how such ratings influence a customer’s decision to acquire a product.1,2 (For more on related work on review systems, see the sidebar.) As in online bookstores, an app’s rating (among other factors) influences app store customers’ decisions. Recent research shows that the ratings correlate strongly with download counts, a key measure of a mobile app’s success.3 However, a key difference exists between mobile apps and books (or other products with a similar rating system). An app can be updated in a very short time period (for example, weekly updates are common in Google Play), whereas books or other products take more time and are often released as new products, not just new versions of old products. Nevertheless, most app store ratings don’t take updated versions into account; they use a static rating system to help customers differentiate the apps that have high or low satisfaction levels among users. To investigate the issues with this rating system, we studied Google Play’s ratings of free-to-download mobile apps for a year. The results indicate the need for a careful rethinking of this system.

Store Ratings

SIMILAR TO buying books from Amazon.com, users can download mobile apps from app stores such as Google Play (http://play.google 86

I E E E S O F T WA R E

| PUBLISHED

.com /store/apps) and rate their experience in using the apps. Studies in other types of online markets such as online bookstores (for exBY THE IEEE COMPUTER SO CIE T Y

Typically, app stores employ ratings on a scale of 1 to 5 stars. Google Play (and most other major app stores) displays a rating that’s the cumulative average of all individual user ratings of the app over all the versions (that is, over the app’s lifetime in the app store). We call this the store rating. For example, if two users give 3 stars to version 1 of an app, and five users give 4 stars to version 2, the app’s store rating is (2 × 3 + 5 × 4)/7 = 3.7. 0 74 0 -74 5 9 / 1 6 / $ 3 3 . 0 0 © 2 0 1 6 I E E E

RELATED WORK IN REVIEW SYSTEMS Laura Galvis Carreño and Kristina Winbladh1 and Claudia Iacob and Rachel Harrison2 analyzed the textual content in the user reviews of mobile apps, for requirements elicitation. Our study (see the main article) examined user app ratings, not the reviews’ textual content, to determine whether Google Play’s rating system is appropriate. Amazon.com’s review system has also been the subject of several studies. Judith Chevalier and Dina Mayzlin studied reviewers’ behavioral patterns on Amazon.com and barnesandnoble.com.3 They found that positive reviews of a book resulted in its increased sales. Bo-Chun Wang and his colleagues proposed to improve Amazon’s review system by adding two factors: review credibility and time decay.4 Lik Mui and colleagues proposed a Bayesian probabilistic technique to weight a rating on the basis of the rater’s personal characteristics.5 Geng Cui and his colleagues studied the effect of early electronic word of mouth in Amazon.com, using data collected over nine months.6 Surprisingly, they found that negative reviews helped increase sales, as long as most of the reviews were positive. However, the negative reviews’ effect decreased with time. Cui and his colleagues posited that once a substantial number of reviews are in (a critical mass of adopters is reached), sales will increase. So, early reviews are critical to a product’s success. Our study found a similar trend. If an app’s initial ratings were poor and a substantial number of people had rated it, its overall store rating had difficulty recovering.

In other words, app stores calculate the store rating as storei = sum of all the individual ratings assigned to the app until version i , nr _ratings _until _i

where storei is the store rating for version i, and nr_ratings_until_i is the total number of ratings across all versions up until i. Essentially, storei is the app’s overall average rating,

Our study differed from the research we just described mainly in that we investigated Google Play. There, the product is software (apps), which changes frequently (and can be updated easily) compared to books and other products. Also, unlike apps, newer versions of books and other products get released as new products, not updated versions of the same product. References 1. L.V. Galvis Carreño and K. Winbladh, “Analysis of User Comments: An Approach for Software Requirements Evolution,” Proc. 2013 Int’l Conf. Software Eng. (ICSE 13), 2013, pp. 582–591. 2. C. Iacob and R. Harrison, “Retrieving and Analyzing Mobile Apps Feature Requests from Online Reviews,” Proc. 10th Working Conf. Mining Software Repositories (MSR 13), 2013, pp. 41–44. 3. J.A. Chevalier and D. Mayzlin, “The Effect of Word of Mouth on Sales: Online Book Reviews,” J. Marketing Research, vol. 43, no. 3, 2006, pp. 345–354. 4. B.C. Wang, W.Y. Zhu, and L.J. Chen, “Improving the Amazon Review System by Exploiting the Credibility and Time-Decay of Public Reviews,” Proc. 2008 IEEE/WIC/ACM Int’l Conf. Web Intelligence and Intelligent Agent Technology (WI-IAT 08), vol. 3, 2008, pp. 123–126. 5. L. Mui et al., “Ratings in Distributed Systems: A Bayesian Approach,” Proc. Workshop Information Technologies and Systems, 2001. 6. G. Cui, H.-K. Lui, and X. Guo, “Online Reviews as a Driver of New Product Sales,” Proc. 4th Int’l Conf. Management of E-Commerce and E-Government (ICMeCG 10), 2010, pp. 20–25.

from the fi rst version until the current version.

The Data Source We chose Google Play because it’s one of the largest app stores and we could extract the data we needed for our study. We extracted the ratings for 242,089 app versions of 131,649 mobile apps.4 Because Google can adjust ratings in case of fraud or assign a rating to unrated apps, 5 we had to sanitize our data to eliminate ratings anomalies. For example, for

3,891 versions of 3,454 apps, a later version had fewer raters than an earlier version. After fi ltering out apps with anomalous ratings, we had 238,198 versions of 128,195 apps. Store ratings of apps with only a few raters aren’t reliable because the developers and their friends could have rated the app highly. Such apps could be very good, but you can’t be sure of it. Andrew Whitby and his colleagues employed statistical filtering to exclude unfair ratings of each user.6 We also observed such a rater

NOVEMBER /DECEMBER 2016

| IEEE

S O F T WA R E

87

FEATURE: MOBILE APPS

bias, so we filtered our dataset to obtain a more representative sample. However, unlike Whitby and his colleagues, we didn’t filter out any particular user’s ratings; instead, we filtered out apps with fewer than 10 raters. We then fi ltered out apps with just one version because, to calculate a specific version’s rating, we needed the store rating and the number of raters of the previous version. (We present our formula for calculating a specific version’s rating later.) So, we ended up with 32,596 versions of 10,150 apps. On every day in 2011, we mined the Google Play store rating for each of the 10,150 apps. We also mined the number of people who had rated the app up to that day.7 We didn’t mine the app reviews, which formed a subset of the people who rated the app. (Users don’t have to write a review in order to rate an app, but they have to rate an app in order to write a review.) Because we didn’t mine the reviews, we couldn’t obtain other metadata such as the user’s name, device name, and so on. So, we couldn’t fi lter out a specific user’s rating from a specific device using a specific app. We downloaded the app binary every day. When a new version of the app binary was available on a particular day, we knew that a new version of the app had been released that day. Using this information, we could reconstruct an app’s version history and how the ratings evolved from version to version. Because Google Play provided no version ratings, we manually reconstructed them from the version history. If you wish to replicate our study, you can access the data at http:// sailhome.cs.queensu.ca/replication 88

I E E E S O F T WA R E

|

/2014/Ratings_ IEEE _ SW/Ratings _Data.csv.

How Store Ratings Respond to New Versions An app’s store rating is an important indicator of its user-perceived satisfaction. Such a rating must be representative of the evolving nature of apps. Our case study examined whether an app’s store rating would change if the rating of a specifi c version of that app changed, compared to the initial store rating.

Calculating Version Ratings To reconstruct the rating of each version of an app, we used this equation: version − ratingi = storei ∗ nr _ratings _until _i − storei −1

∗nr _ratings _until _i − 1 nr _ratings _until _i −nr _ratings _until _i − 1

.

The numerator corresponds to the total number of stars awarded to app version i by all of i’s raters; the denominator corresponds to the number of ratings of i. We focused on apps with at least two versions (when studying version ratings) or three versions (when studying version-rating changes) because we couldn’t calculate the version-rating metric for the fi rst version that appeared in Google Play.

The Initial Results To illustrate our results, we use a hexbin plot, which adds a dimension to the regular scatterplot. The hexbin plot captures each point’s frequency in the scatterplot by divid-

W W W. C O M P U T E R . O R G / S O F T W A R E

|

ing the plot into hexagons, each of which gets a shade representing the number of observations. Figure 1 compares the change in an app’s store rating from one version to another to the change in that app’s version rating. A hexagon’s shading indicates the number of apps that had a particular combination of store rating and version rating. Figure 1 reveals three phenomena. First, most rating changes float around 0 for both the store and version ratings; that is, no rating change happened. Second, the graph shows a long vertical stretch of version-rating deltas (between –3 and 3), with only a short horizontal stretch of store-rating deltas (between –1 and 1). So, versionrating changes had no corresponding store-rating changes, confi rming that the store rating dampened the effect of fluctuations in quality. Third, a slight diagonal pattern from the bottom left to the upper right indicates that some versionrating changes had corresponding but dampened (across a smaller range) store-rating changes. To better understand the dampening, we calculated the percentage of app versions in which a versionrating change resulted in a visible store-rating change. (By visible, we mean that the store rating changed more than half a star.) In 78.8 to 97.4 percent of all app versions, version-rating changes didn’t result in a store-rating change. Of the apps that lost 1, 2, or 3 version-rating stars, 11.2 percent, 21.0 percent, and 14.3 percent, respectively, lost only 1 store-rating star. Of the apps that gained 1, 2, or 3 version-rating stars, 9.3 percent, 20.0 percent, and 14.3 percent, respectively, gained only 1 store-rating star.

@ I E E E S O F T WA R E

Counts 1,694 1,588

2

For each app, we determined the change in store rating between its first and last version in 2011. We also determined the total number of people who had rated the first version. Figure 2 shows that the more raters an app had at the beginning of 2011, the more resilient the app was to store-rating changes, even after a year of ratings. For example, for store-rating changes, the variance and standard deviation were 28 times and 5 times higher, respectively, for apps that started with fewer than 5,000 raters than for apps with more than 5,000 raters. This implies that developers of an app with a high store rating and high number of raters would have leeway to experiment in a new version without negatively affecting the store rating. In contrast, developers of apps with a poor store rating and high number of raters would fi nd it nearly impossible to improve the store rating. We looked at six more months of data (the total period from January 2011 to June 2012) for KakaoTalk, one of the apps with the most ratings, to see how its store and version ratings fluctuated. KakaoTalk had 229,869 raters by January 2011 and 936,497 raters by June 2012. Its store rating stayed at 4.5. However, its version rating fell once by 1.54 and rose once by 1.44. KakaoTalk is an example of an app with highly fluctuating version ratings that didn’t affect its stable store rating. These observations suggest that an app’s real quality doesn’t really matter once a massive number of

1,271 Version-rating change

Why Store Ratings Were Resilient to Change

1,482 1,377 1,165 1,059

0

953 848 742 636 530

–2

424 318 213 107 1

–4 –1.5

–1.0

–0.5

0

0.5

1.0

1.5

Store-rating change

FIGURE 1. The change in version rating for each successive pair of all versions of the apps (with at least two versions in 2011 and 10 raters per version), versus the change in the apps’ store ratings. The store rating was resilient to version-rating changes.

4

2

Store-rating change

The overall lesson is that store ratings were resilient to versionrating changes.

0

–2

1e + 00

1e + 02

1e + 04

1e + 06

Initial no. of raters

FIGURE 2. Store-rating changes between the first and last versions of apps with at least two versions in 2011, versus the total number of raters of first version. The more raters an app had at the beginning of 2011, the more resilient the app was to store-rating changes. NOVEMBER /DECEMBER 2016

| IEEE

S O F T WA R E

89

FEATURE: MOBILE APPS

users have rated the app favorably, because the displayed store rating remains the same. Although an app’s store rating might be resilient, its version rating provides a more in­ stantaneous and hence more accu­ rate view of its perceived quality.

Threats to Validity Here we address the perceived threats to our research’s validity.

External Validity We studied the Android platform because we had readily available APIs to mine apps from Google Play. We studied only the free apps because we required access to the source code or bytecode, which we couldn’t obtain for paid apps with­ out actually paying. Because the An­ droid platform has the largest user base,8 it has the most downloads,9 and free apps represent 75 percent of the apps in Google Play.10 Addi­ tionally, we looked only at data from 2011. However, as we mentioned be­ fore, the rating systems of Google Play and various other app stores are basically the same. So, we be­ lieve that our case study space was broad and practical enough to draw valid conclusions.

Internal Validity We used publicly available APIs to mine Google Play. Our crawling tools collected the data from the store automatically. Although we took every possible precaution to ensure our tools worked correctly, we couldn’t collect every app in the market every day because we were restricted by the number of queries we could submit to the app store. So, we might have missed particular ver­ sions of an app. However, other researchers have extensively used these crawling APIs, 90

I E E E S O F T WA R E

|

and our frequency of data collection was higher than the frequency of new app releases. So, we believe our results don’t suffer significantly from those threats. Also, one of us is the Natural Sciences and Engineering Research Council of Canada / BlackBerry Software Engineering Chair at the School of Computing at Queen’s University. Even though BlackBerry is a competitor of Android, we be­ lieve we controlled for that threat because all of us jointly interpreted and validated our analyses.

Construct Validity Currently, in Google Play, it’s not clear when users rate an app. Users might rate an app at any time inde­ pendently of the current version in Google Play. So, the version ratings we calculated might not be entirely accurate. However, because we fre­ quently downloaded the apps, we be­ lieve we captured the version rating as accurately as possible.

W

e have the following rec­ ommendations for app store owners and app

developers. App store owners should display both the current store rating and version rating. Otherwise, app de­ velopers have no incentive to main­ tain or improve ratings. So, users might not have access to the highestquality apps. App store owners should also ex­ plore more advanced ways to gener­ ate ratings. One option is a system that exponentially decays the older ratings, hence emphasizing recent version ratings over much older (and probably outdated) version ratings. If app stores display only the cur­ rent store ratings, app developers

W W W. C O M P U T E R . O R G / S O F T W A R E

|

will gain limited benefit from re­ leasing a new, improved version of a low-rated app. Instead, develop­ ers should release the new version of a poorly rated app as a new app, and redirect their user base to the new app. Finally, with the current storerating system, the “release early, fix later” strategy isn’t optimal for initial or early app versions. A low-quality initial version might get many poor ratings, thus making it difficult to in­ crease the store rating to 4 or more stars. This underlines the importance of prioritizing requirements for, and ensuring the quality of, (at least) early app versions. References 1. J.A. Chevalier and D. Mayzlin, “The Effect of Word of Mouth on Sales: Online Book Reviews,” J. Marketing Research, vol. 43, no. 3, 2006, pp. 345–354. 2. G. Zacharia, A. Moukas, and P. Maes, “Collaborative Reputation Mechanisms in Electronic Market­ places,” Proc. 32nd Ann. Hawaii Int’l Conf. System Sciences (HICSS 99), vol. 8, 1999, p. 8026. 3. M. Harman, Y. Jia, and Y. Zhang, “App Store Mining and Analysis: MSR for App Stores,” Proc. 9th IEEE Working Conf. Mining Software Repositories (MSR 12), 2012, pp. 108–111. 4. S. Dienst and T. Berger, “Static Anal­ ysis of App Dependencies in Android Bytecode,” tech. note, 2012; www .informatik.uni-leipzig.de/~berger /tr/2012-dienst.pdf. 5. “Google Play Developer Distribution Agreement,” Google, 2014; http:// play.google.com/about/developer -distribution-agreement.html. 6. A. Whitby, A. Josang, and J. Indul­ ska, “Filtering Out Unfair Ratings in Bayesian Reputation Systems,” Proc.

@ I E E E S O F T WA R E

ABOUT THE AUTHORS

ISRAEL J. MOJICA RUIZ is a software

THORSTEN BERGER is an assistant

engineer at McAfee. His research interests include mobile software and empirical software analysis. Mojica Ruiz has an MS in computer science from Queen’s University. Contact him at israel_mojica@ mcafee.com.

professor in the Chalmers University / University of Gothenburg’s Computer Science and Engineering Department. His research interests include model-driven software engineering, software product lines and ecosystems, static program analysis, and mining software repositories. He previously was a postdoctoral fellow in the University of Waterloo’s Generative Software Development Lab. Berger received a PhD in computer science from the University of Leipzig. Contact him at thorsten.berger@ chalmers.se.

MEIYAPPAN NAGAPPAN is an assistant professor in the Rochester Institute of Technology’s Software Engineering Department. His research interests include deriving solutions for software system stakeholders and using large-scale software engineering data to address the concerns of software developers, software operators, build engineers, and project managers. Nagappan received a PhD in computer science from North Carolina State University. He’s the editor of the IEEE Software blog. Contact him at mei@ se.rit.edu.

STEFFEN DIENST is a doctoral student in business information systems at the University of Leipzig. His research interests include using machine learning to monitor the operation of renewable power plants. Dienst received an MS in computer science from the University of Leipzig. Contact him at [email protected]

BRAM ADAMS is an assistant professor at École Polytechnique de Montréal, where he heads the Maintenance, Construction, and Intelligence of Software lab. His research interests include software release engineering, software integration, software build systems, software modularity, and software maintenance. Adams received a PhD in computer science engineering from Ghent University. He’s one of the organizers of the International Workshop on Release Engineering and is a member of IEEE. Contact him at bram [email protected].

AHMED E. HASSAN is the Canada

Research Chair in Software Analytics and the NSERC/BlackBerry Software Engineering Chair at the School of Computing at Queen’s University, Canada. His research interests include mining software repositories, empirical software engineering, load testing, and log mining. Hassan received a PhD in computer science from the University of Waterloo. He spearheaded the creation of the International Working Conference on Mining Software Repositories and its research community. He also serves on the editorial boards of IEEE Transactions on Software Engineering, Empirical Software Engineering, and Computing. Contact him at [email protected].

NOVEMBER /DECEMBER 2016

| IEEE

S O F T WA R E

91

FEATURE: MOBILE APPS

7th Int’l Workshop Trust in Agent Societies, 2004, pp. 106–117. 7. “See Your App’s Ratings & Reviews,” Google, 2013; http:// support.google.com/googleplay /android-developer/bin/answer .py?answer=138230. 8. D. Kellogg, “40 Percent of U.S. Mo-

bile Users Own Smartphones; 40 Percent are Android,” Nielsen, 2011; www.nielsen.com/us/en/insights /news/2011/40-percent-of-u-s-mobile -users-own-smartphones-40-percent -are-android.html. 9. C. Pettey and R. van der Meulen, “Gartner Says Free Apps Will Ac-

count for Nearly 90 Percent of Total Mobile App Store Downloads in 2012,” Gartner, 2012; www.gartner .com/it/page.jsp?id=2153215. 10. “Free vs. Paid Android Apps,” AppBrain, 2013; www.appbrain .com/stats/free-and-paid -android-applications.

CONFERENCES

in the Palm of Your Hand

IEEE Computer Society’s Conference Publishing Services (CPS) is now offering conference program mobile apps! Let your attendees have their conference schedule, conference information, and paper listings in the palm of their hands. The conference program mobile app works for Android devices, iPhone, iPad, and the Kindle Fire.

For more information please contact [email protected]

92

I E E E S O F T WA R E

|

W W W. C O M P U T E R . O R G / S O F T W A R E

|

@ I E E E S O F T WA R E

COMPUTER ENTREPRENEUR AWARD In 1982, on the occasion of its thirtieth anniversary, the IEEE Computer Society established the Computer Entrepreneur Award to recognize and honor the technical managers and entrepreneurial leaders who are responsible for the growth of some segment of the computer industry. The efforts must have taken place over fifteen years earlier, and the industry effects must be generally and openly visible. The award is a museum-quality sterling silver chalice commissioned from Washington DC artist Michael Schwartz. The gold-plated crown below the cup displays the alternating symbols of the IEEE and the Computer Society, supported by clusters of laurel leaves, an ancient symbol for outstanding achievement. All members of the profession are invited to nominate a colleague who they consider most

eligible to be considered for this award. Awarded to individuals whose entrepreneurial leadership is responsible for the growth of some segment of the computer industry.

DEADLINE FOR 2017 AWARD NOMINATIONS

DUE: 15 OCTOBER 2016

•

The award nomination requires a minimum of 3 endorsements

•

Presented at the highly acclaimed IEEE-CS Annual Awards Ceremony.

Past Recipients Include: Diane Greene, Mendel Rosenblum, Sandy Bosack, John Warnock, Charles Geschke, Michael Dell.

AWARD SITE: https://www.computer.org/web/awards/entrepreneur

www.computer.org/awards

THE PRAGMATIC ARCHITECT

Editor: Eoin Woods Endava [email protected]

Software Architecture in a Changing World Eoin Woods

NEARLY 25 YEARS ago, Dewayne Perry and Alexander Wolf’s seminal paper recognized software architecture as a distinct discipline1 —albeit one that’s changed considerably since then. Initially, software architecture focused on the basic problems of designing static software structures. Today, it must deal with global, always-on, Internetconnected systems with ever-evolving architectures. The software architect’s role has continued to evolve as well, perhaps to the point where everyone does some architectyre work. In this column, I trace this evolution and consider what it predicts about the future role of software systems architects.

We can identify five ages of software system evolution, each roughly aligning with a decade (see Figure 1). Through the 1980s, software systems were largely monolithic. They tended to run on single computers, whether large central mainframes with terminals or single-user PCs. Software was developed as “programs,” and architecture was largely a vendor concern, inherited from the platform the developers were using. Moving into the 1990s, distributed systems became mainstream, batch processing transitioned to online pro-

cessing, and the three-tier client-server architecture became standard for enterprise systems. This entailed more architectural decisions than before, but architectural style was still dictated largely by the vendors who supplied the development tools and system software. With the Internet established as a mainstream technology in the late 1990s, organizations needed Internetconnected systems that were “always on” rather than just “online.” These systems initially began as websites but gradually incorporated public UIs for business-to-consumer and business-tobusiness features. Thus, architecture now had to support unpredictable and challenging nonfunctional qualities (particularly performance, scalability, and security). Vendors’ main concern became supplying products, such as largescale servers and network load balancers for scalability or fi rewalls for security, to meet these challenges. Now in the 2010s, the Internet is a basic service. This has caused our systems to evolve again—from being “always on” to being “used from anywhere for anything”—they’re Internet-native systems in which the Internet is the system. These systems combine open source components, remote Internet-connected services, and custom code; in turn, their services become part of the Internet via

PUBLISHED BY THE IEEE COMPUTER SOCIETY

0740-7459/16/$33.00 © 2016 IEEE

The Five Ages of Software Systems

94

IEEE SOFTWARE

|

THE PRAGMATIC ARCHITECT

publicly accessible APIs. These systems need public APIs (rather than just public UIs), provide mobile UIs as their main UI, and use flexible architectural styles (notably microservices) to assemble systems from network-­ accessible services. With cloud computing’s emergence, vendors are concerned with supplying complete cloud-based application platforms, with many Internet systems being deployed to platforms as a service (PaaS) environments rather than traditional IT infrastructure. On the basis of current trends, the next phase of evolution appears to be intelligent connected systems. AI—particularly machine ­learning—is becoming mainstream, 2 and fast, reliable networks are becoming ubiquitous, letting us connect “things” to our systems, as well as to traditional computers.3 These systems will move beyond providing users with access anywhere to providing intelligent assistance. This will require a new architectural focus on data and algorithms as well as a move to “emergent” architecture that forms only at runtime. In this fifth era, “intelligence” will be a primary vendor concern because mainstream systems will use platforms that extend basic PaaS and Internet of Things (IoT) platforms with advanced services such as packaged machine-learning capabilities.

The Five Stages of Software Architecture Software architecture’s evolution has paralleled that of the software industry, with architects’ techniques and concerns changing in response to the changing challenges the industry has faced (see Figure 2). During the monolithic systems development stage, software architecture wasn’t a recognized discipline.

Distributed monoliths (1990s)

Internetconnected (2000s)

Intelligent connected (2020s)

Internet is the system (2010s)

Monolithic (1980s)

FIGURE 1. The evolution of software systems. Each age roughly aligns with a decade, beginning with the monolithic systems of the 1980s and moving toward intelligent connected systems.

Modules, information hiding, layering

Monolithic

+ Views, models, stakeholders, styles and patterns, assessment

Distributed

+ Quality attributes, agility, decisions

Internet-connected

+ Evolution, sustainability, principles

Internet native

+ ...?

Intelligent connected

FIGURE 2. The evolution of software architecture. Architects’ techniques and concerns continue to change in response to each stage’s software-engineering challenges. NOVEMBER/DECEMBER 2016

|

I E E E S O F T WA R E

95

THE PRAGMATIC ARCHITECT

Software Architecture’s Future Decreasing

Increasing

Structural design

Data and algorithm design

Defined structure

Emergent runtime structure

Decisions

Principles, policies, and algorithms

Certainty

Probability

Operational process Operational policy and automation Capex

Opex

FIGURE 3. Software architecture trends as we move into the era of intelligent connected systems. Capex: capital-expenditure biased; Opex: operational-expenditure biased.

However, pioneers were already thinking about large-scale software design. This led to structural design techniques such as using modules to structure large code bases and using information hiding to encapsulate state and isolate change.4 As technology moved to distributed systems, the increasingly complex systems and their environments led to complex design decision making that involved long-term tradeoffs. This resulted in software architecture’s recognition as a discipline and the introduction of techniques to deal with this more complex environment, such as • viewpoints and views for architectural description, 5 • new modeling techniques for architectural design, • explicit identification and management of stakeholders, • definition of proven and reusable architectural styles and patterns,6 and • architectural assessment techniques7 for structured comparison of architectural options. With Internet-connected systems came an architectural focus on • these systems’ challenging non96

I E E E S O F T WA R E

|

functional qualities (or “quality properties”) and how to achieve them;8 • the importance of well-made, clearly communicated architectural decisions;9 and • how architectural design could support the agility needed to make quick changes10 in response to the fast-moving, Internet-driven market. Today’s Internet-native systems are generally more malleable and dynamic, being composed from finegrained network services (microservices). Systems are often built on PaaS platforms and so can include a mix of platform services, other suppliers’ network-connected services, and the system’s own unique services. Thus, software architects are concerned with enabling the system’s rapid and reliable evolution. They also must ensure that the architecture is sustainable (and won’t ossify under a mountain of technical debt) and is defined more as a set of patterns and principles11 than as a static structure that remains stable for a long period. As we look toward a future in which intelligent connected systems will be norm, how will software architecture’s role change again?

W W W. C O M P U T E R . O R G / S O F T W A R E

|

Figure 3 lists trends likely to contribute to changes in the architect’s role as we move into the era of intelligent connected systems. Let’s explore each in a little more detail. Although structural design isn’t going away, the need to integrate dynamic architecture and intelligence into systems will make us reconsider the importance of data and algorithms. These topics don’t appear prominently in the software architecture literature (for example, the original 4+1 viewpoint set had no data or information view 12). However, when a system needs to be dynamic and intelligent, data and algorithms become important system-wide architectural concerns. Another trend is structures moving away from being defined up front through architectural design to being defined at runtime by combining many network services to form a system. This is quite different from the “emergent architecture” that some agile practitioners discuss—they’re referring to the conventional, static architecture that develops incrementally as a project progresses and more information becomes available. Instead, this trend focuses on architectural structure that’s apparent only at runtime because of the services’ dynamic composition. Another recent development is architects acting less as up-front structure designers and more as overseers of a stream of informed, significant decisions made just in time for the project.13 Even this practice will likely be affected by the challenges of intelligent connected systems. Although structural decisions will remain important, these dynamic systems will

@ I E E E S O F T WA R E

THE PRAGMATIC ARCHITECT

demand greater focus on principles that guide their structure and evolution, policies that control their runtime behavior (for example, Microsoft Azure’s autoscaling guidance; https://azure.microsoft.com /en-us/documentation/articles/best -practices-auto-scaling), and, in some cases, algorithms that govern their dynamic evolution. Combined, these factors mean that software architects will more often deal with probability than certainty (or an assumption of certainty). Factors such as composing systems from third-party services, using machine learning and analytics in system design, integrating many small (IoT) devices, and using dynamic runtime environments such as PaaS platforms imply that architecture will involve statistical characteristics and trends more than static structures and definite quantities. Our systems’ operational aspects will also evolve, affecting architecture practice. Today, architects might well be involved in defining and advising on operational processes. Tomorrow, large dynamic systems will require policy-driven automation rather than carefully designed stepby-step processes, whether automated or manual. Finally, architecture is very much the “art of the possible”—so financial constraints can limit or enable architectural decisions. As we move toward cloud-hosted systems, usage-­ based pricing for platforms and services and policy-driven (rather than statically defined) systems will push our financial models and budgets from capital-expenditure biased (Capex) to operational-expenditure biased (Opex). This implies that architects might be having many more conversations with accountants than they’re used to.

A

s software systems have evolved, so has software architecture, with practices growing to meet each era’s new challenges. Architecture is now an implicit part of mainstream practice. It’s often seen as an activity rather than a distinct role, focusing more on decisions and principles than on definitions. Software evolution’s next phase looks even more radical. Intelligent dynamic composition, cloud platform deployment, and the connection of “things” to mainstream systems guarantee an exciting future for software architects everywhere.

References 1. D.E. Perry and A.L. Wolf, “Foundations for the Study of Software Architecture,” ACM SIGSOFT Software Eng. Notes, vol. 17, no. 4, 1992, pp. 40–52. 2. “Amazon Machine Learning,” Amazon Web Services, 2016; https://aws .amazon.com/machine-learning. 3. G. Kortuem et al., “Smart Objects as Building Blocks for the Internet of Things,” IEEE Internet Computing, vol. 14, no. 1, 2010, pp. 44–51. 4. D.L. Parnas, “On the Criteria to Be Used in Decomposing Systems into Modules,” Comm. ACM, vol. 15, no. 12, 1972, pp. 1053–1058. 5. “Systems and Software Engineering—­ Architecture Description,” Int’l Org. for Standardization, Int’l Electrotech-

nical Commission, and IEEE, 2011; www.iso-architecture.org/ieee-1471. 6. D. Garlan and M. Shaw, An Introduction to Software Architecture, School of Computer Science, Carnegie Mellon Univ., 1994. 7. P. Clements, R. Kazman, and M. Klein, Evaluating Software Architectures: Methods and Case Studies, Addison-Wesley, 2002. 8. E. Woods and N. Rozanski, “Using Architectural Perspectives,” Proc. 5th Working IEEE/IFIP Conf. Software Architecture (WICSA 05), 2005, pp. 25–35; doi:10.1109/WICSA.2005.74. 9. J. Tyree and A. Akerman, “Architecture Decisions: Demystifying Architecture,” IEEE Software, vol. 22, no. 2, 2005, pp. 19–27. 10. P. Abrahamsson, M. Babar, and P. Kruchten, “Agility and Architecture: Can They Coexist?,” IEEE Software, vol. 27, no. 2, 2010, pp. 16–22. 11. E. Woods, “Harnessing the Power of Architectural Design Principles,” IEEE Software, vol. 33, no. 4, 2016, pp. 15–17. 12. P. Kruchten, “The 4+1 View Model of Architecture,” IEEE Software, vol. 12, no. 6, 1995, pp. 42–50. 13. E.R. Poort, “Driving Agile Architecting with Cost and Risk,” IEEE Software, vol. 31, no. 5, 2014, pp. 20–23.

EOIN WOODS is the chief technology officer at

Endava. Contact him at [email protected].

Technology Solutions for the Enterprise

www.computer.org/itpro

NOVEMBER/DECEMBER 2016

|

I E E E S O F T WA R E

97

RELIABLE CODE

Editor: Gerard J. Holzmann NASA/JPL [email protected]

Hi Maintenance Gerard J. Holzmann

IT HAS OFTEN been pointed out that measuring programmer productivity by the number of lines of code produced per unit of time is dubious. Measuring code quality by the comment-to-code ratio is similarly unhelpful. So, why are these metrics so bad? Clearly, it’s easy for programmers to increase their performance on these metrics by producing unnecessarily bloated code littered with uninformative comments. This effect is known as Goodhart’s law, which says that “When a measure becomes a target, it ceases to be a good measure.” Debugging or maintaining bloated code can be a nightmare. The unfortunate souls asked to fi x it years later will have a hard time reconstructing what pattern of thought led to its creation. Curiously, bloated and badly written code tends to live longer than wellwritten code. If you can’t understand how or why some code works, you’re much less likely to change it. After all, the golden rule of code maintenance is, if it ain’t broke, don’t fi x it.

Code Bloat Another reason why simplistic code metrics are so unhelpful is that really good programmers tend to write very concise code that doesn’t need many explanatory comments. So, it’s mostly 98

IEEE SOFTWARE

|

PUBLISHED BY THE IEEE COMPUTER SOCIETY

the bad code that will score well on these metrics. As is often the case, it’s easier to spot the absence of code quality than its presence. As part of my job, I have to review a lot of code. In doing so, I try to leverage the use of automatic code analysis tools as much as possible. But even the best analyzers are of little help when you want to fi nd code that’s likely to incur the highest maintenance costs. High-maintenance code not only is verbose but also tends to rely on unstated, poorly stated, or incompletely stated assumptions. If you want to understand that type of code, you need long chains of reasoning to figure out how and why it works, and under which conditions it could start failing when other parts of the system are updated. The reliance on hidden assumptions is probably the most telling feature of high-maintenance code. So let’s look at this in a little more detail.

Hidden Assumptions As a very simple example, consider the following declaration of an array I came across when reviewing a critical piece of embedded C code (though with the names changed): #define MAX_BUF 28 char buf[MAX_BUF*2 + 1]; 0740-7459/16/$33.00 © 2016 IEEE

RELIABLE CODE

A comment at the declaration explained helpfully that the array was fixed to the given size “because of display limitations.” Presumably, the text stored in this buffer was going to be displayed at some point or retrieved from a display entry box. The comment didn’t explain if the limitation would prevent more than the given number of characters from ever being stored into that array. It also didn’t explain if the display couldn’t render more than the given number of characters anyway when the text was going to be written to that display. To determine these things first meant hunting down all uses of the array and all the possible sources that could produce the input. Next, it meant checking whether safeguards were in place to prevent that any changes made elsewhere later in the code’s evolution would be consistent with the assumptions implicit in this part of the code. The macro MAX_BUF introduces a number that seems to depend critically on some other quantity related to the display width that might be defined in some other module. You can avoid the dependency, and thus reduce the risk of

mistakes, by using that original limit, and not a derived value, directly in the array declaration. Later in the function in which this declaration was placed, the library function strcpy was used to fill the array, using a character pointer passed into the function as an argument. I’ll call that argument param here: if (strlen(param) > 0) strcpy(buf, param); It would be fair to complain about the poor formatting and the lack of curly braces around the body of the if statement, which could have helped make the code a little easier to read, but we have bigger fish to fry here. The developer tried to ensure that a zero-length string wouldn’t be copied. That’s very considerate, of course, but what if the param pointer is null or points to a longer string that the target buffer can accommodate? To check that this can’t happen again sends us hunting through the surrounding code. We can avoid all this by adding an assertion explicitly stating that these conditions can never happen: assert( param && strlen(param) < sizeof(buf) );

I use sizeof here instead of comparing against the size from the array declaration, to protect this piece of new code from future changes in the declaration of the buf array. Who knows, that could happen if the system this code is part of ends up being so profitable that the company can afford to switch to larger displays. For every design parameter like this, we want to ensure that the code contains a “single point of truth.” That is, there’s only one point in the code at which you can make a change without having to chase down all its hidden dependencies. Of course, you also should never use unsafe functions such as strcpy but switch to the safer strncpy, or strlcpy if it’s available. But we’re not done. A few lines later in the function, the contents of buf were updated, independently of the length of param, with a call to the library routine sprintf, again ignoring its more well-behaved sibling snprintf. The call looked like this: sprintf( buf, “%s%c”, buf, ch ); Your alarm bells should now be ringing loud and clear. First, the developer made an unjustified

NOVEMBER/DECEMBER 2016

|

I E E E S O F T WA R E

99

RELIABLE CODE

.

memcpy

+

strcpy

(

x:@ident

sprintf

,

+

:x

+

)

.

FIGURE 1. A nondeterministic finite-state automaton for the Cobra token expression [memcpy strcpy sprint] \( x:@ident , .* :x .* \). This automaton performs matching searches for strcpy, memcpy, and sprintf.

a­ ssumption about how sprintf is implemented, passing it the same array as both a source and a destination of the operation. This is a roll of the dice because the C standard explicitly states that the result of such a call is formally undefined. Another concern is that, because the code didn’t check whether the array was updated or left unchanged in the earlier conditional call to strcpy, even a correct execution of sprintf to append a single character to the end of buf now risks overflowing the array when it repeats enough times. Cybercriminals know how to exploit this type of vulnerability. But even if this code wasn’t a security vulnerability, it’s just plain bad, unnecessarily highmaintenance, code.

Token Patterns If you have to review this code and you see a careless statement such as the sprintf call I just mentioned, you’ll immediately want to check for other update operations in which the source and destination might overlap. Here, it’s useful to have some tools at your disposal. The Unix tool grep can easily collect all calls to routines such as sprintf, strcpy, and memcpy. But that will likely give you much more output than you need, requir100

I E E E S O F T WA R E

|

ing far too much additional work to separate the wheat from the chaff. In cases such as these, a simple tokenizer, such as the ctok tool I discussed in an earlier column,1 with a small back end, can prove invaluable. For instance, here’s how we can do a more appropriate pattern search with the Cobra tool, which is based on the same principles:2 $ cobra –re ‘sprintf \( x:@ident , .* :x .* \)’ *.c I used the Cobra tool here to match a token expression in the input. A token expression is a regular expression that’s defined not over strings of characters, like most regular expressions, but over a sequence of lexical tokens. By default, the tool will try to match the literal text of a token, but you can also ask it to match a token type by preceding the text with the @ symbol. In the previous expression, the identifier name sprintf must be matched exactly in the source code. It is to be followed by an opening parenthesis, which has an escape character in front of it to distinguish it from the corresponding regular expression metacharacter for grouping. Next, the token expression is asked to match any identifier name and store its text in a variable I named x (the

W W W. C O M P U T E R . O R G / S O F T W A R E

|

name is, of course, arbitrary). This variable-binding operation lets us refer back to that same bound variable later in the expression. The next lexical token to be matched is a comma, which is followed by a sequence of tokens we don’t care about unless it includes a second instance of the bound variable anywhere before the matching closing parenthesis. Cobra ensures that parentheses, braces, and brackets are always matched correctly in token expressions. So, we’re guaranteed to be checking precisely (and only) the full parameter list of calls to sprintf with this expression. The token expression isn’t sensitive to white space, so it doesn’t matter whether the calls to sprintf that we’re trying to find span multiple lines of text in the source code. In this case, we’re looking just for uses of sprintf that violate the rules; we can, of course, do matching searches for calls to strcpy, memcpy, and so on. We can also specify all these candidate function names in a single token range in brackets, and use that in the expression. Figure 1 shows the nondeterministic finite-state automaton that’s generated from an expression that performs that search.

Writing Low-Maintenance Code To write concise, readable, and lowmaintenance code requires practice, but it helps to look at examples. This is similar to learning to write good prose. For good reason, Steven Pinker titled a chapter “Reverse-Engineering Good Prose as the Key to Developing a Writerly Ear” in The Sense of Style, his recent book on writing.3 When I implemented the code for processing token expressions in the Cobra tool, I first looked at existing algorithms for converting regular expressions to automata. This class

@ I E E E S O F T WA R E

RELIABLE CODE

of algorithms is so fundamental that trying to invent a new version from scratch would be foolish. I also expected that the most recent versions would be the best. Surprisingly, that wasn’t the case. A few years ago, Russ Cox wrote an excellent blog entry on existing implementations of regular expression conversion algorithms.4 He showed a significant difference in performance between recent implementations in Java, Perl, PHP, Python, and Ruby and the by-nowancient Unix code, still available in tools such as grep and awk. The older code turns out to be much faster. Cox explained how the difference in performance can grow to orders of magnitude for longer expressions. The older code is based on an algorithm that Ken Thompson invented when he implemented regular expressions for the line editor ed. As you probably know, the command name grep is an abbreviation of the ed command g/re/p for globally finding and printing all matches for a given regular expression re.

Dreaming in Code The paper describing Thompson’s algorithm appeared in 1968,5 shortly after Ken joined Bell Labs. I decided to use that algorithm as the foundation for the Cobra implementation, if only just to learn from how it was designed. The 1968 paper turns out to be an absolute gem. It manages to describe the algorithm in crystal-clear prose in just four pages, including five figures illustrating the main steps. Thompson’s algorithm simulates the execution of a nondeterministic finite-state automaton generated from a postfix version of the regular expression. The conversion is decomposed into a small number of steps that can each be implemented in a

straightforward way that requires almost no additional explanation. Perhaps this is the way we can understand how good code is born. It starts not with the code itself but with developing a really good understanding of the problem to be solved. I suspect that it also depends on the ability to visualize a problem and its possible solutions, before you start writing code. Who hasn’t had the experience of suddenly “seeing” the solution to a difficult coding problem as you’re about to fall asleep at night? Is that a skill that could be developed and taught? I think I’ll have to sleep on that. References

2. G.J. Holzmann, “Cobra: A LightWeight Tool for Static and Dynamic Program Analysis,” Innovations in Systems and Software Eng., 1 June 2016, pp. 1–15; http://link.springer .com/article/10.1007/s11334-016 -0282-x. 3. S. Pinker, The Sense of Style, Viking, 2014. 4. R. Cox, “Regular Expression Matching Can Be Simple and Fast,” Jan. 2007; https://swtch.com/~rsc/regexp /regexp1.html. 5. K. Thompson, “Regular Expression Search Algorithm,” Comm. ACM, vol. 11, no. 6, 1968, pp. 419–422.

GERARD J. HOLZMANN works at the Jet

1. G.J. Holzmann, “Tiny Tools,” IEEE Software, vol. 33, no. 1, 2016, pp. 24–28.

Propulsion Laboratory on developing stronger methods for software analysis, code review, and testing. Contact him at [email protected].

On Computing podcast

www.computer.org/oncomputing

NOVEMBER/DECEMBER 2016

|

I E E E S O F T WA R E

101

SOUNDING REQUIREMENTS BOARD

Editor: Editor: Jane Philippe Cleland-Huang Kruchten DePaul University University of British Columbia [email protected] [email protected]

The Tragedy of Defect Prediction, Prince of Empirical Software Engineering Research Michele Lanza, Andrea Mocci, and Luca Ponzanelli

IF MEASURED BY the number of published papers, defect prediction has become an important research field over the past decade, with many researchers continuously proposing novel approaches to predict defects in software systems. However, most of these approaches have had a noticeable lack of impact on industrial practice. We believe that the impact isn’t there because something is intrinsically wrong in how defect prediction approaches are evaluated.

In this case, Denmark isn’t a Scandinavian country—it’s the research field called defect prediction. We reflect on what we consider its intrinsic conceptual flaw. This flaw pertains not only to defect prediction but also to other research fields with which defect prediction shares a peculiar commonality. As you’ll see, this commonality pertains to the infamous evaluation that has become a necessary evil of modern software engineering research.

We’re heading into dangerous territory here, so we’d better take this one step at a time. First, what is defect prediction? Defect prediction deals with the creation and empirical evaluation of approaches to know or estimate in advance where defects will appear in a system. The earliest approaches, devised in the 1980s, used simple regression models based on software metrics.1 Since then, the field has seen the invention of a staggering number of novel and more refi ned approaches. This was especially the case during the rise of the research field of mining software repositories, which in turn gave birth to what some people called “empirical software engineering 2.0.” Our goal isn’t to criticize empirical software engineering as a whole, which has many reasons to exist. However, defect prediction is an archetypal example of empirical software engineering research where in the middle of the many trees that need to be felled, the research community has lost sight of the forest. This is especially true concerning the evaluation of novel approaches, which seems to have surpassed the actual technical core of any approach in terms of importance and acceptance.

PUBLISHED BY THE IEEE COMPUTER SOCIETY

0740-7459/16/$33.00 © 2016 IEEE

Act I: Empirical Quicksand Something is rotten in the state of Denmark —Shakespeare, The Tragedy of Hamlet, Prince of Denmark, act I, scene 4

102

IEEE SOFTWARE

|

SOUNDING BOARD

If you survey the many publications on defect prediction, it’s hard not to notice how important the evaluation is, filled with precision and recall percentages, p-values, and other success metrics. What’s wrong with that, you might ask? Indeed, we don’t argue against evaluating such approaches; quite the contrary. But we do maintain that the de facto way of evaluating them is intrinsically flawed. A tiny spoiler: “If my calculations are correct, when this baby hits 88 miles per hour, you’re gonna see some serious ****.”

Act II: Small-Scale Utopia Assume for a second that the world is perfect (except for the existence of software bugs). In such a world, a bug consists of a specific software change, which leads to a defect, which someone then reports through a bug report. In reaction to the reported bug, a developer provides a fix, effectively closing the process. This process is not only a simplification but also an idealization.

The actual process is much more complex and probably never assumes the form we describe here. For example, the typical bug report life cycle allows loops to happen when bugs get reopened. However, several defect prediction approaches rely on this simplified process, and for the sake of our thought experiment, we assume this process too. The pieces of that assumption that are important for validating defect prediction approaches are primarily the bug report and secondarily the change and fix. This is because the report is the actual artifact that can be mined with ease from issue tracker repositories and because the change and the fix can be recovered—with some effort—from the versioning system. (An intriguing conceptual question pertains to the defect itself. In reality, defect prediction approaches are validated not on the actual defects but on the creation of bug reports. In short, from the perspective of defect prediction evaluation, if

there’s no bug report, there’s no bug.) We now take this process and turn it into the (admittedly abstract) concept of “a bug,” ignoring its internal details. We do this to widen the context in the next act.

Act III: Large-Scale Dystopia When researchers evaluate defect prediction approaches, they use as ground truth the “past”—all the bugs reported during a reference time period. The present is placed into the past (which thus becomes a new present), and the predictor is run into the future, which in reality is the past as seen from the actual present. Defect prediction approaches now try, irrespective of their underlying technicalities, to predict where (for example, in which class or module) defects will appear. To do so, they use the fix that was a response to the bug report and establish which parts of the system changed during the fix. If those parts match the predicted part of the system, the predictor worked correctly.

NOVEMBER/DECEMBER 2016

|

I E E E S O F T WA R E

103

SOUNDING BOARD

(Someone could point out that establishing what changed during a fi x, and whether all those changes were a “response” to the bug report, isn’t an exact science and is often based on [imprecise] heuristics.) The evaluation process allows for an easy way to measure defect prediction approaches’ performance— for example, using such common metrics as precision, recall, and Fmeasures. On the basis of those metrics, the approaches are then compared to each other. (It’s still sad but true that few usable benchmark datasets exist, so

In other words, if a defect predictor predicted a bug in a particular area of the system, a developer would look at that area. However, this simple reaction has an influence, and potentially a cascading effect, on anything that follows in time. Of course, you might ask, aren’t we pointing out the obvious here? Indeed: a useful recommender must have some impact on a system’s evolution. Well, here’s the problem. As we mentioned before, defect prediction approaches are evaluated on the past history of a system’s bugs, where that history is treated as the

Act IV: 88 MPH If a predictor were put into production as an in vivo tool, it would produce recommendations. Developers would see these recommendations, which would influence and (hopefully) significantly affect what they do from that moment on. 104

I E E E S O F T WA R E

|

future. In essence, the predictors are being evaluated in a way equivalent to the situation in which they act as if developers will completely ignore them. But, if the point of an approach (that is, research) is to have some impact on a system (that is, the real world), doesn’t this contradict that goal? If a predictor correctly predicted a bug, that recommendation would impact any subsequent bug and might produce unexpected consequences. Two possibilities are that subsequent bugs either don’t appear where they previously appeared or don’t appear at all. In essence (apologies for the upcoming high-flying wording), a real prediction perturbs the space–time continuum. Let’s fly at a lower altitude, so to speak. Bugs are causally connected

W W W. C O M P U T E R . O R G / S O F T W A R E

|

The evaluation of defect prediction approaches using a system’s bug history is intrinsically flawed.

Tying back to the spoiler: defect prediction approaches are evaluated using the fading-picture metaphor from the movie Back to the Future. Although the movie is very nice, its time travel logic is full of evident paradoxes.

Act V: The Angel’s Advocate

The evaluation of defect prediction approaches using a system’s bug history is intrinsically flawed.

any comparison between different approaches on diverse datasets is an apples-and-oranges comparison with little validity.) So far, so good. So what? The problem is that software is developed by humans, and more important, it evolves. Any decision in the system—for example, a bug fi x or any other change—impacts, directly or indirectly, future decisions over the development time. And time is the keyword for our next act.

because software is produced by humans, and if they’re doing something, they’re not doing something else. Short of supporting the theory of parallel universes, the main message is this:

Because the devil’s advocate seems to be a coauthor of this article, we summon the help of the angel’s advocate, who dislikes what we claim. “Not all bugs are causally connected: your base assumption is wrong. If two bugs reside in very distant parts of a system and aren’t structurally related, they have no causal connection whatsoever.” We concede that if two bugs appear at very close points in time in very distant parts of the system, they might have no causal connection. However, given enough time distance, even bugs that are far from each other and aren’t structurally related are causally connected because software is developed by humans who follow a process. “If a defect prediction approach uses only the code’s structural properties, you can ignore or factor out the recommendations’ impact on the system’s evolution.” Indeed, if the recommendations are based on only an entity’s structural properties, the impact of the system’s evolution on the code met-

@ I E E E S O F T WA R E

SOUNDING BOARD

rics can be factored out. In fact, the more the predictor recommends the entities that have been really fixed, the more the predicted evolution resembles the one that was observed in the system. However, current approaches don’t rely only on purely structural metrics. If we consider Marco D’Ambros and his colleagues’ study, 2 process metrics actually exhibit the best performance and lowest variability, outperforming other metrics based on source code. This is because process metrics are intrinsically evolutionary and are thus strongly influenced by any change of the development process itself. “You’re wrong; a simple n-fold cross validation on the bug dataset is enough to do away with all this time-traveling nonsense.” Such cross validation can’t take into account the defect predictor’s potential impact on the system. In other words, recombining the training and testing datasets with n-fold cross validation won’t help you reconstruct the defect predictor’s potential impact on the system by simulating the changes that such a recommender would make. Without an in vivo adoption, you simply can’t measure the predictor’s effect. “Wait; if you did defect prediction research yourself, aren’t you biting the hand that fed you?” Yes, we are. We don’t deny that, nor do we regret it. Some of our most impactful (that is, cited) papers are in that area. Back in those days, we believed that was the way to do things. This insight of ours came only recently, but hey, better late than never.

Epilog Although this article’s tone isn’t exactly serious, the point we’re making is a serious and honest criticism

of how defect prediction approaches have been evaluated all these years. We reiterate that we’re not criticizing defect prediction approaches per se. In fact, many approaches are based on sound, meaningful assumptions. These are some well-known conjectures formulated by researchers: bugs might appear in parts of the system where bugs have already occurred, 3 in parts that change frequently,4 or where complex changes have been performed.5 These conjectures are clearly reasonable and well founded, and it’s interesting to investigate them to prove or disprove them. In the end, the overall goal has been and remains to advance the state of the art and the software engineering discipline, in which the engineering is to be considered as a set of proven best practices. The problem isn’t the approaches. The problem lies in how the approaches are evaluated and how they’re being compared to each other. The unpleasant truth is that a field such as defect prediction makes sense only if it’s used in vivo. In other words, researchers should seriously consider putting their predictors out into the real world and having them used by developers who work on a live code base. Of course, this comes at a high cost. But then again, consider that if a predictor manages to correctly predict one single bug, this will have a real, concrete impact. That’s more than can be said about any approach relying on in vitro validation, no matter how extensive.

2. M. D’Ambros, M. Lanza, and R. Robbes, “Evaluating Defect Prediction Approaches: A Benchmark and an Extensive Comparison,” Empirical Software Eng., vol. 17, nos. 4–5, 2012, pp. 531–577. 3. S. Kim et al., “Predicting Faults from Cached History,” Proc. 29th Int’l Conf. Software Eng. (ICSE 07), 2007, pp. 489–498. 4. N. Nagappan and T. Ball, “Use of Relative Code Churn Measures to Predict System Defect Density,” Proc. 27th Int’l Conf. Software Eng. (ICSE 05), 2005, pp. 284–292. 5. A.E. Hassan, “Predicting Faults Using the Complexity of Code Changes,” Proc. 31st Int’l Conf. Software Eng. (ICSE 09), 2009, pp. 78–88. MICHELE LANZA is a full professor and the

head of the REVEAL (Reverse Engineering, Visualization, Evolution Analysis Lab) research group at the Università della Svizzera italiana. Contact him at [email protected]. ANDREA MOCCI is a postdoctoral researcher in the REVEAL research group at the Università della Svizzera italiana. Contact him at andrea​ [email protected]. LUCA PONZANELLI is a PhD student in infor-

matics and a member of the REVEAL research group at the Università della Svizzera italiana. Contact him at [email protected].

References 1. V.Y. Shen et al., “Identifying ErrorProne Software: An Empirical Study,” IEEE Trans. Software Eng., vol. 11, no. 4, 1985, pp. 317–324.

Selected CS articles and columns are also available for free at http://ComputingNow.computer.org.

NOVEMBER/DECEMBER 2016

|

I E E E S O F T WA R E

105

VOICE OF EVIDENCE

Editor: Rafael Prikladnicki Pontifica Universidade Catolica do Rio Grande do Sul [email protected]

ADAPT A Framework for Agile Distributed Software Development Raoul Vallon, Stefan Strobl, Mario Bernhart, Rafael Prikladnicki, and Thomas Grechenig

AGILE DEVELOPMENT and distributed software development (DSD) seem like an impossible match. Agile processes are designed for collocated teams collaborating closely, which appears incompatible with DSD and its inherent coordination, control, and communication challenges.1 Nonetheless, 82 percent of respondents to VersionOne Inc.’s 10th Annual State of Agile survey, conducted in 2015, said they had at least some distributed teams practicing agile development, a significant rise from only 35 percent just three years earlier.2 To gather evidence about the past and current state of research on teams using both agile and distributed development, three of us conducted a systematic literature review of the topic covering 1999 to 2014. (For the review protocol, see the Web extra at https://extras . c o m p u t e r . o r g / e x t r a / m s o 2 0 16 0 6 0106s1.pdf.) We found an increasing interest in applying agile practices to DSD from 2004 in the form of anecdotal experience reports and from 2010 in the form of evaluation papers, mainly case studies that indicated a switch to more rigorous research approaches. However, past research seldom fully reported contextual details, omitting information such as team size, thus limiting the results’ generalizability. In response, we created a checklist for 106

IEEE SOFTWARE

|

PUBLISHED BY THE IEEE COMPUTER SOCIETY

fully reporting the empirical context of case studies on agile DSD, as well as general information about projects. (For the checklist, see the Web extra at https://extras.computer.org/extra/mso 2016060106s2.pdf.) Also, although past research reported lessons learned in agile DSD, no one has created a comprehensive framework describing how to apply agile practices to DSD to which both researchers and industrial practitioners can relate. We launched our multiyear research project primarily to create such a framework— ADAPT (Agile Distributed Adaptable Process Toolkit).

Evidence from a Multiple-Case Study We studied multiple cases to generate ADAPT’s empirical base. We included selected Scrum-based cases to pre sent the state of the industry because we found that most reported cases in the past 15 years used either Scrum or Scrum with Extreme Programming. We selected the following heterogeneous, information-rich cases 3 to produce stronger results: 4 • Case CrossTown—two development sites in the same city (Vienna) • Case NoTimeshift—two sites in the same country (Austria) 0740-7459/16/$33.00 © 2016 IEEE

TABLE 1

VOICE OF EVIDENCE

Contextual information about the three cases in the ADAPT (Agile Distributed Adaptable Process Toolkit) study. Case Topic

Contextual details

CrossTown

NoTimeshift

Continental

Distribution details

Location

Onshore

Onshore

Offshore

Insourcing or outsourcing

Insourcing

Outsourcing

Insourcing

Geographic distance

Near

Near

Near

Time-zone difference

None

None

Small

Sociocultural distance

None

None

Low

Supplier location

Austria

Austria

3 European countries

Customer location

Austria

Germany

1 European country

No. of sites

2

2

3

Team distribution

Integrated teams

Integrated teams

Isolated teams

Domain

Web and hardware

Enterprise software

Web

Experience with distributed software development

10 years

2 years

15 years

Team size

Overall: 19 Site 1: 13 Site 2: 6

Overall: 30 Site 1: 20 Site 2: 10

Overall: 39 Site 1: 14 Site 2: 19 Site 3: 6

Duration

15 mos.

6 mos.

9 mos.

Type

Industry

Industry

Industry

Successful

Yes

Yes

Yes

Agile experience

7 years

3 years

3 years

Agile process

Scrum

Scrum

Mixed

Agility level

All teams

All teams

All teams

Project details

Agile details

• Case Continental—three sites in the same continent (Europe) Our checklist (see Table 1) drove our data collection to ensure reporting of a complete contextual picture. For each case, we first conducted an analysis resulting in sets of candidate guidelines for eliminating the challenges that agile DSD faces (15

derived from CrossTown, 22 from NoTimeshift, and 12 from Continental) and recommended candidate development-­team practices (40 from CrossTown, 35 from N ­ oTimeshift, and 19 from Continental). We combined the candidate guidelines and practices to create empirically stronger versions by either identifying duplicates or com-

bining those that address variations of the same basic theme. We then linked practices to guidelines they could help implement and linked each guideline to the one challenge it could help mitigate. Table 2 shows these linkages. (For a schematic of the case study design, see the Web extra at https://extras.computer.org /extra/mso2016060106s3.pdf.)

NOVEMBER/DECEMBER 2016

|

I E E E S O F T WA R E

107

TABLE 2

VOICE OF EVIDENCE

In ADAPT, the guidelines (G1– G10) are linked to the challenges they mitigate. Coordination challenges

G1. Strive for all sites’ equal involvement.

Practice P1. Traveling ambassador

G2. Let longlived crossfunctional teams selforganize.

✓

G4. Use a retrospective as a driver for continuous improvement.

✓

P2. Full-team onsite sessions P3. Team rotations

G3. Establish knowledge and information flow between sites.

✓ ✓

✓

P4. Team events

✓

P5. Scrum master on each site

✓

P6. Cross-site reviews P7. Multiway informal communication

✓

P8. Meeting minutes

✓ ✓

✓

P9. Ad hoc screen sharing P10. Synchronized sprints

✓

P11. Accessible backlogs

✓

P12. Tangible requirements (behavior-driven development)

✓

P13. Customer requirements workshop

✓

P14. Feature-team organization

✓

P15. Multiteam workflow board P16. Multilevel onsite proxy planning

✓

P17. Separation of roadmap and sprint planning

✓

✓

P18. Onsite retrospective with proxies

✓

P19. Onsite sprint review with proxies P20. Establish metrics to evaluate the process

✓

P21. Daily intrateam communication

✓

P22. Interteam scrum of scrums

✓

P23. Frequent deployments to customer P24. On-demand specification meetings

✓

P25. Cross-team specialist meeting P26. Global all-site broadcast meeting

✓ ✓

✓

P27. User story requirements

✓

P28. Code quality and standards

✓

P29. Agile coach * A checkmark means the indicated practice helps implement the guideline.

108

I E E E S O F T WA R E

|

W W W. C O M P U T E R . O R G / S O F T W A R E

|

@ I E E E S O F T WA R E

VOICE OF EVIDENCE

Control challenges

G5. Truthfully visualize all sites’ workflow.

Communication challenges

G6. Invite the customer in with frequent releases.

G7. Embrace quality over feature rush.

G8. Build a tool chain to support agile practices.

G9. Establish multilevel, multiconcern feedback loops.

✓

G10. Step by step, create an environment in which agile can work.

✓

✓

✓

✓ ✓

✓

✓

✓

✓ ✓ ✓

✓ ✓

✓

✓

✓ ✓ ✓

✓ ✓ ✓ ✓

✓

✓

✓

✓ ✓

✓ ✓ ✓



NOVEMBER/DECEMBER 2016

|

I E E E S O F T WA R E

109

VOICE OF EVIDENCE

Control, communication

A

P6

Cross-site reviews

Linked guidelines: G5, G7, G9 Cross-site reviews foster intersite information exchange and knowledge transfer

FIGURE 1. This practice card illustrates practice P6, “Cross-site reviews,” in which developers at one site review code or other artifacts such as test cases from another site. This helps transfer knowledge between sites and improves software quality. Each card shows the practice identifier (in this case, P6), title (Cross-site reviews), the challenges the practice mitigates (control, communication), the guidelines it helps implement (G5, G7, G9), a one-line description, and an icon.

Evolving the Method For practitioners, ADAPT provides in-depth descriptions of each practice and guideline. For researchers, it thoroughly documents how we developed the framework. As part of this effort, we designed practice cards (Figure 1 shows an example) to be used in kickoff workshops and retrospective meetings in which developers work on practices critical to satisfying specific guidelines. We completed ADAPT’s design theory5 during coauthor Raoul Vallon’s four-month visit to Stanford University’s Center for Design Research, and we plan future iterations. Five testable propositions 110

I E E E S O F T WA R E

|

(TPs) describe the nature of current and future iterations: • TP1—The framework’s guidelines and practices are grounded in empirical evidence. • TP2—The framework allows simple, pragmatic, and iterative process tailoring. • TP3—The framework supports project-based process tailoring, making it useful in different situations. • TP4—The framework provides tangible, detailed advice to practitioners. • TP5—The framework is easily extensible for future modifications. The propositions enable the framework to scale while remaining true to its origins and intended design.

Using ADAPT ADAPT lets developers tailor the process implementation ­step-by-step to a project’s constraints. This capability also lets teams cope with changing constraints throughout a project’s life, such as a development site’s addition or removal. Table 2 shows the full ADAPT framework with the three categories of challenges spanning 10 guidelines and 29 practices. Developers can use it when they set up a new process implementation for a project in a DSD environment or add it to ongoing efforts. They can use it to tailor the selection of agile practices to project constraints via a continuous threestep cycle. First, developers refer to the ADAPT guidelines to find suitable linked practices to add for the next sprint iteration to address all the guidelines. A new process implementation should have at least one prac-

W W W. C O M P U T E R . O R G / S O F T W A R E

|

tice per guideline. It’s better to use fewer practices per guideline at the beginning of the process. Second, the developers conduct the sprint iteration and then collect data to evaluate the practices’ effectiveness via, for example, burn-down charts, bug counts, or lead time. Third, the developers evaluate the data and reflect on the process implementation as a team during, for example, a retrospective. Then, they start over with the first step but now consider adding, modifying, or removing practices while trying to balance the coordination, control, and communication challenges.

W

e evaluated the current guidelines and practices via interviews with 10 industrial and academic experts from Austria, Finland, Germany, and the US. Table 3 shows the results. The response was positive. We’re still working on several aspects of the framework such as scalability, usability, and practitioner utility. We regard ADAPT as an important step in creating a common foundation for implementing agile DSD projects. We invite practitioners to test it and provide feedback, and we ask researchers to help extend the framework.

References 1. E. Carmel and R. Agarwal, “Tactical Approaches for Alleviating Distance in Global Software Development,” IEEE Software, vol. 18, no. 2, 2001, pp. 22–29. 2. 10th Annual State of Agile Report, VersionOne, 11 July 2016; http:// stateofagile.versionone.com. 3. M.Q. Patton, Qualitative Research and Evaluation Methods, Sage Publications, 2002.

@ I E E E S O F T WA R E

TABLE 3

VOICE OF EVIDENCE

Feedback on ADAPT from 10 interviews with industrial and academic experts. General interviewee response Approval

Improvements needed

Issue

Summarized feedback

Interviewees

Testable propositions and research approach

ADAPT was adaptable, easily extensible, tangible, and detailed. The case study approach fit the problem well.

1, 6, 7, 8, 9

Detailed practices

Practices were regarded as the central component. The guidelines provided good meta-information that was ready to use in an implementation study.

2, 5, 6, 7, 8, 9, 10

Overview table

The table was well designed and had all necessary information on one page.

6, 7, 8, 9, 10

Framework design

The modularity was good for future iterations. The hierarchy of challenges, guidelines, and practices was accessible and served the framework well.

2, 3, 5, 6, 7, 8, 9, 10

Practice cards

The cards were a great idea, a good starting point, and worth testing in practice.

6, 7, 8, 9, 10

Implementation study

Such a study would be very interesting. Interviewees 7, 9, and 10 showed interest in supporting the implementation in their industrial setting.

All

Growing empirical basis

Once ADAPT’s empirical basis is larger, it should be analyzed to determine whether the practices fit better with one of the distribution scenarios.

3, 6, 10

Practice equivalency

Researchers should determine which practices are interchangeable, offering different perspectives on them such as simplicity, cost, and impact.

2, 5, 6, 7, 8, 9, 10

4. R. Prikladnicki, J.L.N. Audy, and J.R. Evaristo, “Distributed Software Development: Toward an Understanding of the Relationship between Project Team, Users, and Customers,” Proc. Int’l Conf. Enterprise Information Systems (ICEIS 03), 2003, pp. 417–423. 5. R. Vallon, Empirically Driven Design of the Agile Distributed Adaptable Process Toolkit (ADAPT), tech. report, Austrian Marshall Plan Foundation, 2015; www.marshallplan.at /images/Vallon.pdf. RAOUL VALLON is a postdoctoral researcher at TU Wien, where he leads the AMMA (Amazing Makers) work group on empirical software engineering. He developed the ADAPT (Agile Dis

tributed Adaptable Process Toolkit) framework as part of his PhD research. Contact him at raoul [email protected].

of Rio Grande do Sul, where he also leads the MuNDDoS research group. He’s also on IEEE Software’s editorial board. Contact him at [email protected].

STEFAN STROBL is a PhD candidate and

researcher with TU Wien’s BUSY research team, which focuses on industrial software engineering and reengineering. Contact him at stefan.strobl@ inso.tuwien.ac.at.

THOMAS GRECHENIG is a professor of industrial software engineering and head of the Industrial Software Group at TU Wien. Contact him at [email protected].

MARIO BERNHART is a software researcher

and practitioner who leads TU Wien’s BUSY software engineering research team. Contact him at [email protected]. RAFAEL PRIKLADNICKI is an associate

professor at the Computer Science School and the director of the Science and Technology Park (Tecnopuc) at the Pontifical Catholic University

Selected CS articles and columns are also available for free at http://ComputingNow.computer.org.

NOVEMBER/DECEMBER 2016

|

I E E E S O F T WA R E

111

SOFTWARE TECHNOLOGY

Editor: Christof Ebert Vector Consulting Services christof.eber [email protected]

Software Crowdsourcing Platforms Alexandre Lazaretti Zanatta, Leticia Santos Machado, Graziela Basilio Pereira, Rafael Prikladnicki, and Erran Carmel

Crowdsourcing is outsourcing to an undefi ned network of contributors. It has quickly gained momentum to fi ll urgent competence needs. There is a dark side. Amazon Mechanical Turk workers make extremely little money and enjoy no protections. This affects the entire software landscape because such microtasking reduces software quality. Also, students wonder whether they should still embark on computer science and software engineering careers. In this instalment of Software Technology, Alexandre Zanatta and his colleagues introduce us to software crowdsourcing, describing various platforms and presenting a case study from Brazil. I look forward to hearing from both readers and prospective column authors. — Christof Ebert SOFTWARE CROWDSOURCING is mediated by platforms that connect requesters (buyers) with online workers— the crowd. Thus, these platforms have emerged as an important stakeholder in software development. Here, we introduce them and group them by development phase.

Crowdsourcing will fundamentally change existing IT business models.

112

IEEE SOFTWARE

|

PUBLISHED BY THE IEEE COMPUTER SOCIETY

Crowdsourcing is essentially a distributed problem-solving model. In software development, crowdsourcing can be adopted at certain stages or throughout a project. Any development phase or task can be crowdsourced, including requirements, design, coding, testing, and documentation.1 Some platforms cover every development phase; others handle specific phases or tasks. All these platforms let requesters fi nd talent beyond their boundaries and benefit from other crowdsourcing advantages: reduced costs, reduced time to market, talent identification, solution diversity, higher quality, and access to creativity and problem solving. 0740-7459/16/$33.00 © 2016 IEEE

SOFTWARE TECHNOLOGY

A Look at the Platforms So how do crowdsourcing platforms work? They use the traditional market model, a competition model, or a hybrid of the two. The requesters (companies or individuals) post their issues—mainly software development problems they want solved— as a freelance job or competition. A community of online workers who have signed up for the platforms then decide (as individuals or small teams) whether to take on the challenge. In the competition model, requesters assess the submissions and select one or more winners, who receive a monetary prize. The innovation in modern crowdsourcing is in the platform itself— and the services it provides. These services include management and coordination of processes and people at both the technical and business levels.2 For example, Topcoder, Upwork, and Crowdplat have tools that support project managers, team leads, and any other governance needs. (We examine these three platforms in more detail later.) Figure 1 characterizes the basic interaction. The requester creates a task and submits a request describing the main requirements, including instructions, constraints, acceptance criteria, and goals. The requester also defines the target audience, taking into account the crowd’s abilities, and the task’s duration, resulting in a document that goes through the platform. The platform assigns the task to the crowd. The crowd participates and executes the request. At the end of the process, the requester validates the request and rewards the crowd on the basis of the accepted solutions. Some general platforms, such as Amazon Mechanical Turk, Stack Overflow, and Freelancer, aren’t spe

Requester

Submit request Validate request Pay for request

Crowdsourcing platform

Participate Execute request Charge for request

Provider (crowd)

FIGURE 1. Interaction with a crowdsourcing platform. These platforms have emerged as an important stakeholder in the software development process.

cifically for software development but support it. Amazon Mechanical Turk is the main platform for microtasks and has been employed, for instance, to support GUI testing. Microtasks are self-contained units of work that are granular and might take a few seconds or minutes to complete, with correspondingly small payments. Stack Overflow is a question-and-answer portal that has been used to improve software documentation. As we mentioned before, some platforms specifically support software development; we look at them next. Table 1 summarizes the information for all the platforms discussed in this article.

Multiple Development Phases Topcoder is the world’s largest software-­crowdsourcing platform, with a registered crowd of more than one million developers. The crowd often works on each phase separately as a competition. The standard phases include requirements exploration (application specification), architecture, design, component, deployment, and testing. TopCoder keeps track of each competitor’s ratings. After a competition, it applies an algorithm to the competitors and ratings. It ranks competitors on the basis of their efficiency, assigning them colors: red (the highest), yellow, blue, green, and gray. Most competitors are ranked as gray. Upwork is a giant platform with services ranging from graphic design

to software development. CrowdPlat is a small startup. Its model differs somewhat from that of Topcoder in that it connects requesters to either virtual freelance project teams or project teams from small consulting firms. GetACoder is a typical online auction site. Requesters post the software’s specifications, and the crowd bids on it. GetACoder uses a rating system similar to Topcoder’s.

Requirements Crowdsourcing can support the requirements phase because the crowd could be the potential users of the software, designed to meet their own requirements. Requesters could harness the power of the crowd to understand its requirements as part of requirements elicitation. The open source model has validated this approach. Some early research, such as CrowdREquire, 3 has examined this phase.

Design Parsing design out to the crowd is difficult. Numerous platforms do design, although most of it is visual— from logos to webpages. DesignCrowd uses a competition model and freelance jobs to distribute projects. Requesters can send the crowd private messages and view a specific design during a competition. Evaluation of the designers’ performance is through reviews and positive or negative feedback. Requesters

NOVEMBER/DECEMBER 2016

|

I E E E S O F T WA R E

113

TABLE 1

SOFTWARE TECHNOLOGY

Software crowdsourcing platforms. Platform

Purpose or development phase

No. of members

Location

Selection model

Learning resources

Reputation system

Amazon Mechanical Turk

Microtasks

2005

500,000

US

Freelance jobs

Yes

Yes

Stack Overflow

Microtasks

2008

1.3 million

US

Freelance jobs

Yes

Yes

Freelancer

Microtasks

2009

18 million

Australia

Freelance jobs

Yes

Yes

Quirky

Microtasks

2009

N/A

US

Freelance jobs

Yes

Yes

Topcoder

Multiple phases

2001

1 million

US

Competition

No

Yes

Upwork

Multiple phases

2015

9,000

US

Recruitment

N/A

Yes

Crowdplat

Multiple phases

N/A

N/A

US

Competition and freelance jobs

No

N/A

GetACoder

Multiple phases

2004

N/A

US

Freelance jobs

N/A

Yes

CrowdREquire

Requirements

2013

N/A

N/A

Competition

N/A

N/A

DesignCrowd

Design

2008

400,000

Australia

Competition and freelance jobs

No

Yes

99designs

Design

2008

300,000

US

Competition

No

N/A

Bountify

Coding

N/A

N/A

N/A

N/A

N/A

N/A

uTest

Testing

2007

175,000

US

Recruitment

Yes

Yes

Passbrains

Testing

2011

70,000

Switzerland

Recruitment

Yes

Yes

BugFinders

Testing

2010

55,000

Europe

Recruitment

N/A

N/A

Testbirds

Testing

2012

65,000

Europe

Recruitment

No

Yes

99tests

Testing

2010

12,000

India

Competition

No

Yes

can offer second- and third-place prizes or even pay designers just to compete as a guarantee. 99designs is the biggest player in this niche. For all categories except website and app design, a competition usually runs for seven days. Competitions have four stages: 1. the qualifying round, 2. selecting the finalists, 3. the final round, and 4. selecting the winner. The platform conducts localized 114

Launch date

I E E E S O F T WA R E

|

competitions, such as those in the Brazilian market.

Testing

Crowdsourcing’s immense power is evident for software testing. Here, a large crowd tests the software, usCoding This phase is covered largely by the ing many testing platforms in which general-purpose platforms we men- the applications run on different detioned before. Basically, request- vices, OSs, browsers, and language ers describe the problem and post a versions. Testing can be quick, with task, and programmers bid or com- quick ramp-up and ramp-down, in pete to provide solutions. We note different environments and situations. Typically, requesters pay for one specific platform here. Bountify is a question-and-­ only the valid bugs found. Some crowd-testing platforms answer platform that has been employed to improve crowdsourced have experience with diverse skill levels, minimum functionality, and small coding tasks and IDEs.

W W W. C O M P U T E R . O R G / S O F T W A R E

|

@ I E E E S O F T WA R E

SOFTWARE TECHNOLOGY

security during operational execution. A crowd-testing platform must coordinate activities in the crowd; track the work progress; guarantee task deadlines and quality; and ensure project confidentiality, safety, security, and terms and conditions. The following are some of the main crowd-testing platforms. uTest is the largest crowd-testing platform. It doesn’t allow anonymous contributions; members must sign up and log in. Recruitment is based on the quality and quantity of bugs members have submitted and the frequency of their participation in testing cycles. Passbrains offers a huge variety of tests, such as functional, compatibility, performance, and user experience tests. During the test cycles, testers deliver bug reports, user experience reports, product ratings, and improvement suggestions. BugFinders has a recruitmentbased selection model in which members receive test project alerts by email. Testers gain access to not only projects, such as testing unreleased mobile apps and websites, but also forums in which to share their expertise. Testbirds is a large platform that was quick to automate testing. It also works with the BYOC (bring your own crowd) option. 99tests pays $25.00 on average per bug. It provides functional, security, load, and automation testing. It has a process to create a test requirement (test cycle), submit bugs (log bugs), and check the components mentioned in the test cycle. 99tests’ members also validate the found bugs. Another crowd-testing platform is Crowdtest. For more on it, see the sidebar “Case Study: Crowdtest.”

Social Concerns Crowdsourcing—and

more

spe-

CASE STUDY: CROWDTEST Because our research team is in Brazil, we take a special interest in Brazilian crowdsourcing. So, we did a case study of Crowdtest, a small Brazilian crowdtesting platform founded in 2011.1 Many of the smaller crowd-testing websites are country-specific because of language and culture, but our case study’s lessons generalize to most crowd-testing situations. Crowdtest faced these growth challenges: • data confidentiality (many companies are afraid to share business information with testers), • very specific business rules (too many rules can impair testers’ ability and performance on some activities and tests), and • training the crowd for complex tasks requiring domain-specific knowledge. We also looked at one of Crowdtest’s key clients—an e-commerce company we’ll call BoveBras. BoveBras used crowd testing because it needed to • • • •

increase scalability, run more projects in a short period, achieve wider testing coverage, and perform the same quality assurance tasks both in-house and outside under different human and technical profiles.

BoveBras had an internal bug tracker with which it could monitor in real time the bugs being registered. This let it correct the bugs during crowd testing. Although the crowd testers detected many bugs, the testers’ maturity seemed low. Many bugs were poorly detailed. Others were superficial and predictable, suggesting that the testers didn’t work hard enough to break the application by developing complex test scenarios. Seemingly, crowd testing was weak when the testers needed specific business knowledge. Reference 1. L. Machado et al., “Software Crowdsourcing Challenges in the Brazilian IT Industry,” Proc. 18th Int’l Conf. Enterprise Information Systems (ICEIS 16), 2016, pp. 482–489.

cifically, software crowdsourcing— raises ethical and social concerns. One concern is reasonable payment. Microtasking websites tend to have the lowest wages. Workers earn less than minimum wage (for most countries in the Organisation for Economic Co-operation and Development)— approximately $1.50 to $6 an hour, with no work

protections or benefits. In the competition model, usually only the worker who wins gets paid. Another concern is fairness. For example, if a company uses a crowdsourcing platform instead of its regular agency to design a logo, is that fair? Also, some people have argued that crowdsourcing is labor exploitation.

NOVEMBER/DECEMBER 2016

|

I E E E S O F T WA R E

115

SOFTWARE TECHNOLOGY

GLOBAL SOFTWARE ENGINEERING CONFERENCE The annual IEEE International Conference on Global Software Engineering (ICGSE) brings together worldwide industry and research leaders in distributed software development. It’s the preeminent forum for topics such as how to make distributed teams more effective and efficient and how to cope with the challenges these teams create (for example, how to deal with different methods and tools). The most recent conference had participants from more than 20 countries, with one-third of the papers from industry. ICGSE 2017 will take place on 22 and 23 May in Buenos Aires, in conjunction with the International Conference on Software Engineering. Attend it and learn how to succeed with distributed software projects. The call for papers and more information are at www.icgse.org.

TECHNOLOGIES 2017 Participate in the Technologies 2017 survey and have the chance to win a copy of the book Global Software and IT, which contains many practical case studies. The survey is at www.vector.com/trends-survey.

M. Six Silberman and his colleagues warned that “paid crowd workers are not just an API call—but all too often, they are treated like one.”4 In contrast, Aleksejs Busarovs reported that crowd workers didn’t feel they were exploited.5

S

I E E E S O F T WA R E

ALEXANDRE LAZARETTI ZANATTA is a

PhD candidate in the area of crowdsourcing for software development, at the Computer Science School at the Pontifical Catholic University of Rio Grande do Sul. He also teaches software engineering at the University of Passo Fundo. Contact him at [email protected]. LETICIA SANTOS MACHADO is a PhD

candidate in the area of crowdsourcing for software development, at the Computer Science School at the Pontifical Catholic University of Rio Grande do Sul. She also teaches information systems at Universidade do Vale do Rio dos Sinos. Contact her at leticia.machado.001@ acad.pucrs.br. GRAZIELA BASILIO PEREIRA is a project

manager at PROCERGS (Companhia de Processamento de Dados do Estado do Rio Grande do Sul). Contact her at [email protected].

References

oftware crowdsourcing taps global inputs in new ways. Crowdsourcing platforms have introduced dramatic innovations to software development, from competitions, to coder ratings, to massive crowd testing. These benefits come with some complications. The platforms have been evolving, so both the requesters and workers must choose the best platform for a project. Additionally, sourcing some—or all—of a project increases both the 116

need for coordination and the risks. Challenges include cross-task coordination, virtual-team organization, determining the target audience, integrating the crowd’s deliverables, and ensuring the software’s quality.

Spring Symp.: Wisdom of the Crowd, 2012, pp. 2–7. 4. M.S. Silberman, L. Irani, and J. Ross, “Ethics and Tactics of Professional Crowdwork,” XRDS: Crossroads, the ACM Magazine for Students, vol. 17, no. 2, 2010, pp. 39–43. 5. A. Busarovs, “Ethical Aspects of Crowdsourcing, or Is It a Modern Form of Exploitation,” Int’l J. Economics & Business Administration, vol. 1, no. 1, 2013, pp. 3–14.

|

1. K.J. Stol and B. Fitzgerald, “Two’s Company, Three’s a Crowd: A Case Study of Crowdsourcing Software Development,” Proc. 36th Int’l Conf. Software Eng. (ICSE 14), 2014, pp. 187–198. 2. X. Peng, M. Ali Babar, and C. Ebert, “Collaborative Software Development Platforms for Crowdsourcing,” IEEE Software, vol. 31, no. 2, 2014, pp. 30–36. 3. A. Adepetu et al., “CrowdREquire: A Requirements Engineering Crowdsourcing Platform,” Proc. AAAI

W W W. C O M P U T E R . O R G / S O F T W A R E

|

RAFAEL PRIKLADNICKI is an associate

professor at the Computer Science School and the director of the Science and Technology Park (Tecnopuc) at the Pontifical Catholic University of Rio Grande do Sul, where he also leads the MuNDDoS research group. He’s also on IEEE Software’s editorial board. Contact him at [email protected]. ERRAN CARMEL is a professor in the Information Technology Department of the Kogod School of Business at the American University in Washington, DC. Contact him at carmel@ american.edu.

@ I E E E S O F T WA R E

SOFTWARE ENGINEERING

Editor: Robert Blumen SalesForce Desk.com rober t@rober tblumen.com

James Phillips on Service Discovery Charles Anderson

SERVICE DISCOVERY has become increasingly important in the construction of scalable, elastic, and always-on distributed systems. In this interview, James Phillips, who works on the open source service discovery tool Consul at HashiCorp, explains what service discovery is, provides use cases, and discusses available tools. You can listen to the entire interview at www.se-radio .net. Portions of the interview not included here for reasons of space discuss consensus, security, monitoring, durability, and bootstrapping.

Charles Anderson (CA): At a high level, what’s service discovery? James Phillips (JP): A service can be a logical entity within your architecture. You might have a database or a pool of application servers. At the highest level, service discovery is a system that lets you ask, “Where is a service located?” The answer is usually an IP (Internet Protocol) address or another important number. A set of processes usually back a given service, and for most highly available or scalable things, more than one process makes up a service. Service discovery lets you fi nd those things on a spectrum. You can have a fully statically configured service discovery system or a dynamic one. The techniques you use to do service discovery vary, depending 0740-7459/16/$33.00 © 2016 IEEE

mostly on how fresh the information is and how changes get put into your service discovery catalog. CA: When you say “static configuration,” that makes me think of configuration fi les, which I might update occasionally. Then I could use a configuration tool such as Puppet or Chef. What’s wrong with that approach? JP: That approach can work okay when you have a small handful of things to manage. But as soon as you get into the medium-to-large, large, to very large infrastructure, it becomes very hard to keep that catalog up to date by hand. The time involved to do a convergence run can take minutes. That’s often not fast enough to propagate a change. Also, having a human in the loop to check in changes to that catalog and to manage a list of IP addresses, and a system to push that out, becomes a burden when you want to run as automatically as possible. It becomes a maintenance and response time problem for infrastructure when it gets beyond trivial scale. CA: And I can imagine that, even at a small scale, response time would be a problem, as you mentioned. JP: Think about a master failover of your database. You need to point all

NOVEMBER/DECEMBER 2016

|

IEEE SOFTWARE

117

SOFTWARE ENGINEERING

your clients somewhere else, and you want that change to go out quickly. You don’t want that to take tens of minutes to propagate through your system. The configuration management tools definitely have a role, even if you’re using a service discovery system for bootstrapping your nodes or getting the service discovery system kicked off. But managing the ongoing state of the infrastructure becomes difficult to do with a static setup. CA: What system scale is appropriate for service discovery—LAN, single datacenter, or across datacenters? JP: My short answer to that is, yes, it can have a place at all of those different levels. You would not have it within an application process. You’re not going to find things like components or plug-ins with a service discovery mechanism. But once you have a process trying to find another process, it’s appropriate. For highly available or globally distributed infrastructures, it definitely makes sense for some service in datacenter A to reach out and find an instance of another service in datacenter B. Usually there’s a preferential scope. You want to use things that are close and nearby. Sometimes it’s part of normal operations to find things remotely that are located in a much larger tier across the Internet. It definitely makes sense when you’re talking about [geographic] redundancy and failover. Ideally, your service discovery system would let you cross those boundaries. Your application has to know how to reach out to all of these different things. CA: On a local network, is service discovery comparable to 118

I E E E S O F T WA R E

|

zero-­configuration networking—­ something such as Apple Bonjour? JP: That is definitely the most basic example: “What’s the IP address of an instance of this type of service?” We’ll see later that, for managing other types of configuration or orchestration, that [approach] probably isn’t ideal. [Finding IP addresses on a LAN] requires multicast. [However, that approach] is often a low-level piece of a bigger service discovery solution. CA: You mentioned processes finding each other. Can you tell us more about scenarios in which service discovery would be appropriate? I can think of examples such as a serviceoriented architecture or possibly microservices. JP: Definitely. Even a monolithic application must deal with issues like “Where’s the database?” and “How do I connect to it?” That makes sense in any type of architecture. But, as you move to service-oriented [architecture] or microservices, you’re going to have a much more distributed set of pieces that need to find each other. Behavior becomes more dynamic as you have an architecture that’s distributed across functional pieces, with different pieces of the architecture coming and going over time. In general [the difference is that] you’ll have more than one instance to choose from. You want to choose a healthy one to talk to. Service discovery really shines there. Under a resource scheduler, like Kubernetes, or Mesos, or Nomad, some [containers] are placed onto the machines in your cluster by an automated infrastructure. At that point, there is no realistic way to have humans editing config files

W W W. C O M P U T E R . O R G / S O F T W A R E

|

and then pushing out the changes. You need something that, in real time, can manage where all your resources are, which ones are healthy, and where to find them. CA: Are there applications or scenarios in which I wouldn’t want to use service discovery? JP: I don’t think so. I think the basic hygiene of separating the configuration out of your application is a good thing to start with early on. You don’t want to be hard-coding IP addresses in your source code, to give an extreme example. You will progressively use more features of service discovery as your application gets more sophisticated. It’s possible to start simple within an integration that’s very, very lightweight, even zero impact on your application code, and then expand from there by adding more orchestration features—for example, electing a leader among many potential leaders in your pool of services. If you build machine images, it’s nice to separate out the service discovery piece into a separate layer to avoid the need to make a new machine image when it’s some configuration changes. Having that layer in there can even have practical implications for your deployment pipeline and how you manage your images for deployment. CA: You said something there that made me think about immutable infrastructure. If you’re talking about baked-in Amazon Machine Images, extracting out this variable configuration and information would make sense, right? JP: Having that layer there and then being able to dynamically push

@ I E E E S O F T WA R E

SOFTWARE ENGINEERING

changes out after something is deployed, without having to get into that image and change its configuration, is a super-big plus. That same machine image can connect to any database or any instance of your API server because it’s getting all of that configuration on the fly from the service discovery system. CA: Let’s move into some more technical details. What data are typically stored in service discovery repositories? You mentioned host names, or IP addresses, and port numbers. Is that the extent of it? Or is there more? JP: That’s the most fundamental data. When you are managing services and their configuration, you generally need a little bit more information—­ things like database user name, potentially credentials, tokens, and other information along with the basic ID and port information that’s already stored in the service discovery system. It’s also a good place to put things like feature flags. Nearly every service discovery system supports a general bucket of key–value information, which can be used to capture the whole set of the configuration data that you need for interacting with other services. CA: What are a service discovery tool’s typical components? JP: A complete solution for service discovery comes down to four different pieces. There’s the core service discovery: So, where is this thing? What’s this IP address and port? How do I connect to it? And there is going to be a health-monitoring piece. It’s not useful to get an instance that’s no longer functioning when you’re looking for something

to connect to. The health-monitoring component creates a fresh and live set of data that is easily managed. You need some configuration storage. So that’s generally in the form of a key–value store. That can also be used for coordination. And then [you need] an orchestration piece. It’s often useful to be able to elect a leader [from] many possible instances or to make sure that an operation is done with no race conditions. CA: Would load balancing be a function of service discovery? Or is that going to be something separate? JP: It can be. That’s an architectural choice with different service discovery systems. Some systems make load balancing a first-class part of the architecture. In those cases you route all of your traffic at a load balancer that manages talking to the different healthy instances. It’s often the case, though, that you can avoid a load-balancing tier by using service discovery for that purpose. You can avoid that one tier and one potential point of failure. You can talk directly to a healthy instance by virtue of how your service discovery system works. There are tradeoffs and there are choices. One common practice is within the datacenter not to use load balancers. But you’ll use your service discovery system to configure an external load balancer that your customers are using. Some systems run load balancers internally but route traffic over late hours. There’s a range of possible solutions. CA: How do servers that want to offer services know where they’re going to register? And on the flip side, the clients that are looking for a service— how do they know? Do we need another layer of service discovery?

JP: It’s turtles all the way down. You generally need some kind of seed or some way to introduce a new entity into the service discovery system. Some systems do that with wellknown DNS records for a root service. There are different architectures in terms of how you access the service discovery system. Consul, for example, runs an agent on every node. Your applications only ever talk to their local agent, and then Consul manages talking to other servers and routing requests. Other systems make you locate a central server, and then you make requests against that. But there usually is some sort of bootstrapping process to kick things off. CA: You said “seed.” At some point in time, all the way down to following all the turtles down, we get an egg or a seed there. JP: There’s a hard-coded IP address or something similar somewhere. If you have a well-known thing to reach out to, it will manage the task of finding you a server to join with. CA: Service discovery is needed by the whole app. It must be reliable. How is that reliability provided? JP: That’s a prime concern. It would be a single point of failure if it wasn’t done properly. A key component of any service discovery system is to be distributed and replicated. You need to be able to build out redundancy to whatever level of failure tolerance you want. And that may mean having redundancy [at each level of scale]. Within your local area network you might have multiple servers. And then you may also want redundancy by having federations of servers that can talk to each other and

NOVEMBER/DECEMBER 2016

|

I E E E S O F T WA R E

119

SOFTWARE ENGINEERING

SOFTWARE ENGINEERING RADIO Visit www.se-radio.net to listen to these and other insightful hour-long podcasts.

RECENT EPISODES • 262—Bill Curtis talks with host Sven Johann about what software quality is and how to achieve it. • 263—Camille Fournier joins host Stefan Tilkov for a conversation about lessons learned regarding real-world distributed systems. • 265—Pat Kua and host Johannes Thönes delve into the role of tech lead and leadership-related issues.

UPCOMING EPISODES • 267—Jürgen Höller speaks with host Eberhard Wolff on the Spring Reactive initiative, which involves reactive extensions to the popular Java framework. • 268—Phillip Carter discusses the F# programming language with host Eberhard Wolff. • 289—Kief Morris talks with host Sven Johann about infrastructure as code.

might be in different geographic locations. A distributed system with replication must handle a server going completely offl ine, or two servers. Partition tolerance is very important. And you need to deal with what happens when the system is down altogether. In the event of a partition there are different strategies. Consensus algorithms require a minimum number of servers for a quorum. You want it to operate even in degraded modes. If you get below that, maybe you can’t write to your system anymore but you still want to read. The client can say, “Hey, I’m willing to take some stale information. What’s your best information that you had as of this long ago?” There are many techniques that good service discovery solutions have for managing [partial failures]. Do they perform retries? How do they avoid thundering herds when 120

I E E E S O F T WA R E

|

things come back online? How do they randomize traffic to spread load among different components? How do you scale events, based on the size of the clusters? There are many layers that go into making a robust service discovery system. CA: You mentioned a consensus algorithm, which would lead us into the CAP (consistency, availability, partition tolerance) theorem, in terms of making tradeoffs? JP: Different tools have different strategies and tradeoffs. There are the AP-type systems that provide better availability but make it (potentially) much harder to reason about failure modes, because you can end up with two different sides of your cluster working in two different ways. And then there are systems that go the CP route. Those are often eas-

W W W. C O M P U T E R . O R G / S O F T W A R E

|

ier to reason about because they have a consensus algorithm that lets you know the state of your cluster. They have a known behavior in the event that things go wrong. Depending on your application, there are considerations. I would say that most systems tend toward a CP-type architecture. CA: Preferring consistency and partition tolerance over availability? JP: Yes, but with the caveat that you have read availability even in the loss of a quorum, say. The minority that can’t make progress in terms of making writes can still read the current state as it was at the time the partition happened, for example. CA: We’ve mentioned databases a couple of times. Suppose rather than running my own database server, I’m hosting in Amazon Web Services, and I’m using Amazon Relational Database Service to provide a MySQL or Postgres server. Would I still be using service discovery to discover the database, even though in theory Amazon is going to keep it pretty stable for me? JP: I think so, because tools such as Consul have support for what we call external services. So those are static registrations, but they are served in the same manner in terms of Consul’s APIs, as any other service. CHARLES ANDERSON is a software devel-

oper who focuses on systems, back-end, and infrastructure programming. Contact him at [email protected].

@ I E E E S O F T WA R E

See www.computer.org /software-multimedia for multimedia content related to this article.

PURPOSE: The IEEE Computer Society is the world’s largest association of computing professionals and is the leading provider of technical information in the field. MEMBERSHIP: Members receive the monthly magazine Computer, discounts, and opportunities to serve (all activities are led by volunteer members). Membership is open to all IEEE members, affiliate society members, and others interested in the computer field. COMPUTER SOCIETY WEBSITE: www.computer.org OMBUDSMAN: Direct unresolved complaints to ombudsman@ computer.org. CHAPTERS: Regular and student chapters worldwide provide the opportunity to interact with colleagues, hear technical experts, and serve the local professional community. AVAILABLE INFORMATION: To check membership status, report an address change, or obtain more information on any of the following, email Customer Service at [email protected] or call +1 714 821 8380 (international) or our toll-free number, +1 800 272 6657 (US):

EXECUTIVE COMMITTEE

• • • • • • • • •

Executive Director: Angela R. Burgess Director, Governance & Associate Executive Director: Anne Marie Kelly Director, Finance & Accounting: Sunny Hwang Director, Information Technology & Services: Sumit Kacker Director, Membership Development: Eric Berkowitz Director, Products & Services: Evan M. Butterfield Director, Sales & Marketing: Chris Jensen

Membership applications Publications catalog Draft standards and order forms Technical committee list Technical committee application Chapter start-up procedures Student scholarship information Volunteer leaders/staff directory IEEE senior member grade application (requires 10 years practice and significant performance in five of those 10)

PUBLICATIONS AND ACTIVITIES Computer: The flagship publication of the IEEE Computer Society, Computer, publishes peer-reviewed technical content that covers all aspects of computer science, computer engineering, technology, and applications. Periodicals: The society publishes 13 magazines, 19 transactions, and one letters. Refer to membership application or request information as noted above. Conference Proceedings & Books: Conference Publishing Services publishes more than 175 titles every year. Standards Working Groups: More than 150 groups produce IEEE standards used throughout the world. Technical Committees: TCs provide professional interaction in more than 45 technical areas and directly influence computer engineering conferences and publications. Conferences/Education: The society holds about 200 conferences each year and sponsors many educational activities, including computing science accreditation. Certifications: The society offers two software developer credentials. For more information, visit www.computer.org/ certification.

NEXT BOARD MEETING 13–14 November 2016, New Brunswick, NJ, USA

revised 10 June 2016

President: Roger U. Fujii President-Elect: Jean-Luc Gaudiot; Past President: Thomas M. Conte; Secretary: Gregory T. Byrd; Treasurer: Forrest Shull; VP, Member & Geographic Activities: Nita K. Patel; VP, Publications: David S. Ebert; VP, Professional & Educational Activities: Andy T. Chen; VP, Standards Activities: Mark Paulk; VP, Technical & Conference Activities: Hausi A. Müller; 2016 IEEE Director & Delegate Division VIII: John W. Walz; 2016 IEEE Director & Delegate Division V: Harold Javid; 2017 IEEE DirectorElect & Delegate Division V: Dejan S. Milojičić

BOARD OF GOVERNORS Term Expriring 2016: David A. Bader, Pierre Bourque, Dennis J. Frailey, Jill I. Gostin, Atsuhiro Goto, Rob Reilly, Christina M. Schober Term Expiring 2017: David Lomet, Ming C. Lin, Gregory T. Byrd, Alfredo Benso, Forrest Shull, Fabrizio Lombardi, Hausi A. Müller Term Expiring 2018: Ann DeMarle, Fred Douglis, Vladimir Getov, Bruce M. McMillin, Cecilia Metra, Kunio Uchiyama, Stefano Zanero

EXECUTIVE STAFF

COMPUTER SOCIETY OFFICES Washington, D.C.: 2001 L St., Ste. 700, Washington, D.C. 20036-4928 Phone: +1 202 371 0101 • Fax: +1 202 728 9614 Email: [email protected] Los Alamitos: 10662 Los Vaqueros Circle, Los Alamitos, CA 90720 Phone: +1 714 821 8380 Email: [email protected] MEMBERSHIP & PUBLICATION ORDERS Phone: +1 800 272 6657 • Fax: +1 714 821 4641 • Email: [email protected] Asia/Pacific: Watanabe Building, 1-4-2 Minami-Aoyama, Minato-ku, Tokyo 107-0062, Japan Phone: +81 3 3408 3118 • Fax: +81 3 3408 3553 Email: [email protected]

IEEE BOARD OF DIRECTORS President & CEO: Barry L. Shoop President-Elect: Karen Bartleson Past President: Howard E. Michel Secretary: Parviz Famouri Treasurer: Jerry L. Hudgins Director & President, IEEE-USA: Peter Alan Eckstein Director & President, Standards Association: Bruce P. Kraemer Director & VP, Educational Activities: S.K. Ramesh Director & VP, Membership and Geographic Activities: Wai-Choong (Lawrence) Wong Director & VP, Publication Services and Products: Sheila Hemami Director & VP, Technical Activities: Jose M.F. Moura Director & Delegate Division V: Harold Javid Director & Delegate Division VIII: John W. Walz

Meet Analytics Experts Face-To-Face

18 October 2016 | Mountain View, CA

Why Attend Rock Stars of Pervasive, Predictive Analytics? Want to know how to avoid the 4 biggest problems of predictive analytics – from the Principal Data Scientist at Microsoft? Take a little time to discover how predictive analytics are used in the real world, like at Orbitz Worldwide. You can stop letting traditional perspectives limit you with help from Mashable’s chief data scientist.

Come to this dynamic one-day symposium.

Sameer Chopra

GVP & Chief Analytics Officer Orbitz Worldwide

www.computer.org/ppa

Juan Miguel Lavista

Haile Owusu

Principal Data Scientist Microsoft

Chief Data Scientist Mashable