Thursday, March 31, 2011

Bob Smith, Honeywell CTO/VP
SDM Alum Offers Insight on Innovation

By Kathryn O'Neill


Bob Smith
Innovation is the lifeblood of the aerospace industry, and MIT's System Design and Management Program (SDM) provides many of the tools needed to inspire and foster innovation, said Bob Smith, chief technology officer and vice president of engineering and technology at Honeywell Aerospace, in speaking to a gathering of SDM fellows on March 7, 2011.

"[SDM] provides the foundational thinking on the interaction of business and technology and gives you insight into dealing with large, complex systems—which I would argue are most systems today," said Smith, SDM '97, who gave the keynote address during SDM's spring "business trip," a week of activities that brought on-campus and distance SDM students together for lectures, workshops, and networking March 7-11 at MIT.

In his presentation, "Innovating and Competing in the Aerospace Industry," Smith provided a brief history of innovation in aviation—and noted its continued significance at Honeywell Aerospace, an $11 billion unit of the $35 billion multi-industry conglomerate. Smith told the SDM students that although Honeywell's legacy includes the first autopilot flight controller, the first flight management systems, the first business jet turbofan, and other firsts—the company doesn't rest on its laurels. "All of our customers pay us for innovation," he said. "Within the aerospace industry, you either innovate or you die."

Smith said Honeywell works hard to keep its product pipeline fresh by employing three types of innovation:

Product innovation—The simplest kind of innovation, Smith said, is making an existing product better. He used examples from other industries to illustrate his point and cited the Swiffer dust mop as a great one. "It's basically a paper towel on a stick, but it's a wonderful piece of innovation," he said, improving on the traditional mop by enhancing both its usability and convenience.

Market innovation—More sustainable than product innovation, this kind of innovation is about discovering and fulfilling needs the customer didn't even know he had, Smith said, calling Starbucks a case in point. "It really wasn't the coffee that brought everybody to Starbucks," Smith said."They are paying $4 for the experience—because they like the jazz and the café environment. Otherwise they're going to Dunkin' Donuts."

Business model innovation—This is the real game changer, Smith said, citing the iPod. "[Apple] didn't invent the mp3 player," Smith noted. "They changed the market distribution channel for legal and profitable digital music by inventing iTunes to go with the iPod."

How does one replicate such success? Smith suggested that cultivating diversity in your thinking—a skill SDM encourages—is critical. "The reason a lot of senior managers fail is that that they've succeeded by doing the same things in the same ways for a long time, and then a situation occurs in which that doesn't work," he said. "The multi-industry aspect of the SDM academic program is great because it helps highlight blind spots in your own industry" so you can avoid this trap.

Smith noted that when he was at SDM one of his fellow students worked at a camera and film company, and at the time the company was most concerned about the threat posed by other film companies. "We kept telling him, 'You need to be thinking about image [not film] as your business,'" but the student was convinced that film was king. "He was trapped within his own organization's thinking."

In contrast, Smith said Honeywell has continually profited by thinking about old products in new ways. The company currently has a high market share in inertial gyros because it has historically stayed on top of advances in measuring orientation. Similarly, the company's success in selling centrifugal compressors can be traced to past efforts to find new ways to apply that technology.

Smith urged SDM students to use the program fully to broaden their thinking. "Spending time with your [SDM] colleagues and understanding their business models, as well as the trends they have to address worldwide, is very important," Smith said.

Smith also praised SDM for offering invaluable skills in business analytics, giving him insight into the importance of systems interactions, and providing "inordinately helpful" lessons in organizational design. Organizing for innovation is challenging, he said, but Honeywell works hard to give employees a sense of ownership over their work and to provide a reward system that keeps people engaged.

"Ideation can be guided by models and methods, but inspiration, great ideas, and a great environment are essential," he said. "You have to organize around [innovation], reward people for it, and celebrate it when it's done well so that everybody understands why it's important."

How Systems Thinking Will Bring Broadband to Rural Areas

By David Rosenbaum

Jess Posey
Editor's Note: Jess Posey will deliver a webinar expanding on this topic on April 11, 2011. For details or to listen to a recorded version after that date, please visit the SDM webinars page.

When Brian "Jess" Posey enrolled in MIT's System Design and Management Program (SDM), he already knew what his thesis would be: an analysis informed by systems thinking of how Dynamic Time Metered Delivery (DTMD) could help fulfill Congress' 2009 mandate that every American, no matter where he or she lived, should have access to affordable broadband. Meeting that goal, Congress believed, would advance "consumer welfare, public safety, community development" and a host of other societal benefits.

Posey's focus stems both from his prior experience as vice president of a company that marketed an ultimately unworkable broadband solution and his current position as co-founder and president of TelePulse Technologies, which has patented DTMD, a time-and-code-based communications technique for a variety of transmission media, including copper phones lines, coaxial cable, fiber, and others. In July 2010, the FCC redefined broadband from 200kbps to 5Mbps thus increasing the number of un-served from a few million to 14-24 million. This action is quite helpful to TelePulse Technologies.

According to Posey's thesis, DTMD can make broadband access affordably deliverable to underserved rural areas because it addresses the business and technology difficulties inherent in the three most popular modes of Internet delivery: DSL, cable, and fiber.

With DSL, says Posey, the technological problem is that speeds "attenuate quickly over distance." To accommodate greater speeds, DSL providers have to expand the current phone company infrastructure in order to get close enough to rural customers to get faster DSL speeds. That's expensive. In technology, Posey says, usage and volume reduce costs; in construction labor, it's the opposite.

With expanding the use of fiber to the home, says Posey, the problem is primarily financial; it's "horrendously expensive" to install directly to a household. To get fiber to rural households means digging and incurring labor costs. Those costs have to be shared among the potential users of the fiber so cost per customer is important. Cable, like fiber to the home, works best in cities or where companies can aggregate enough customers and achieve economies of scale. In rural areas, with fewer widely disbursed users per square mile, there's little incentive for investment because the cost per customer will be higher.

Conversely, by leveraging existing infrastructure, DTMD can be deployed without capital investment while improving the quality (and speed) over DSL service. The population density is irrelevant. For the FCC goal of 5Mbps, DSL does it out to 1 mile and DTMD does it out to 5 miles. For the FCC goal of 100 Mbps, DSL does it out to 1,300 ft and DTMD does it out to 4,500.

The Hypercube analysis Posey used in his thesis is a systems approach. "I looked at what DTMD meant for VoIP providers, broadband customers, the semi-conductor industry, wired telecom providers, equipment manufacturers. It's a much more holistic view," he says.

"For example, if you're a VoIP or Skype provider, DTMD is an incremental innovation. Their core doesn't change, but I can expand their market for them.

"If you're a regular wire-line phone company, and you're not serving a rural community, you'll see DTMD as a modular change. I'm enhancing value without touching your infrastructure.

"If, however, you've taken fiber into the home, then DTMD is a radical, disruptive innovation, so some companies won't be happy. The same thing if you're a DSL chip manufacturer. For the equipment manufacturer DTMD would be seen as an architectural innovation. Their core concepts are reinforced, but the architecture of their networking equipment is changed. They would neither like nor hate DTMD. The equipment manufacturer will build the equipment if the phone company guarantees large markets and follow-on business. However there is no incentive for the equipment manufacturer to pursue the new technology then find a phone a company to use it.

"With Hypercube analysis, you're dealing with more than technology; you're analyzing financial, policy, and business model questions. Just being a faster, better, cheaper innovation is (oddly enough) irrelevant.

"Before I came to SDM," Posey concludes, "I knew intuitively that it wasn't enough to have a great piece of technology; it had to fit into a system. But that's what I wasn't quite getting right. What I needed was industrial engineering, systems engineering, and engineering management with a systems focus and raised to higher level of abstraction. That's what I got at SDM. At SDM, you raise the level of abstraction. In other programs, it's as if they're teaching you to optimize functions for their own sake. At SDM you step up to figure out how something fits into the value chain."

Tuesday, March 29, 2011

Faculty Member Outlines Value of Software System Architecture

By Alan MacCormack, visiting associate professor of management

Editor's note: Alan MacCormack is a member of the Technological Innovation and Entrepreneurship Group at the MIT Sloan School of Management. He teaches Sloan's core class in innovation and has served as thesis advisor for several students in MIT's System Design and Management Program (SDM).

Alan MacCormack
Over the last 10 to 15 years, even the most traditional of industries have come to rely on software, for everything from inventory control to vehicle navigation. The average automobile today has more software than the first Apollo moon rocket. Your garden variety microwave may even have an algorithm for cooking popcorn to fit your specific tastes. Despite this dramatic increase in the pervasiveness and importance of software, however, many companies lack a fundamental understanding of the architecture underlying their code. This problem costs firms millions of dollars per year.

Ask a systems designer at any major commercial software company to describe the architecture of their product on a whiteboard. They'll typically draw a diagram showing a number of boxes (modules) that perform highly specific functions, with a few neat connections between them. My research shows however, that if you actually measure the interactions between boxes at the code-level, you'll find the architecture is much more tightly coupled than anyone would think. Coupling has its virtues—tight interactions between different pieces of code can lead to increased performance in areas such as speed or memory footprint. But coupling also has major drawbacks, with respect to the ease with which software can be corrected and adapted to meet future needs.

Virtual systems are fundamentally different from other kinds of systems. As an information-based product, software appears to be easy and quick to change—which can be an advantage and a disadvantage. There are no physical changes to be made, yet the complexity of modern software is such that even small modifications can ripple through a system with unintended consequences. Software appears to be malleable, but in practice, the architecture of many systems is opaque. A developer dare not change them too much for fear of creating a tangled web of dependencies and changes to upstream files.

Furthermore, unlike industries such as automobiles and airplanes, which create new platforms from the ground up every few years, modern software development efforts rarely start with a clean slate. Most systems have a significant legacy, on top of which new features and functionality are built. Unfortunately, it's not obvious from looking at the older code which pieces are connected to which others. It's not like working with a mechanical system, where you can see connections simply by inspecting the product, or reverse-engineering its design. Unfortunately, this hard-to-understand legacy code often embeds assumptions and design decisions that are no longer optimal for the system.

Why are initial design decisions often so out-of-whack with the current requirements for a software system? One reason is that the original design may have been built quickly, by a small company or startup more focused on releasing its first product rapidly than on building a framework to last for many years and multiple product evolutions. Software engineers design programs to meet their immediate needs, and in a startup, there is no guarantee that you will be around in 12 months. Speed is of the essence, and any performance edge is pivotal, no matter how you achieve it. Ten years later, however, when the war for market share is over, the needs of a user might be better served by a much more modular, maintainable, and adaptable system. In essence, early design decisions create a "technical debt" that must be paid by all those that follow.

Let me provide a micro-level example of these dynamics. Alice might decide to use a piece of functionality that Robert has already designed in his module, so she writes some code to "call" his function from her module. This saves time, but creates a dependency between Alice's modules and Robert's that may not be transparent to the system architect. Five years down the line, when Robert and Alice have both retired to Tenerife, that dependency may be a complete surprise to a programmer needing to make a change. Changing code in Robert's module may well cause Alice's module to cease functioning.

The work that Andrei Akaikine, SDM '09, did in the thesis I supervised provides a great example of the costs that arise from an architecture that is overly complex. In his thesis, he examined a software system with a long history, which generated significant maintenance costs each year. Every change could create unexpected problems and require additional fixes to other parts of the system. The owner of this system—a large commercial software firm—decided to redesign the software with the goal of adding new features to the system, while simultaneously reducing its complexity (by reducing the coupling between elements). Akaikine showed that the result of this redesign was a significant reduction in maintenance effort, as captured by the time it takes to fix defects.

Of course, any major redesign involves significant costs of its own—management has to decide if these costs are warranted. Unfortunately, many businesses make these decisions based on gut-feel and intuition, rather than a rigorous analysis of the likely payoffs. We need much better data to make informed decisions, and the software industry is woefully lacking in such data. Ultimately, this is why the work I have done with Akaikine and other ESD students—including Daniel Sturtevant, SDM '07, who is working on his PhD—is important. We are among the first research teams to visualize and measure the extent of technical debt in legacy software systems.

To achieve this goal, we have developed pioneering methods for visualizing and measuring attributes of a software architecture that can help us assess its underlying structure. Consider a well-known example from a recent paper, in which we look at the Mozilla web browser. After its release as open-source software in 1998, a major redesign effort was undertaken on the system, with the aim of making the codebase more modular, and hence easier to contribute to. The design structure matrices (DSMs) from before and after this redesign illustrate what happened. The modular architecture that resulted facilitated contributions to the code by creating fewer unintended interactions between components. Before the redesign, each component was, on average, connected to 18 percent of other components. Afterward, this figure dropped to below 3 percent.

Ultimately, different designs will have different performance characteristics along a variety of important dimensions, making techniques like ours valuable for exploring design trade-offs. A highly integrated design is likely to be faster, while a highly modular design may be more reliable. A designer must consider carefully what the product needs to do to arrive at the optimal design for her objectives. For example, if a system has to last 10 years, and you have no idea what it will need to do at the end of that time, the software must be designed to be extremely flexible and evolvable. Unfortunately, very few software companies practice such forward-looking "systems thinking."

How should a firm begin? Nobody should rush headlong into full-blown re-factoring of a major system, given we are still in the infancy of understanding how these efforts work. Indeed, our research reveals that a manager's intuition about where to start such an effort is frequently wrong, given the perceptions of an architecture and the realities embedded in its source code are often in conflict. Software companies first need to generate data on measures of architecture, and begin to link these measures to performance outcomes that they care about. Most firms tinker with and redesign their software all the time—in effect they run hundreds of small experiments every year. Armed with a careful assessment of this data, they will be better placed to assess what works and what doesn't. Ultimately, we know complexity hurts. But reducing it is also a complex endeavor.

SDM Fellows Provide Strategic Consulting for Boston Cleantech Firm

By Karl Critz, SDM '10

Karl Critz delivering the team's project presentation at the
EnerNOC corporate meeting. Photo by Edoardo Cavalieri d'Oro
During the fall semester of 2010, a group of five SDM fellows engaged in a strategic consulting project for the Boston Cleantech firm EnerNOC. The work was conducted through Michael Davies' Systems Leadership and Management (SLaM) Lab.  EnerNOC laid out a specific, mission-critical goal: expand the company's demand response offering, DemandSMART™, to reach a new class of end-use customers.  The SDM team responded with an immediately implementable solution that targeted new sources of value for company and customer alike.

SLaM lab connects student teams with companies that want a fresh approach to a business challenge. Projects must span technological and managerial domains, represent real issues with concrete  impact, and have strong internal support.  Sassan Zelkha (SDM'10) identified EnerNOC's level of involvement as a key success factor: "The level of exposure and access granted to us by EnerNOC was exceptional."

Sassan Zelkha, Swope Fleming, and Avi Latner prepare
to answer questions. Photo by Edoardo Cavalieri d'Oro
To determine market need and the range of solutions, the team held dozens of interviews with customers and experts. EnerNOC sales representatives, engineers, operations managers, and marketers freely shared domain knowledge and established realistic parameters for implementation.  Current customers revealed their reasons for signing up for DemandSMART while potential customers catalogued concerns.  After conducting primary research, exploring analyst reports, and analyzing actual customer electricity consumption data, the team synthesized the large body of unstructured information into actionable intelligence.

The team concluded that as a standalone product for the desired customer base, demand response alone is not a sufficiently compelling value proposition. To connect with the new type of user, the team developed a hybrid product that delivered more value and addressed a specific anxiety common to the new customer base. The new product still allows EnerNOC to aggregate and deliver firm, reliable demand response resources to electrical utility partners and system operators.  Hardware and installation represented a significant part of the product’s cost structure; the team specified a new equipment mix to reduce costs and generate a favorable rate of return.  Finally, the team created a new sales strategy to facilitate the go-to-market plan.

This solution was presented to C-level executives and the Utility Solutions group at EnerNOC's 2010 corporate conference.  The presentation was enhanced by the visual communication techniques emphasized in the SLaM course.  EnerNOC's corporate culture involves in-depth questioning and rigorous assumption-checking, so the SLaM team had to be ready with quick and thorough answers. Product Manager Margaret Yellott was enthusiastic, noting that "I thought the presentation was snappy, your points and supporting data were well articulated, and you fielded questions effectively. And of course, the substance of the product was good, and we're looking forward to digging into next steps internally."

The process was just as important as the product.  Throughout the course, the topics included leadership, teamwork, and group dynamics. Team members were able to apply these concepts immediately and improve their critical soft skills.  Swope Fleming (SDM'10) summarized the experience well: "I thought it was an excellent project and EnerNOC's support was fantastic.  Being able to work with 'live ammo' is something that just cannot be replicated in the classroom alone, and it was an invaluable experience."

The MIT project team consists of Avi Latner, Swope Fleming, Edoardo Cavalieri d'Oro, Sassan Zelkha, and Karl Critz.  We thank the EnerNOC project team of Lee Garf, Mark Foreman, and Margaret Yellott.

Booz Allen, TransGlobal Business Systems Execs Discuss Leadership & Innovation with SDM Fellows

By Kathryn O'Neill

Two senior executives recently joined fellows in MIT's System Design and Management Program (SDM) for a question-and-answer session on entrepreneurial and corporate leadership. According to George Schu, senior vice president of Booz Allen Hamilton, and Mark Walcott, president of TransGlobal Business Systems, a clear vision, ably communicated, is critical to leading any business successfully.

"I believe leadership comes from an amalgam of qualities," said Walcott, whose company provides information-sharing solutions for public safety, homeland security, and private industry clients. "Good leaders essentially have the community's interest at heart; they have a clear message and they provide hope for people."

Schu agreed. "You inspire innovation as a leader by helping people realize a vision," he said. "As a leader, I take a lot of interest in helping young innovators."

The two speakers fielded a long list of questions from fellows during a March 9, 2011, lunch at the MIT Faculty Club, tackling topics ranging from "What percent of your time is spent on innovation?" to "Are leaders born or made?"

Walcott answered the former question by saying innovation must always be a priority. "You don't ever look away. You structure your internal organization to look at both [innovation and day-to-day issues] at the same time," he said.

Schu responded to the latter by saying that leaders are both born and made. "Leadership is impossible without experience," he said, noting one way to build leadership in organizations is through mentoring. "I spend a lot of time mentoring people—very junior people," Schu said. "I believe that a very important element of leadership is to listen—not to be the one speaking all the time.... Good ideas do not flow from the top exclusively. Smart leaders embrace others' ideas."

Walcott said that leaders must communicate their vision clearly in order to inspire people to realize the goals of the business. Both he and Schu agreed that good communication can also be the best defense when facing pushback in implementing new ideas. Schu said that it is possible to change people's minds through clear communication, project piloting, and good metrics.

Walcott said he challenges employees to come up with a better solution if they don't like a proposed plan. "I'm a firm believer that success is always tied to the people who support you."

Schu agreed. "People are the most important resource," he said. "You need to be able to recognize talent, train talent, and give them a path forward."

This panel session with George Schu of Booz Allen Hamilton and Mark Walcott of TransGlobal Business Systems was a highlight of SDM's spring "business trip," a week-long event held each semester that brings on- and off-campus SDM fellows together at MIT for lectures, presentations, classes, and workshops.

Monday, March 28, 2011

Melissa Rosen, SDM '11: Developing Medical Devices and WiSDM

Melissa Rosen
Photo by Kathy Tarantola Photography
By Ethan Gilsdorf






As a project engineer for the Swiss-based consulting group Helbling Precision Engineering Inc., Melissa Rosen, a first-year student in MIT's System Design and Management (SDM) Program, has been involved in the early stage R&D process for medical devices for nearly five years. She leads development efforts to create devices such as drug delivery systems for diabetes patients and implantables like hearing aids.

But as an "ethical engineer," she does not merely focus on her company's bottom line. She wants to create products that both enter the marketplace at the right time and improve the quality of life for those who suffer. "There is a fine line between medicine and business," Rosen said.

The SDM program is helping Rosen strike that balance.

The professors, courses, and community are widening her view of her industry to include all stages of product development — from conceptual design and market studies through regulatory approval and manufacturing. It was one of her faculty members, Eric Von Hippel, professor of technological innovation, who stressed how crucial user needs are in product design. "A patient carries a device like an injection pen or infusion pump with her every day. But it's not just about the technology. Getting that device in a patient's hands and having them provide feedback is extremely important in the design development process. I remember what Professor Von Hippel said: 'The actual users are the ones who are going to innovate.' The professors here are some of the most notable and respected thinkers in the world."

Rosen, 31, holds a BS in mechanical engineering from Carnegie Mellon University. Before Helbling, she worked as a design engineering supervisor for Thermal Circuits Inc. and as a process engineer for Raytheon. Her initial interest in medical devices sprung from her work at Thermal Circuits, where she was on a design-to-manufacture engineering team that created neonatal incubators and heating systems used to automate hospital pathology.

Unlike other SDM students who come from far-flung lands, Rosen grew up in Marblehead, MA, and now lives in Lynn with her husband, Christopher Ceruolo. As a commuter student, she takes a full course load (36 units), while also continuing to work at Helbling's office in Kendall Square. "In looking for a graduate program, I wanted to stay at my job and not relocate," she said. "SDM has been a perfect fit for my career goals."

Despite matriculating just last fall, Rosen is already seeing how her education impacts her day job. "When I come back to the office after class, I have the ability to apply what I've learned immediately," she said. "I can feel myself developing as a person, becoming more proficient in making strategic decisions."

Melissa Rosen, second row from top, second from left,
with members of Women in SDM (WiSDM).
All are in the SDM '11 cohort.
On top of her demanding schedule, Rosen has also made it a priority to enrich the experience of her fellow students. She was an organizer for the SWIM (Sloan Women in Management) Fashion Forward event, an annual fundraiser benefiting Artists for Humanity (which gives undeserved youth in the Boston area paid employment in the arts) and Dress For Success (which provides disadvantaged women with professional attire). Rosen was also a panel organizer for the recent MIT Sloan BioInnovations Conference 2011, where industry leaders such as Steve Rusckowski, CEO of Philips Healthcare, and Peter Hecht, CEO of Ironwood Pharmaceuticals, spoke about trends in life sciences and arising challenges. "We are lucky to get speakers with such impressive global industry experience to discuss the challenges future leaders will face."

Rosen is now reinvigorating WiSDM (aka Women in SDM, and pronounced "wisdom") and was just elected the group's chairwoman. Via networking events, WiSDM informally recruits prospective female applicants and supports women to enter the male-dominated field of engineering and management. "I want to encourage the younger, upcoming generation of women."

Rosen's academic goal at SDM is to more deeply immerse herself in what she calls the "holistic systems" of her field: biomedical business strategy, FDA regulations, intellectual property management, clinical trials and political decisions. "I've discovered this is an incredibly complex process. Developing a medical device can take 10 years and billions of dollars. It's not like making an iPhone app." She expects the MIT SDM program will help her gain a deeper understanding of that process, and better manage it as she rises to higher positions of authority in her field. Her SDM thesis will likely focus on the challenges facing the processes of commercializing biomedical products.

"Throughout my career, I want to introduce high-value products to the market that have a positive impact on the way people live," said Rosen. "In addition, I want to help reduce time, cost, and risk through developing those products."

Friday, March 25, 2011

Rafael Marañón: Leadership, Innovation, Systems Thinking

By David Rosenbaum

Rafael Marañón



System Design and Management (SDM) student Rafael Marañón last January won SDM's first annual Leadership, Innovation, and Systems Thinking Award, which honors a member of the SDM cohort who has made strategic and sustainable contributions to his fellow SDM students and the greater MIT community.

Marañón's contributions are multiple. He helped found the MIT Social Media Club and the MIT Student INCOSE Club. He also co-taught ESD.942, a case study approach to how social media is transforming health care, financial services, and other domains in both business and government.

Marañón is an Andalusian Scholar, an award designed to promote the overseas studies of promising executives. His co-founding of the MIT Social Media Club, for which he created the technology platform, derives from his belief that online communication represents an evolutionary leap in the power of people to collaborate. Technology is, he says, an "assistant to the brain" that allows individuals to track their interactions and thereby subject them to "analysis in detail."

Marañón's enthusiasm for connective technologies also drove his involvement with the SDM website (where he is a prodigious blogger) and the Industrial Relations Committee, where he advocates for using social media to "connect alumni, faculty, student, and industry stakeholders." He describes his strategy for leading innovation at MIT as "learning by doing and sharing."

Rafael, who worked in the IT industry as a product marketing manager prior to coming to SDM, developed his skills in system dynamics — a methodology to model human behavior — while at MIT. He is not only applying it to model software process improvement, but also for his thesis on labor migration management.
In his thesis, Marañón builds a systems dynamic model to explain the key factors that helped the European Union-funded circular migration program (in which workers travel from Africa to Spain to harvest the region's strawberries just during the season) succeed in supporting Marañón's home province of Huelva. Through qualitative analysis, he demonstrated that this system helped stabilize the labor supply in times of economic uncertainty (like today), while improving social services for both locals and migrants.

Systems thinking, which provided Marañón with a holistic view of circular migration, helped him see the consequences of policies, including those (such as cutting the number of visas during hard times to create employment opportunities for locals) that had deleterious effects on the Spanish economy because they focused on a single problem, not the totality of the system.

After graduation in June, Marañón will again be exploring new horizons to help high-tech companies empower customers and employees by fostering collaboration and open communications using social media platforms.

Thursday, March 17, 2011

Valuing Flexible Options in Product Development

Valuing Flexible Options in Product Development

By David Rosenbaum

Matt Harper, SDM '10
Photo by Kathy Tarantola Photography
MIT System Design and Management (SDM) student Matthew Harper wants to use concepts from Real Options Analysis (ROA) to reduce the cost of product development projects. In his thesis, supervised by ESD Professor Richard de Neufville, Harper combines the systems thinking approach he learned at SDM with ROA methods typically applied to financial and capital investments.

"ROA has gained significant traction within the general management sphere over the past 10 years," says Harper, although the concept has been around since the early 1970s. While options are used extensively in financial investments and markets, ROA places value on a company's decision to increase, decrease, or cease investment in facilities or projects. Harper's SDM thesis extends the concept to product design and development. Instead of considering options on the scale of a project, Harper's approach considers options on the scope of a product's market focus.

For example, at Prudent Energy, where Harper is a product manager, the question arose whether it was best to design a product for a specific market or for a broad category of applications. "We could optimize the product for market arbitrage (storing energy when prices are low to sell when prices rise), or we could include features that would allow us to participate in emerging, but potentially lucrative, secondary markets." What fascinated Harper was not so much the answer to that question as the concept that a systems thinking approach, combined with the notion of flexible options, could improve strategic decision-making in the development, design and manufacture of new products and capabilities.

If, Harper explains, one wants to maximize the returns from a product over its lifecycle, it would seem logical to build as much flexibility as possible into the product's design and manufacturing system, given that the future is always uncertain. (How much will demand change? Will energy costs go up, down, or remain level? Will new competitors emerge?)

However, Harper's thesis stresses that flexibility has a cost that needs to be accounted for to properly assess a product's ultimate return on investment. By having a product include options for features rather than features themselves, companies can reduce their product development costs while retaining the flexibility to address markets as they develop.

"For example," he explains, "say I'm developing a new carafe. There's a pretty good market for coffee carafes, but I think there might be a future market for tea carafes, too. At the outset, I may attempt to design for both markets. However, ROA can allow me to quantify the savings realized by delaying the decision to include features for the tea carafe market, executing that option in the future only if doing so is economically justified."

The application of such options-based analyses to physical things (as opposed to financial instruments) has led Harper to the very systems thinking-like conclusion that though making effective strategic decisions is important, employing effective processes for framing and analyzing such decisions is even more powerful. "Your option model," Harper says, "may or may not exactly match reality, but the market research, scenario analysis and cost examination you use to develop that model is priceless."

The personal end-state Harper hopes to arrive at, enabled by the knowledge he's gained at SDM, is one that will allow him to fill a role where he can, he says, "conceptualize and deliver truly exceptional products, collaborate with phenomenally talented individuals, and leave the world in a better state than I entered it."

From Oracle India to SDM

By Cody Ned Romano
Photo by Kathy Tarantola Photography

Farrah Tazyeen grew up in Hyderabad, India, a city that Lonely Planet dubbed "Cyberabad" because of its booming IT industry. "My state, Andhra Pradesh, has seen tremendous growth in the previous decade because of technology. I myself have been part of that growth, working in and benefiting from India's booming IT sector," said Tazyeen.

Before she joined MIT's System Design and Management Program (SDM), she worked as a technical consultant for Oracle, helping to develop a system that monitored the disassembly, disposition and reassembly of parts during the overhaul process of aircrafts on the runway. Thanks to the module developed by her team, air marshals were able to reduce the time they spent in the position monitoring from seven days down to just five minutes by seamless integration of various modules into a single user interface.

To organize this and other complex projects, Tazyeen leveraged systems thinking. When starting to develop software, she separated code into sections according to functionality, starting with the largest and most complex parts. Within each part, she identified various interconnected subsystems. Often in this view, the concerns of business and engineering overlapped: how would each line of code impact, for example, the company's overall business flow?

"I had been looking for a master's program that would allow me to continue my involvement on the technical front, while expanding my knowledge of management," Tazyeen said. "SDM is unique because it offers students a hybrid combination of technical and strategic challenges."

In 2006, she earned her B. Eng. with honors in electronics and instrumentation from the Birla Institute of Technology and Science (BITS) Pilani, which became a national university in 1964 with MIT's technical assistance. Shortly after graduating from BITS, Tazyeen went to work for Oracle.

Technical consulting challenged her to multitask. Although Tazyeen worked principally for one consulting project, she needed to make herself available to respond to service requests at any time; day and night, her cell phone rang. As Tazyeen became more senior, she coordinated multiple projects simultaneously, guiding clients in areas such as accounting, taxation and supply chain management.

While consulting work often drew upon Tazyeen's technical background and expertise in the IT industry, it also leveraged her passion for public speaking. When she addressed clients from countries like Korea, she used translators, many of whom had little technical knowledge and sometimes struggled to echo back her speeches. Nevertheless, Tazyeen welcomed these meetings as a chance to find new ways of communicating, and even involved her colleagues in this pursuit by organizing Toastmasters sessions at Oracle.

Coming from the software industry, Tazyeen says that SDM courses have introduced her to peers from different fields whose experiences in system architecting correlate to her own. Lectures on product development and innovation encourage her to ask the question: how can we make innovations in technology more widely accessible?

After graduating from SDM, Tazyeen will use her enhanced systems thinking perspective to develop better IT products, and she hopes to make these products more widely accessible to consumers, particularly in developing regions of India.

"Technology has not yet benefited everyone — but it can. I would like to contribute somehow to India's grassroots technologies."

Monday, March 14, 2011

Three SDM Teams Advance in MIT $100K Competition

By Kathryn O'Neill

Two teams connected to MIT's System Design and Management Program (SDM) have been named semifinalists in the annual MIT $100K Business Plan Competition, an event called "the granddaddy" of business-plan contests worldwide.

A third SDM-associated team is a runner-up in the competition, which received a record 260 entries this year. "I was delighted to hear so many SDMs were advancing in the $100K, but I wasn't surprised," said SDM Industry Codirector Joan Rubin. "Looking at problems from a systems perspective is a good way to find innovative approaches to business problems."

The $100K named just 25 semifinalists—five in each of five categories. Each semifinalist receives a $1,000 expense account to fund the team's venture and enters a mentorship program to help members flesh out their business plan in advance of the competition finals in April.

"It was one of my dreams to take part in this grand event," said Rupreet Singh Soni, SDM '11, whose team is a runner-up, earning the chance to compete for a "wild card" spot. "This competition not only allows students to come up with cutting-edge ideas with regard to business, but also nurtures entrepreneurship."

The three SDM teams are:
  • ReceiptsOnDemand, a business designed to replace paper receipts with an electronic system, is a semifinalist in the Web/IT category. The team was formed by three first-year SDM students—Hassan Mousaid, Ke Ning, and Alex Thomas—and two MIT Sloan School of Management MBA students—Neheet Trivedi and Michael Goulet.
  • Evolving Technologies, a venture focused on developing an endoscopy device to meet the needs of patients and physicians in impoverished communities, is a semifinalist in the Emerging Markets category. The team was formed by Avi Latner and Sassan Zelkha, both SDM '10, with members from outside MIT.
  • Aulus Mobile, a team that includes Soni and Vivin Nath, SDM '11, Sloan MBA student Jeff Anderson and three member from the MIT Media Lab, has a "wild card" spot in the Products & Services category. Aulus Mobile is developing an inexpensive mobile device to detects eye cataracts. As a runner-up, Aulus Mobile will be have to compete with 24 other teams for the last two semifinalist spots. "I hope for the best to come in the future rounds," Soni said.
"We wish all of these teams the best as they progress to the next stage of the competition," Rubin said.

Designing a Business Venture with System Thinking: ReceiptsOnDemand enters MIT $100k semi-finals

(Left to right) SDM students Ke Ning, Hassan Mousaid and Alex
Thomas joined Sloan MBA ’12 student Michael Goulet and Neheet
Trivedi (not shown) for the 2011 MIT 100K Business Plan Competition.
Their team, ReceiptsOnDemand, is one of 25 semi-finalists.
This year, a record number of 260 teams entered their business plans to the 2011 MIT 100K Business Plan Contest. Just 25 of these teams were selected to advance into the semi-final round.  One consists of three first year System Design Management (SDM) ’11 students --  Hassan Mousaid , Ke Ning, and Alex Thomas, who teamed up with Sloan MBA ’12 students Neheet Trivedi and Michael Goulet who will enter next round of competition as one of the five best teams in the Web/IT track.

The vision of team, named ReceiptsOnDemand, is to become a major provider of real-time electronic retail solutions. Although they have identified several key business opportunities in the retail industry their solution does not focus on any one area of the business or niche product. Rather they view the problem faced by retail storeowners and their customers as parts of an overall system. By understanding how things influenced one another within the system, they sought to solve the problems with a holistic approach.

ReciptsonDemand’s cloud-based software platform would allow retail stores to replace reams of costly paper receipts with electronic versions. Shoppers would be able to access their receipts anytime, anywhere through a variety of channels such as email, rich mobile applications and the web. As a result, they would find it considerably easier to run expense reports, return products and claim warranties.

In addition, ReceiptsOnDemand will equip storeowners with real-time customer and market insight to help them make effective business decisions. This is achieved through “SocialRetail” - a novel social analytics feature that combines structured transactional data (collected via electronic receipts) and unstructured information from social media (such as Twitter and Facebook) to provide real-time insights into customer sentiment and buying trends. The results of the sentiment analysis could be used, for example, to augment the impulse buying decisions of customers and business decisions of retail stores.

Join us in congratulating the ReceiptsOnDemand team and wishing them the very best in their future endeavors.

Team biographies
Hassan Mousaid is pursuing his Master of Science in Engineering and Management at MIT’s System Design and Management Program and his PhD in Computer Science at the University of Waterloo.  Mousaid has 10 years of experience in software engineering, software architecture, design and development.  During his professional experience, Hassan served in various technical and managerial roles such as enterprise architect, technical lead and IT project manager.   Hassan led the architecture of applications that won industry awards, such as the Aite Group’s Best-in-Class Awards.  He is currently working at Philips as a senior architect and holds an Master of Business Administration and a Master of Science from Texas A&M.

Ke Ning is a first year student in MIT’s System Design and Management (SDM) Program. Ning spent 10 years in the software industry as a technology lead, developing large scale software products. He has worked at  Qualcomm, NVIDIA, Analog Devices. He was also a founding member of Axis Semiconductor, a micro-processor start-up. Ning holds 7 technical patents and has authored numerous publications. He holds a Ph.D. in Computer Engineering from Northeastern University, an M.S. degree in Electrical Engineering from the University of Minnesota and a B.S. in Physics from the University of Science and Technology of China.

Alex Thomas is pursuing his Master of Science in Engineering and Management at MIT’s SDM program. Prior to coming to MIT, Alex spent 10 years at SAP Labs, the R&D division in India. During this time he served in various technical and managerial roles such a technical lead, development architect and development manager. As development manager he started and led a team of 15 engineers to develop middleware for SAP Business ByDesign—SAP’s cloud-based solution for small- and medium-scale businesses. Thomas also holds a Master’s degree in Information Technology from the International Institute of Information Technology, Bangalore and a Bachelor’s degree in Architecture from Mumbai University in India.

Neheet Trivedi has seven years of experience in politics, investment banking, and energy finance. He has worked with entrepreneurs throughout Latin America to build and finance clean energy projects. He is a first year MBA student at the MIT Sloan School of Management.

Michael Goulet is a first year MBA student at the MIT Sloan School of Management.  Prior to Sloan he was a management consultant in strategy, operations, M&A due diligence, partnerships, and supply chain strategy. He holds a B.S. in mechanical and aerospace engineering and an MEng. in Engineering Management from Cornell University.

Sunday, March 13, 2011

SDM Best Thesis analyzes costs of software system complexity - SDM Pulse Spring 2011

By Andrei Akaikine, SDM ’09

Andrei Akaikine
SDM ’09
Editor’s note: Andrei Akaikine was awarded the SDM Best Thesis Prize in October 2010 for his thesis, “The Impact of Software Architecture on Product Maintenance Efforts and Measurement of Economic Benefits of Product Redesign.”
“If it ain’t broke, don’t fix it” is the basic principle used to manage complex socio-political and engineering systems. For many engineers, the risk of upsetting a system’s stability outweighs the benefits of attempting to improve it when there is no evident flaw.
However, maintaining a complex system at a “good enough” level of functionality comes at a cost. In systems where stability is paramount, personnel dealing with small emergencies traditionally rely on “Band-Aid” fixes that increase complexity and heighten the risk of destabilizing the whole system with each new modification, however minor.
In most cases, a product’s lifetime maintenance cost overshadows the cost of initial product development by a large margin. Based on the empirical data for the computer software industry, the cost of a fix grows exponentially between each phase of the product’s life cycle. Some sources estimate that activities during the maintenance phase may consume as much as 75 percent to 90 percent of total product lifetime expenses.
Measuring costs associated with maintaining complex computer systems is one of my long-time interests. Having spent more than five years working in product support and sustained engineering at Microsoft, I have seen the effects of product architecture complexity on maintenance costs and overall software system stability. Combining my interests with the knowledge that I acquired in MIT’s System Design and Management Program (SDM), I focused my SDM thesis research on the following three questions:
•          Is there a relationship between engineering efforts required for a basic maintenance task and the overall software system complexity?
•          Are any components more susceptible than others to change during system maintenance tasks?
•          Can the redesign of a system be economically justified?
To answer these and other questions regarding the effects of system complexity on the cost of software maintenance, I designed an experiment based on data from the industry. The core idea was to demonstrate a correlation between some numerical measure of a system’s complexity and engineers’ productivity.
I studied two versions of a mature software product.
The chosen product had undergone a significant redesign between these two versions that involved rewriting an estimated 70 percent of the product’s code. However, most of product’s functional requirements did not change. This provided a basis for an experiment with few externalities.
In the experiment, I measured the effort engineers spent making a code modification associated with a corrective change request. For each version of the product, I tallied about 400 corrective changes performed during the first 30 months after release. I then used the time that engineers reported working on each change to estimate their productivity.
To measure the initial product architecture complexity of the product, I chose the methodology developed by Alan MacCormack, MIT visiting associate professor of technological innovation, entrepreneurship, and strategic management (see article, page 4), and Carliss Baldwin, the William L. White professor of business administration at Harvard Business School. This methodology is based on the application of design structure matrices (DSMs) to map dependencies between system components. I used DSMs to compute the design structure complexity measures that were most suitable to assessing software system maintainability (see Figure 1).

Figure 1: Visibility matrices of the product before and after the redesign.
Visibility matrix for the old product is much denser, indicating the high propagation cost.
The first complexity metric I used measures the degree of “ripple effect” propagation through the chain of dependencies across system elements. Propagation cost predicts the percentage of system components that can be affected, on average, when a change is made to a random design element. Propagation cost is a single numerical measure that characterizes the interconnectedness of the elements that comprise the product system.
For each design element, two other complexity measures can be defined: 1) a measure of dependencies that flow into an element—fan-in visibility; and 2) a measure of dependencies that flow out of the element—fan-out visibility. Based on fan-in visibility and fan-out visibility measures, components of the system may be characterized into four types. MacCormack et al. define these types as core, peripheral, shared, and control (see Figure 2). These few measures captured the important complexity attributes of the hypotheses I tested in my research.
My experiment showed a clear correlation between initial product complexity and engineers’ productivity. A decrease in the product’s propagation cost (or complexity) from 38 percent to 11 percent resulted in 10 percent to 14 percent improvement in engineers’ productivity. Besides engineer productivity, such metrics as amount of rework and effort needed for a single module change improved by 16 percent to 25 percent.
Figure 2: Characterization of components
by visibility measures.
Modules of the core type were found to be more likely to be touched during a random corrective code change.
Out of 542 unique modules that were changed, 404 were of the core type. The frequency with which core modules were modified is disproportionate to their share in the whole system: 85 percent of modules that were modified more than once during the studied period were core modules. Some of them were modified 10-12 times.
I concluded that product architecture redesign that reduces the structural complexity of the software system may become economically viable and desirable as the product support cycle grows in length and the pressure to lower maintenance costs increases. Considering that in some cases, maintenance can consume up to 90 percent of the total product life-cycle cost, an improvement of 10 percent to 15 percent in productivity may result in savings almost as large as the initial cost of product development. Of course, any redesign may have downsides that need to be considered before the decision to redesign an existing product can be made.
It is essential for a development organization to perform a comprehensive net present value (NPV) analysis before investing resources into redesign to avoid any NPV-negative initiatives.
That said, it’s clear that the economic benefits of controlling the complexity of product architecture have significant managerial implications. Product development organizations should measure the complexity of new and legacy software products to control their total life-cycle costs.

Saturday, March 12, 2011

SDM course helps students build a leadership roadmap - SDM Pulse Spring 2011

By Shalom S. Saar, senior lecturer, MIT Engineering Systems Division

Editor’s note: In this article, Senior Lecturer Shalom S. Saar describes Leadership: The Missing Link, a required course in MIT’s System Design and Management Program (SDM).

Shalom S. Saar
SDM’s leadership course is designed to prepare students to become better decision-makers. Students emerge with a richer understanding of their strengths and weaknesses—as well as a roadmap for leveraging their abilities to become more successful leaders.
Too often, students who return to school for upper-level engineering degrees overemphasize their need for technical skills and underemphasize the importance of gaining people skills. Yet the reality is that conflict is a growth industry.
As business becomes more global, conflicts proliferate—it’s simply too easy to read an unfamiliar environment the wrong way, and different leadership styles prove more successful in different situations. While the technical side of being at MIT is important, the people side is just as important, if not more critical.
The purpose of Leadership: The Missing Link is to enhance each student’s ability to lead and mobilize others. Helping students become aware of themselves and their impact on others can increase their level of competency to work through others. To paraphrase the ancient Chinese general Sun Tzu, author of The Art of War, if the executive doesn’t know himself and doesn’t know his opponents, his chances of winning are very low.
The course utilizes various instruments, real-world case studies, and simulations. While the first part of the course focuses on understanding oneself, the second part assists students in developing the skills needed to motivate and influence others. We focus on such topics as strategic thinking, leadership styles, personality types, approach to conflict, and emotional intelligence. In addition, we use a 360-degree feedback diagnostic tool that each SDM student is required to complete during orientation.
Students conduct the 360-degree assessment by requesting feedback on 25 leadership competencies from a wide array of colleagues—including supervisors, subordinates, peers. The report they get from this instrument is usually eye opening; it reveals that the perception someone has of himself is not always the perception others have. One woman might think she’s a good listener, for example, only to discover that her friends and colleagues think she ignores their views.
By the end of the course, students are able to assess their strengths and weaknesses, but the class is also prescriptive. Students learn how to probe, listen, influence, negotiate, and motivate.
In one exercise, for example, students learn the value of bringing people to their own solutions—an effort that builds trust and loyalty. Leaders need to know how to build and sustain trust in order to motivate followers. And, once trust breaks down, it can be impossible to regain. For that reason, the course also includes simulated conflicts that allows students to experience the corrosive and contagious nature of mistrust.
As a final exercise, each student is asked to submit a paper analyzing an unsuccessful experience. This can range from having a conflict with a boss to not getting along with a peer. By reflecting on the experience and relying on the findings from the various instruments, students are able to understand the dynamics and their roles in making things worse. By examining their role, they come up with constructive alternatives to the problem they faced.
Lastly, each student has the option of meeting the instructor for one hour privately to go deeper into the results of the instruments and to get coaching and counseling. By the end of this course, students have learned to enhance their effectiveness as leaders—developing a set of “soft skills” that often make the crucial difference in human relations.
_____________________________
Shalom Saar’s course was the ideal capstone for the management aspect of the SDM program. [His] teaching is without parallel. He brings situations to life ... and makes the time spent in this class among the most valuable time of your MIT student-career.
            —Blade Kotelly, SDM ’10
I am not sure what I’ll do after SDM, [but] wherever I go I’m bound to face leadership and communication challenges for which this course was very useful.
            —Avi Latner, SDM ’10
Shalom Saar is a wise instructor who creates a trustful and interactive learning environment, which together with cutting-edge diagnostic tools helped me redefine questions on leadership, trust, collaboration, authority, conflict resolution, and human interaction.
            —Azamat Abdymomunov, SDM ’10
As leaders, we will have to know how to get the best out of people no matter what their personalities. We learned how to lead and structure work for individuals with a variety of personality types, building concepts and developing practices that will be effective among as diverse a group as possible.
            —Matt Harper, SDM ’10

Friday, March 11, 2011

Faculty member outlines value of software system architecture - SDM Pulse Spring 2011

By Alan MacCormack, visiting associate professor, MIT Sloan School of Management

Alan MacCormack
Editor’s note: Alan MacCormack is a member of the Technological Innovation and Entrepreneurship Group at the MIT Sloan School of Management. He teaches Sloan’s core class in innovation and has served as thesis advisor for several students in MIT’s System Design and Management Program (SDM), including Andrei Akaikine, SDM ’09 (see story, page 1).
Over the last 10 to 15 years, even the most traditional of industries have come to rely on software for everything from inventory control to vehicle navigation. The average automobile today has more software than the first Apollo moon rocket. Your garden variety microwave may even have an algorithm for cooking popcorn to fit your specific tastes. Despite this dramatic increase in the pervasiveness and importance of software, however, many companies lack a fundamental understanding of the architecture underlying their code. This problem costs firms millions of dollars per year.
Ask systems designers at any major commercial software company to describe the architecture of their product on a whiteboard. They’ll typically draw a diagram showing a number of boxes (modules) that perform highly specific functions, with a few neat connections between them.
My research shows however, that if you actually measure the interactions between boxes at the code-level, you’ll find the architecture is much more tightly coupled than anyone would think. Coupling has its virtues—tight interactions between different pieces of code can lead to increased performance in areas such as speed or memory footprint. But coupling also has major drawbacks, with respect to the ease with which software can be corrected and adapted to meet future needs.
Virtual systems are fundamentally different from other kinds of systems. As an information-based product, software appears to be easy and quick to change—which can be an advantage and a disadvantage. There are no physical changes to be made, yet the complexity of modern software is such that even small modifications can ripple through a system with unintended consequences. Software appears to be malleable, but in practice, the architecture of many systems is opaque. A developer dare not change them too much for fear of creating a tangled web of dependencies and changes to upstream files.
Furthermore, unlike industries such as automobiles and airplanes, which create new platforms from the ground up every few years, modern software development efforts rarely start with a clean slate. Most systems have a significant legacy, on top of which new features and functionality are built. Unfortunately, it’s not obvious from looking at the older code which pieces are connected to which others. It’s not like working with a mechanical system, where you can see connections simply by inspecting the product, or reverse-engineering its design. Unfortunately, this hard-to-understand legacy code often embeds assumptions and design decisions that are no longer optimal for the system.
Why are initial design decisions often so out-of-whack with the current requirements for a software system?
One reason is that the original design may have been built quickly, by a small company or startup more focused on releasing its first product rapidly than on building a framework to last for many years and multiple product evolutions. Software engineers design programs to meet their immediate needs, and in a startup, there is no guarantee that you will be around in 12 months. Speed is of the essence, and any performance edge is pivotal, no matter how you achieve it. Ten years later, however, when the war for market share is over, the needs of a user might be better served by a much more modular, maintainable, and adaptable system. In essence, early design decisions create a “technical debt” that must be paid by all those that follow.
Let me provide a micro-level example of these dynamics. Alice might decide to use a piece of functionality that Robert has already designed in his module, so she writes some code to “call” his function from her module. This saves time, but creates a dependency between Alice’s modules and Robert’s that may not be transparent to the system architect. Five years down the line, when Robert and Alice have both retired to Tenerife, that dependency may be a complete surprise to a programmer needing to make a change. Changing code in Robert’s module may well cause Alice’s module to cease functioning.
The work that Andrei Akaikine, SDM ’09, did in the thesis |I supervised provides a great example of the costs that arise from an architecture that is overly complex. In his thesis, he examined a software system with a long history, which generated significant maintenance costs each year. Every change could create unexpected problems and require additional fixes to other parts of the system. The owner of this system—a large commercial software firm—decided to redesign the software with the goal of adding new features to the system, while simultaneously reducing its complexity (by reducing the coupling between elements). Akaikine showed that the result of this redesign was a significant reduction in maintenance effort, as captured by the time it takes to fix defects.
Of course, any major redesign involves significant costs of its own—management has to decide if these costs are warranted. Unfortunately, many businesses make these decisions based on gut-feel and intuition, rather than a rigorous analysis of the likely payoffs. We need much better data to make informed decisions, and the software industry is woefully lacking in such data. Ultimately, this is why the work I have done with Akaikine and other ESD students—including Daniel Sturtevant, SDM ’07, who is working on his PhD—is important. We are among the first research teams to visualize and measure the extent of technical debt in legacy software systems.
To achieve this goal, we have developed pioneering methods for visualizing and measuring attributes of a software architecture that can help us assess its underlying structure. Consider a well-known example from a recent paper, in which we look at the Mozilla web browser. After its release as open-source software in 1998, a major redesign effort was undertaken on the system, with the aim of making the codebase more modular, and hence easier to contribute to. The design structure matrices (DSMs) from before and after this redesign (see Figure 1) illustrate what happened. The modular architecture that resulted facilitated contributions to the code by creating fewer unintended interactions between components. Before the redesign, each component was, on average, connected to 18 percent of other components. Afterward, this figure dropped to below 3 percent.
Ultimately, different designs will have different performance characteristics along a variety of important dimensions, making techniques like ours valuable for exploring design trade-offs. A highly integrated design is likely to be faster, while a highly modular design may be more reliable. A designer must consider carefully what the product needs to do to arrive at the optimal design for her objectives. For example, if a system has to last 10 years, and you have no idea what it will need to do at the end of that time, the software must be designed to be extremely flexible and evolvable. Unfortunately, very few software companies practice such forward-looking “systems thinking.”
How should a firm begin? Nobody should rush headlong into full-blown re-factoring of a major system, given we are still in the infancy of understanding how these efforts work. Indeed, our research reveals that a manager’s intuition about where to start such an effort is frequently wrong, given the perceptions of an architecture and the realities embedded in its source code are often in conflict. Software companies first need to generate data on measures of architecture, and begin to link these measures to performance outcomes that they care about. Most firms tinker with and redesign their software all the time—in effect they run hundreds of small experiments every year. Armed with a careful assessment of this data, they will be better placed to assess what works and what doesn’t. Ultimately, we know complexity hurts. But reducing it is also a complex endeavor.
Figure 1. These two design structure matrices illustrate the interdependencies that
existed within Mozilla’s software architecture before (left) and after a major redesign.

Thursday, March 10, 2011

SDM alum explains need for negotiation in software architecture - SDM Pulse Spring 2011

By Christine Miyachi, SDM ’00

Christine Miyachi, SDM ’00
Editor’s note: SDM alumna Christine Miyachi is a principle systems engineer and architect at Xerox Corporation. She also writes a weekly blog about software architecture: abstractsoftware.blogspot.com.
“An accidental architecture emerges from the multitude of individual design decisions that occur during development, only after which can we name that architecture.”
                —Grady Booch, pioneering software engineer
I enrolled in MIT’s System Design and Management Program (SDM) because I wanted to become a lead software designer/architect/systems engineer. I thought the program would give me the technical skills I needed—and it did. But I also learned that leadership and negotiation are critical to architecting successful software.
Today, my daily work involves myriad decisions that depend on both technical expertise and an understanding of business needs. My background gives me the skills to create an initial framework that will persist. However, even after an architecture has been designed and implemented, information about how the system will and can work is often discovered, requiring design shifts to continue to support the business.

Figure 1. The waterfall method of software design
calls for work to be done in stages, without
any return to earlier stages.
 It’s important to understand—and to be able to communicate—that creating software is not like an assembly line where every piece of work is completely uniform and understood. In fact, it’s an intellectually intensive and often unpredictable process.
Figure 2. In iterative or agile design, requirements, design, and
implementation is done in each short cycle, with functionality
delivered to stakeholders after each iteration.
It’s helpful to compare and contrast two methodologies software developers commonly use: waterfall (Figure 1) and iterative/agile (Figure 2). Pure waterfall proponents believe that all architectural decision must be made upfront. Pure agile proponents say that nothing needs to be decided upfront because methods, requirements, design, and implementation is done in short cycles, with functionality delivered to the stakeholders in each iteration. However, most software architects agree that a combination of upfront and iterative decisions contribute to successful software architecture.
In Ken Schwaber’s book Agile Software Development with SCRUM, he discusses the empirical model of a process that incorporates the unexpected. Control is established through frequent adaptations, he explains.
My experience with software architecture is very close to this. While it is tempting to be very rigid in architecture and not allow changes, this strategy causes conflicts and often produces a system that does not meet the ever-changing business needs.
For example, in one project I worked on many years ago, we selected a framework that auto-generated code. This framework became outdated, the company that provided the auto-generating tools went out of business, and we got to the point where we couldn’t make changes to this module in our system. We actually had to design other programs around it. Finally, thanks to the courage of a few, this section was redone.
The challenge in software is that, unlike other engineering disciplines, the output is malleable. Changes can be made fairly easily—at least before the product ships. I think that’s why I’ve found we always end up with what Grady Booch calls an “accidental architecture.” The final product is a result of decisions made following each iteration—and all of these decisions require a lot of negotiation.
Here are three examples of how design and architecture are negotiated in software. They illustrate the tools and skills I learned while an SDM student, in particular the leadership and negotiation methodologies that are critical to architecting successful software.
Case 1: I’m not the expert, but I bring a team of experts in to make a decision.
Experts from different disciplines often don’t agree, so in this case I act as a negotiator, guiding the team to a solution—usually in one meeting because time is always a factor. When negotiating and brainstorming, I make sure that everyone’s voice is heard, and I work to get the quiet people to speak up. It’s important not to make anyone appear stupid, and not to use anger or aggression to win your case. That usually backfires.
Figure 3. Using a template like this one to establish a mind map
can help bring logic and rigor to the decision-making process.
I use tools such as mind maps or decision matrices to bring logic, rigor, and a common understanding to the discussion. The mind map (Figure 3, a tool taught in SDM’s system architecture course) and the decision matrix (similar to the quality function development matrix taught in SDM’s product design class) are both ways of visually representing the relationship of ideas. Axiomatic design, another method taught in the SDM program, is similar.
Case 2: I disagree with someone else on a design decision.
When should I dig in my heels and when should I compromise?
I have a colleague on my team who always wins design arguments because he has a very strong personality. Other people back down simply because they don’t want to put up a fight. Sometimes I do fight, but I can also compromise. The question is when to hold my ground and when to give way.
The following guidelines, taught in SDM, have proved useful:
•    If I realize the other person is correct (I see something I didn’t see before), I will agree to change.
•    If I think the proposed decision direction will hurt the project, I will fight it.
•    If I think we can make a change later with no ill effects, I will sometimes wait and put the change in a parking lot.
Of course, I’m not always right. Sometimes I end up wishing I had fought harder and sometimes I wish I had compromised. I’m always learning.
Case 3: A key decision is made, then changed.
This scenario is common in software architecture, partly because of the product’s malleability and partly because leadership and teams are subject to change.
For example, I once acted as a negotiator and an expert for a key architectural decision. We developed a set of requirements, weighed their importance, and looked at four solutions to meet those requirements. We rated each solution against those requirements, and two were very close. One was more robust but not as scalable to low-end computing systems (not a lot of memory, weaker CPU, etc). One was less robust but very scalable. Although one team member objected, the team ended up choosing the more robust system.
About a year later, after some shifts in the business, we had to revisit the decision. The market had changed and we had to go with a less robust but more scalable solution. The lesson is that as an architect you must be able to gauge if a solution is still viable in the business climate, which is constantly and sometimes drastically changing. We had to adapt or we would have lost business. It’s also essential to document decisions as they are made because this will save time and increase efficiency by eliminating the need for “archaeological excavation.” In short, if the business changes, you will more easily see when past logic is no longer valid and know that it’s time to make some changes.
The bottom line is that software architects need more than technical and managerial expertise—they need to know how to negotiate design decisions and use a toolbox of ways to examine tradeoffs logically—something SDM provided for me.
Today, these SDM tools help enhance the contributions I and my team members can make to Xerox. This includes the expertise to facilitate and lead groups to create an initial framework that will persist, but as importantly, the leadership and negotiation skills to make design shifts that will continue to support the company as it evolves.