Search in book...
Toggle Font Controls
Create new playlist

Name your new playlist

Playlist description (optional)
Sign In

Email address

Password

Forgot Password?

or

Continue with Facebook

Continue with Google
Sign Up

Full Name

Email address

Confirm Email Address

Password

or

Continue with Facebook

Continue with Google

11.6 Summary

Complex systems frequently face challenges managing stakeholders. There are many stakeholders, and their relative priority can be unclear, especially if they provide a non-monetary input such as regulatory approval or if they do not participate in a bilateral exchange with the firm. Additionally, complex systems with new architectures face the challenges of all new products in identifying latent needs, as well as the needs served by existing products in the market.

In this chapter, we have focused on deriving prioritized goals for the architecture, based on stakeholder needs. Several important ideas have emerged in this discussion. First is the idea of value as an exchange, where your outcomes meet their needs, and their outcomes meet your needs. Second is the idea of prioritizing stakeholders according to their importance to you. Third, represent the goals in a System Problem Statement, and pay careful attention to its creation, because small differences in the problem statement can shape the problem-solving activity.

11.7 Box Case Study: 1998 Nagano Winter Olympics: Stakeholders in IT Architecture

By Dr. Victor Tang. Dr. Tang was the Director of IT Client Relations for IBM’s 1998 Olympic Winter Games, with responsibility for architecture and systems management.

Introduction

IBM was one of 11 top sponsors for the 1998 Olympics Winter Games in Nagano, Japan. Each sponsorship has been reported to cost $60 to $80 million (Humphreys 2008, Djurdjevic 1996). As the IT sponsor, IBM was contractually obligated to provide and operate the entire IT system for the games, in return for which, IBM was allowed use the Olympic logo for marketing.

The Challenge

IBM’s scope was daunting. It had to provide, build, operate, and maintain a customized IT system just for the Games. This system had to compute and deliver competitors’ results for stakeholders, media, and the general public; update and archive athletes’ records; accredit athletes and staff; record drug testing results, and so on (Figure 11.18). The built system consisted of 25 million lines of software to support 10 mainframes, 5,000 PCs, 1,500 printers, and 160 servers networked through 2,000 routers that served about 150,000 athletes, officials, and volunteers. Key stakeholders included the IOC, the media, games administration, sports federations, the Nagano Organizing Committee (NAOC), and dozens of others. The Winter Olympics IT system is a system-of-systems (SoS) in which each constituent system has a different stakeholder with distinct priorities, interests, and biases.

Figure 11.18 The Nagano 1998 Olympics IT system, clients, and users.

Figure 11.18 Full Alternative Text

Beyond the daunting scope, IBM faced a loss of confidence from the IOC and its stakeholders as a result of poor execution at the 1996 Olympic Summer Games in Atlanta. The IOC told IBM that they “didn’t find any part which worked well.”

Rethinking IBM’s Strategy

For the Atlanta Summer Games, IBM had the wrong strategy. It chose to showcase products, technology, and systems that were not ready for showcasing. This lack of readiness caused widely visible disruptions in Games operations and business management. To avoid another fiasco, IBM changed its myopic product-technology-centric strategy to one in which products and technology were the means to deliver a service, not the end itself. IBM communicated this strategic shift as: “IT as a service . . . helping those running the Games, run the Games . . . [and] enhancing the Olympic experience.” In other words, IBM explicitly moved the system boundary.

The social architecture was implemented using the organizational pattern of X-teams (Ancona et al. 2009). X-teams are formed by enabling domain-experts to work across organizational boundaries with their counterparts. IBM formalized this approach by announcing that (i) IBM was inviting stakeholders to participate in its IT system development, and that (ii) IBM was embedding itself in the Olympic stakeholders’ processes. There was a sharp contrast in how development work was completed before and after the formation of X-teams (Figure 11.19). This approach to stakeholders’ interactions enabled IBM engineers to develop the Games IT solution with a substantially more comprehensive understanding of the technical requirements and reciprocal organizational dependencies. Stakeholders became competent spokespersons and also credible advocates for IBM’s work. Stakeholders were no longer just critics; they were part of the IT development team.

Two tables represent without x-teams, and with x-teams have 7 columns and 9 rows each. — Figure 11.19 Co-development with and without X-teams.

Figure 11.19 Full Alternative Text

The Requirements

From the Atlanta debacle, four “IBM Must Do” goals emerged: (i) meet all technical and management system requirements, (ii) ensure no surprises during the games, (iii) provide 24/7 operations, and (iv) ensure highly secure and usable systems. IBM had its work cut out for itself.

These imperatives were easier to impose than to satisfy. The technical and sports-specific requirements were exhaustively documented in a voluminous library compiled by the IOC and the sports federations. A less formal, but equally formidable, set of technical requirements were those dealing with timing equipment from Seiko; printing and distribution requirements from Xerox; accreditation and security requirements for those providing press, TV, and radio coverage, medical services, transportation, and accommodations; technical training and education for volunteers; and so on. IBM pondered how it could convincingly satisfy this enormous set of requirements.

IBM found the answer in the International Competitions Prior to the Games (ICPG). The practice of the sports federations is to hold competitions, before the actual Olympic Games, using new or modified Olympic rules and IT systems. Many World Cup competitions are ICPGs. The goal is to make sure everything works. Instead of the ad hoc debriefings of the past, IBM held a plenary convocation to discuss IBM’s performance at the ICPGs. IBM invited the winter-sports federations, IOC representatives, and key stakeholders to this meeting in Nagano. They came well armed with papers documenting IBM’s errors and shortcomings. After protracted negotiations, it was decided that solving the documented errors and shortcomings would be interpreted as IBM satisfying all requirements. Thus management-by-exception became the strategy for the “IBM Must Do” work.

The data flow diagram shows flows between results, accreditation, and the internet components, as well as info 98 information management, info 98 terminals, and info 98 email, etc. components. — Figure 11.20 Data flow view of the architecture of the Nagano 1998 Olympics IT system.

Figure 11.20 Full Alternative Text

IBM re-conceptualized the Olympics IT system as a utility (highly secure and plug-&-play usability) to provide data and information to run the games. Networked servers would be the equivalent of a utility’s power plant and distribution grid (with 24/7 availability), applications would be the equivalent of generators, and structured data would be the output of the plant to serve the stakeholders and the public as clients and consumers (Figure 11.20). These concepts were initially received with reserve and skepticism.

Architecting a complex system is seldom a green field endeavor; it must consider the legacy subsystems and components that need not be reinvented but can be reused, modified, or protected. For the Nagano IT System, legacy was concentrated in the Athlete Qualification, Results, Games Management, and INFO98 (a Web-based system for Olympic information) systems. They formed the core of the Nagano IT SoS (Figure 11.18). Clearly, the most important subsystem is the Results System that must process athletes’ performance. These systems were formed into a coherent whole using principles of data and function flow (Pahl and Beitz 1995). In the remainder of this case study, we will focus on the Results System as a concrete example of the Nagano IT architecture.

Architecture is the product of a mapping from function to form. These mappings, except for the simplest systems, are seldom completed in a single step. Rather, they require sequences of deliberate steps. For the Nagano IT system, IBM used the classical pattern of stepwise system decomposition and refinement. For example, the overall Results System is hierarchically decomposed into Results Subsystems for each competition venue. The first-level decomposition of the Results Subsystem is based on the principles of data-function flow within the constraint of using Seiko timing for data entry (input) and the score board (output) for displaying results. IBM provided the IT hardware and software systems that join Seiko’s inputs to Seiko’s output. Figure 11.21 shows how the architectural pattern (Gamma 1995) “reliability through redundancy” was used. The idea is simple, though challenging to implement. In this pattern, key functional components and subsystems are duplicated. Should any of them fail, its duplicate takes over so that operations remain uninterrupted. This pattern was used repeatedly throughout the IBM IT system, ranging from timing interfaces, PCs, LANs, WANs, and databases to medium and mainframe servers—all designed to prevent any single failure rendering the entire IT system inoperable.

A series of images represent the redundant reliability pattern between system components beginning with redundant timing devices, and ending with a C I S token ring L A N. — Figure 11.21 Redundant reliability pattern in the Nagano IT system.

Figure 11.21 Full Alternative Text

1. To paraphrase Clemenceau’s famous dictum, “IT architecture is too important to be left to technical experts.” IT is a technical expression of a business’s policy. IT architecture has to be positioned within the context of a business policy for the architecture to be meaningful to decision makers, stakeholders, and IT users (Henderson and Venkatraman 1983). As a corollary, IT is no longer just about products; it is also about services. Far from being satisfied with just “break/fix and maintenance” services, customers increasingly need knowledge-intensive services to deal effectively with the cradle-to-grave complexities of multivendor and multi-stakeholder social technical systems. These are now known as product-service systems (PSS) (Tang and Zhou 2009).
2. The architect is always accountable for the integrity of the system but is not responsible for its implementation, which must necessarily be delegated. This is particularly true for large-scale social and technical systems. The architect is accountable for the specification of the mappings, descriptions of form, and specification of intended emergent system outcomes. Responsibility for implementation must be delegated and diffuse.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.

Table of Contents for 11.6 Summary

Create new playlist

Sign In

Sign Up

Table of Contents for
11.6 Summary