6

ARCHITECTURE AND INFRASTRUCTURE

Valero Energy, the North American oil and gas refiner, has experienced hypergrowth for the past ten years, mostly through acquisitions.¹ The company's revenue has grown from $29 billion to $90 billion, but with this growth came a mixture of different information technology (IT) systems and applications that were difficult and expensive to manage, and that did not easily integrate into their corporate enterprise resource planning (ERP) system and their business applications suite. Further, in the future, managers wanted to implement a self-service model where business units could create applications themselves in an easy, low-cost manner. For the managers to execute their business strategy, their IT architecture had to be redesigned and their infrastructure updated.

The architecture had to be flexible, able to grow with the company, and easily reused as new systems were needed. The IS organization decided to use an SOA (service-oriented architecture) design in which applications and computing resources were available as components. For example, an order management component might be used by both a customer service application and a profitability analysis application.

The infrastructure for the ERP and business applications suite was SAP's R/3 system. The newer components included a set of 90 services built on SAP's development environment. Further, these core services have been used to create 40 different composite applications, helping management attain their reusability goal and keeping application development costs down. For example, one of the new applications was designed to let wholesale clients view account information via the Internet. The infrastructure used SAP NewWeaver Portal interface to connect to the SAP R/3 CRM (customer relationship management) system data warehouse and to other nonSAP systems. This design gives users a single view into the integrated information.

The results were dramatic. Savings added up for Valero because they did not have to build interfaces between all the independent systems they inherited through the acquisitions. New applications made operations more efficient and effective. One application saved the company a half-million dollars in fees that are charged when a ship sits idle at the dock. Before this new application, the managers did not have a way to monitor tankers as they unloaded oil, and therefore sometimes ships had to wait to unload their cargo. The new application provides visibility to the tankers and communications with employees at the refineries in order to avoid scheduling conflicts and the ensuing costs.

So far, this text explored the organizational, tactical, and strategic importance of IS. As illustrated with the Valero story, this chapter examines the mechanisms by which business strategy is transformed into tangible IS architecture and infrastructure. The terms architecture and infrastructure are often used interchangeably in the context of IS. This chapter discusses how the two differ and the important role each plays in realizing a business strategy. Then this chapter examines some common architectural components for IS today.

FROM VISION TO IMPLEMENTATION

As shown in Figure 6.1, architecture translates strategy into infrastructure. Building a house is similar: the owner has a vision of how the final product should look and function. The owner must decide on a strategy about where to live—in an apartment or in a house. The owner's strategy also includes deciding how to live in the house in terms of taking advantage of a beautiful view, having an open floor plan, or planning for special interests by designing such special areas as a game room, study, music room, or other amenities. The architect develops plans based on this vision. These plans, or blueprints, provide a guide—unchangeable in some areas, but subject to interpretation in others—for the carpenters, plumbers, and electricians who actually construct the house. Guided by past experience and by industry standards, these builders select the materials and construction techniques best suited to the plan. The plan helps them determine where to put the plumbing and wiring. When the process works, the completed house fulfills its owner's vision, even though he or she did not participate in the actual construction. As finishing touches, the owner adds window coverings, light fixtures, and furniture to make the new house livable.

FIGURE 6.1 From the abstract to the concrete—building vs. IT.

An IT architecture provides a blueprint for translating business strategy into a plan for IS. An IT infrastructure is everything that supports the flow and processing of information in an organization, including hardware, software, data, and network components. It consists of components, chosen and assembled in a manner that best suits the plan and therefore best enables the overarching business strategy.² Infrastructure in an organization is similar to the plumbing, wiring, and furnishings in a house; it's the actual hardware, software, network, and data used to create the information system.

The Manager's Role

Even though he or she is not drawing up plans or pounding nails, the homeowner in this example needs to know what to reasonably expect from the architect and builders. The homeowner must know enough about architecture, specifically about styling and layout, to work effectively with the architect who draws up the plans. Similarly, the homeowner must know enough about construction details such as the benefits of various types of siding, windows, and insulation to set reasonable expectations for the builders.

Like the homeowner, the manager must understand what to expect from IT architecture and infrastructure to be able to make full and realistic use of them. The manager must effectively communicate his or her business vision to IT architects and implementers and, if necessary, modify the plans if IT cannot realistically create or support them. For without the involvement of the manager, IT architects could inadvertently make decisions that limit the manager's business options in the future.

For example, a sales manager for a large distribution company did not want to partake in discussions about providing sales force automation systems for his group. He felt that a standard package offered by a well-known vendor would work fine. After all it worked for lots of other companies, he rationalized, so it would be fine for his company. No architecture was designed, and no long-range thought was given to how the application might support or inhibit the sales group. After implementation, it became clear that the application had limitations and did not support the type of sales process in use at this company. He approached the IT department for help, and in the discussions that ensued, he learned that earlier infrastructure decisions now made it prohibitively expensive to implement the capability he wanted. Involvement with earlier decisions and the ability to convey his vision of what the sales group wanted to do might have resulted in an IT infrastructure that provided a platform for the changes the manager now wanted to make. Instead, the infrastructure lacked an architecture that met the business objectives of the sales and marketing management.

THE LEAP FROM STRATEGY TO ARCHITECTURE TO INFRASTRUCTURE

The huge number of IT choices available, coupled with the incredible speed of technology advances, makes the manager's task of designing an IT infrastructure seem nearly impossible. However, in this chapter, the task is broken down into two major steps: first, translating strategy into architecture and, second, translating architecture into infrastructure. This chapter describes a simple framework to help managers sort through IT issues. This framework stresses the need to consider business strategy when defining an organization's IT building blocks. Although this framework may not cover every possible architectural issue, it does highlight major issues associated with effectively defining IT architecture and infrastructure.

From Strategy to Architecture

The manager must start out with a strategy, and then use the strategy to develop more specific goals, as shown in Figure 6.2. Then detailed business requirements are derived from each goal. In the Valero case, the strategy was to provide a single face to customers, and the goal was to integrate all the acquisitions. The business requirements were to integrate the information systems into a single, flexible system. By outlining the overarching business strategy and then fleshing out the business requirements associated with each goal, the manager can provide the architect with a clear picture of what IS must accomplish and the governance arrangements needed to ensure their smooth development, implementation, and use. The governance arrangements specify who in the company retains control of, and responsibility for, the IS. Preferably this is somebody at the top.

Of course, the manager's job is not finished here. Continuing with Figure 6.2, the manager must work with the IT architect to translate these business requirements into a more detailed view of the systems requirements, standards, and processes that shape an IT architecture. This more detailed view, the architectural requirements, includes consideration of such things as data and process demands, as well as security objectives. These are the architectural requirements. The IT architect takes the architectural requirements and designs the IT architecture.

From Architecture to Infrastructure

Valero's decision to use a service-oriented architecture led to the design of a number of services and composite applications. This illustrates the next step, translating the architecture into infrastructure. This task entails adding yet more detail to the architectural plan that emerged in the previous phase. Now the detail comprises actual hardware, data, networking, and software. Details extend to location of data and access procedures, location of firewalls, link specifications, interconnection design, and so on. This phase is also illustrated in Figure 6.2 where the architecture is translated into functional specifications. The functional specifications can be broken down into hardware specifications, software specifications, storage specifications, interface specifications, network specifications, etc. Then decisions are made about how to implement these specifications; what hardware, software, storage, interface, network, etc. to use in the infrastructure.

FIGURE 6.2 From strategy to architecture to infrastructure.

When we speak about infrastructure we are referring to more than the components. Plumbing, electrical wiring, walls, and a roof do not make a house. Rather, these components must be assembled according to the blueprint to create a structure in which people can live. Similarly, hardware, software, data, and networks must be combined in a coherent pattern to have a viable infrastructure. This infrastructure can be considered at several levels. At the most global level infrastructure may focus on the enterprise and refer to the infrastructure for the entire organization. Infrastructure may also focus on the interorganizational level by laying the foundation for communicating with customers, suppliers, or other stakeholders across organizational boundaries. Sometimes infrastructure refers to those components needed for an individual application. When considering the structure of a particular application, it is important to consider databases and program components, as well as the devices and operating environments on which they run. The application-level infrastructure reflects decisions made at the enterprise level. The following discussion relates to infrastructure and architecture at the enterprise level.

Often when referring to an infrastructure, the underlying computer system is called the platform. A platform refers to the hardware and operating system on which applications run. For example, in the laptop/PC industry, technologists talk about a “windows platform,” which refers to personal systems whose hardware supports the windows operating system. Another common platform is the “Mac platform,” which refers to the latest operating system from Apple running on a Macintosh laptop or PC. In the smartphone industry, the “Android platform” and the “iPhone platform” are two examples frequently seen. Both may run the same applications from a user's perspective, but that is because the vendor of the applications has written two versions—one for each platform.

A Framework for the Translation

When developing a framework for transforming business strategy into architecture and then into infrastructure these basic components should be considered:

• Hardware: The physical components that handle computation, storage, or transmission of data (e.g., personal computers, servers, mainframes, hard drives, RAM, fiber-optic cabling, modems, and telephone lines).
• Software: The programs that run on the hardware to enable work to be performed (e.g., operating systems, databases, accounting packages, word processors, sales force automation, and enterprise resource planning systems). Software is usually divided into two groups: system software and applications. System software, such as an operating system like Microsoft's Windows, Apple's Lion, Linux, iPhone's iOS, and Android, specifies the platform on which the applications run. Applications, on the other hand, are software that automate business and personal tasks such as storing data, transferring files, creating documents, calculating numbers, texting, listening to music and playing games.
• Network: Software and hardware components, such as switches, hubs, and routers, that create a path for communication and data sharing according to a common protocol. Some networks are private, requiring credentials to connect. Others, like the Internet, are public.
• Data: The electronic representation of the numbers and text. Here, the main concern is the quantity and format of data, and how often it must be transferred from one piece of hardware to another or translated from one format to another.

The framework that guides the analysis of these components was introduced in the first chapter, in Figure 1.8. This framework is simplified to make the point that initially understanding an organization's infrastructure is not difficult. Understanding the technology behind each component of the infrastructure and the technical requirements of the architecture is a much more complex task. The main point is that the general manager must begin with an overview that is complete and that delivers a big picture.

This framework asks three types of questions that must be answered for each infrastructure component: what, who, and where. The “what” questions are those most commonly asked and that identify the specific type of technology. The “who” questions seeks to understand what individuals, groups, and departments are involved. In most cases, the individual user is not the owner of the system or even the person who maintains it. In many cases, the systems are leased, not owned, by the company, making the owner a party completely outside the organization. In understanding the infrastructure, it is important to get a picture of the people involved. The third set of questions addresses “where” issues. With the proliferation of networks, many IS are designed and built with components in multiple locations, often even crossing oceans. Learning about infrastructure means understanding where everything is located.

We can expand the use of this framework to also understand architecture. To illustrate the connections between strategy and systems, the table in Figure 6.3 has been populated with questions that typify those asked in addressing architecture and infrastructure issues associated with each component.

The questions shown in Figure 6.3 are only representative of those to be asked; the specific questions managers would ask about their organizations depend on the business strategy the organizations are following. However, this framework can help managers raise appropriate questions as they seek to translate business strategy into architecture and ultimately into infrastructure in their organizations. The answers derived with IT architects and implementers should provide a robust picture of the IT environment. That means that the IT architecture includes plans for the data and information, the technology (the standards to be followed and the infrastructure that provides the foundation), and the applications to be accessed via the company IT system.

Traditionally, there are three common configurations of IT architecture as shown in Figure 6.4. Enterprises liked the idea of a centralized architecture where everything is purchased, supported and managed centrally, usually in a data center, to eliminate the difficulties that come with managing a distributed infrastructure. In addition, since almost every enterprise had a large data center with mainframe at some point, there are a significant number of legacy mainframe environments still in operation today. However, one large computer at the center of the IT architecture is not used as regularly today as it was in the recent past. Instead, many computers are linked together to form a centralized IT core that operates very much like the mainframe, providing the bulk of IT services necessary for the business.

FIGURE 6.3 Infrastructure and architecture analysis framework with sample questions.

A more common configuration is a decentralized architecture. The hardware, software, networking, and data are arranged in a way that distributes the processing and functionality between multiple small computers, servers, and devices and they rely heavily on a network to connect them together. Typically, a decentralized architecture uses numerous servers, often located in different physical locations, at the backbone of the infrastructure, called a server-based architecture.

Although some would debate this point, a third increasingly common configuration is service-oriented architecture (SOA), the architecture that Valero decided to use. An example of a service might be an online employment form that, when completed, generates a file with the data for use in another service. Another example might be a ticket processing service that identifies available concert seats and allocates them. These relatively small chunks of functionality are available for many applications, or reuse. The type of software used in an SOA architecture is often referred to as software-as-a-service or SaaS. Another term for these applications, when delivered over the Internet, is Web services.

FIGURE 6.4 Common architectures.

A manager must be aware of the trade-offs when considering centralized versus decentralized architectural decisions. For example, decentralized architectures are more modular than the centralized architectures, allowing additional servers to be added with relative ease and provide greater flexibility for adding clients with specific functionality for specific users. Decentralized organizational governance, such as that associated with the networked organization structure (discussed in Chapter 3) is consistent with decentralized architectures. In contrast, a centralized architecture is easier to manage in some ways because all functionality is centralized in the main computer instead of distributed throughout all the devices and servers. A centralized architecture tends to be a better match in companies with highly centralized governance, for example, those with hierarchical organization structures. SOA is increasingly popular because the design enables large units of functionality to be built almost entirely from existing software service components. It is useful for building applications quickly because it offers managers a modular and componentized design, and therefore a more easily modifiable, approach to building applications.

An example of an organization making these trade-offs is the Veterans Health Administration (VHA), a part of the Department of Veterans Affairs of the U.S. federal government.³ The organization included 14 different business units that served various administrative and organizational needs. The primary objective of the organization was to provide health care for veterans and their families. In addition, the VHA was a major contributor to medical research, allowing medical students to train at VHA hospitals. The medical centers operated independently and sometimes competed against each other. When the U.S. Congress passed an act that enabled the VHA to restructure itself from a system of hospitals to a single health-care system, the IT architecture was reconfigured from a very centralized design, which enabled the Office of Data Management and Telecommunications to retain control, to a decentralized hospital-based architecture that gave local physicians and administrators the opportunity to deploy applications addressing local needs, while ensuring that standards were developed across the different locations. The VA then introduced the “One-VA” architecture to unify the decentralized systems and “to provide an accessible source of consistent, reliable, accurate, useful, and secure information and knowledge to veterans and their families. . . ” Efforts were made to encrypt, secure, and account for every piece of computer hardware in the system and a national and regional data warehouse initiative was launched to standardize business data storage and management.

Recent technological advances make designs possible such as peer-to-peer and wireless or mobile infrastructures. These designs do not necessarily need to be the firm's exclusive infrastructure. For example, a wireless infrastructure may operate separately or may be built on a mainframe or server-based backbone. Peer-to-peer allows networked computers to share resources without a central server playing a dominant role. ThePirateBay.org, the Web site for sharing music, movies, games, and more, and Skype, a site for teleconferencing, texting, and telephoning, are examples of businesses that use a peer-to-peer architecture. Wireless (mobile) infrastructures allow communication from remote locations using a variety of wireless technologies (e.g., fixed microwave links, wireless LANs, data over cellular networks, wireless WANs, satellite links, digital dispatch networks, one-way and two-way paging networks, diffuse infrared, laser-based communications, keyless car entry, and global positioning systems).

Web-based architectures are architectures in which significant hardware, software, and possibly even data elements reside on the Internet. Web-based architectures offers greater flexibility when used as a source for capacity-on-demand, or the availability of additional processing capability for a fee. IT managers like the concept of capacity on demand to help manage peak processing periods when additional capacity is needed. It allows them to use the Web-available capacity as needed, rather than purchasing additional computers to handle the larger loads.

With the proliferation of smart phones and intelligent computing tablets like the iPad, enterprises are increasingly faced with employees who want to bring their own devices and connect to enterprise systems. Some call this Bring Your Own Device, or BYOD, and it raises some important managerial considerations. When employees connect their own devices to the corporate network, issues such as capacity, security, and compatibility arise. For example, many corporate applications are not designed to function on the small screen of a smart phone. Redesigning it for personal devices may require significant investment to accommodate the smartphone platform. And not all smartphone platforms are the same. Designing for an iPhone is different than for an Android phone. Even if a system were redesigned for these two platforms, the resources required to maintain the system increase since each platform evolves at a different rate and the applications need to appear similar on each device. In some circles, the drive to port applications to personal devices and the ensuing issues to make them work is referred to as the consumerization of IT.

Consumerization of IT is a growing phenomenon. Not only do employees want to use their own devices to access corporate systems, but customers increasingly expect to access company systems from their mobile devices. Making applications robust yet simple enough for customers to use from virtually any mobile device over the Web is a challenge for many information systems departments. Companies such as Good Technology have been created to provide services that allow enterprise employees to connect, communicate, and collaborate using their own devices, supplementing the IT organization's ability to meet this new demand.

FROM STRATEGY TO ARCHITECTURE TO INFRASTRUCTURE: AN EXAMPLE⁴

This section considers a simple example to illustrate the process of converting strategy to architecture to infrastructure. The case discussed is TennisUp, a fictitious maker of tennis rackets.

Define the Strategic Goals

The managers at TennisUp recognize the increasing popularity of tennis; in fact, they can hardly keep up with demand for their rackets. At the same time, however, TennisUp's president, Love Addin, is concerned that tennis mania may end. Addin wants to ensure that TennisUp can respond to sudden changes in demand for rackets. Along with the board of directors, Addin sets TennisUp's strategic goals:

• To lower costs by outsourcing racket manufacturing
• To lower costs by outsourcing racket distribution
• To improve market responsiveness by outsourcing racket manufacturing
• To improve market responsiveness by outsourcing racket distribution

Translate Strategic Goals to Business Requirements

To keep things simple, consider more closely only one of TennisUp's strategic goals: To lower costs by outsourcing racket manufacturing. How can TennisUp's architecture enable this goal? Its goal must be translated into business requirements. The business requirements reflect the following key interfaces to the new manufacturing partners:

• Sales to manufacturing partners: Send forecasts, confirm orders received.
• Manufacturing partner to sales: Send capacity, confirm orders shipped.
• Manufacturing partner to accounting: Confirm orders shipped, electronic invoices, various inventory levels, returns.
• Accounting to manufacturing partner: Transfer funds for orders fulfilled.

Translate Business Requirements into Architecture

To support the business requirements, architectural requirements are specified that dictate the architecture to be established. One major component of the architecture deals with how to obtain, store, and use data to support those business requirements.

The database can be designed to provide the sales data to support sales applications such as sending forecasts and confirming orders received. The database can also be designed to support manufacturing applications that confirm orders shipped, manage inventory, and estimate capacity. The database also needs to be designed to support accounting applications for invoicing, handling returns, and transferring funds.

Translate Architecture to Infrastructure

With the architecture goals in hand, the framework presented in Figure 6.2 outlines how to build the infrastructure. The architecture informs the architect of the functions needed by the infrastructure, and a functional specification is created. Those specs are then translated into hardware, software, data protocols, interface designs, and other components that will make up the infrastructure. For TennisUp's database, the functional specification would include details such as how big it should be, how fast data access should be, what the format of the data will be, and more. These functional specifications then help narrow down the technical specifications, which answer these questions. For example, TennisUp's database needs to accommodate up to 10,000 terabytes as determined by projecting the current database growth for the next five years. The programming language for the database will be SQL, to be compatible with the other applications in the enterprise. Additional technical specifications would be created until the entire infrastructure is designed. Then TennisUp's IT department is ready to pick specific hardware, software, network, data, etc., to put into its infrastructure.

Figure 6.5 lists questions raised when applying the framework to TennisUp's architecture goals and related infrastructure. Note that not all questions apply in a given situation. Figure 6.6 lists possible infrastructure components.

FIGURE 6.5 Framework application to TennisUp.

FIGURE 6.6 TennisUp's infrastructure components.

ARCHITECTURAL PRINCIPLES

Any good architecture is based on a set of principles, or fundamental beliefs about how the architecture should function. Architectural principles must be consistent with both the values of the enterprise as well as with the technology used in the infrastructure. They are designed by considering the key objectives of the organization, and then translated into principles to apply to the design of the IT architecture. The number of principles vary widely, and there is no set list of what must be included in a set of architectural principles. However, a guideline for developing architectural principles is to make sure they are directly related to the operating model of the enterprise and IS organization. Principles should define the desirable behaviors of the IT systems and the role of the organization(s) that support it. A sample of architectural principles is shown in Figure 6.7.

ENTERPRISE ARCHITECTURE

Many companies apply even more complex frameworks than those described earlier for developing an IT architecture and infrastructure, employing an enterprise architecture (EA), or the “blueprint” for all IS and their interrelationships in the firm. Enterprise architecture is the term used for the organizing logic for the entire organization, often specifying how information technologies will support business processes. It differs from an IT architecture in its level of analysis, although it shares some design principles of the lower-level architectures. It identifies the core processes of the company and how they will work together, how the IT systems will support the processes, the standard technical capabilities and activities for all parts of the enterprise, and guidelines for making choices. As experts Jeanne Ross, Peter Weill, and David Robertson describe in their book, Enterprise Architecture as Strategy,

FIGURE 6.7 Sample architectural principles.

Source: Adapted from examples of IT architecture from IBM, TOGAF, the U.S. Government, and the State of Wisconsin.

The components of an enterprise architecture typically include four key elements:

• Core business processes—the key enterprise processes that create the capabilities the company uses to execute its operating model and create market opportunities
• Shared data—the data that drives the core processes
• Linking and automation technologies—the software, hardware, and networking technologies provide the links between applications (applications themselves are part of the IT architecture, but the way applications will link together is part of the bigger picture of the enterprise architecture)
• Customer groups—key customers to be served by the architecture⁶

One example of an enterprise architecture framework is the TOGAF (The Open Group Architecture Framework).⁷ TOGAF includes a methodology and set of resources for developing an enterprise architecture. It is based on the idea of an open architecture, an architecture whose specifications are public (as compared to a proprietary architecture, where specifications are not made public). It is based on the U.S. Department of Defense frameworks and has been developing and continuously evolving since the mid-1990s. It provides a practical, standardized methodology (called Architecture Development Methodology) to successfully implement an enterprise architecture for an organization. The architect implements the enterprise architecture by setting up the foundation architecture, which is composed of services, functions, and standards. Subsets of the enterprise architecture are the business, data, application, and technology architectures. While there is no well-accepted standard for enterprise architecture, architects who understand and use TOGAF speak a common language and use the same basic framework and processes to build their company's IS architecture. TOGAF is designed to translate strategy into architecture and then into a detailed infrastructure; however, it supports a much higher level of architecture that includes more components of the enterprise.⁸

Another example of enterprise architecture frameworks is the Zachman Framework. The Zachman Framework determines architectural requirements by providing a broad view that helps guide the analysis of the detailed view. Its perspectives range from the company's scope to its critical models and, finally, to very detailed representations of the data, programs, networks, security, and so on. The models it uses are the conceptual business model, the logical system model, and the physical technical model.⁹

Because enterprise architecture is more about how the company operates than how the technology is designed, building an enterprise architecture is a joint exercise to be done with business leaders and IT leaders. IT leaders cannot and should not do this alone. Because virtually all business processes today involve some component of IT, the idea of trying to align IT with business processes is outdated. Instead, business processes are designed concurrently with IT systems.

Building an enterprise architecture is more than just linking the business processes to IT. It starts with organizational clarity of vision and strategy and places a high value on consistency in approach as a means of optimal effectiveness. The consistency manifests itself as some level of standardization—standardization of processes, deliverables, and/or people Every enterprise architecture has elements of all these types of standardization; however, the degree and proportion of each vary with the organizational needs, making it dynamic. A good enterprise architect understands this and looks for the right blend for each activity the business undertakes. That means that because organizational groups and individuals are resources for business processes, the organizational design decisions should be part of the enterprise architecture. However, this is a sophisticated capability, and new enterprise architects often seek to put more rigid standards in place and do not attempt to tackle the more complex organizational design issues.

Barclay's Bank¹⁰ servicing more than 48 million customers worldwide, had an IT architecture that included more than 2000 applications and spent in excess of £1 billion annually on IT. The resulting complexity was managed with an enterprise architecture that specified frameworks, tools, and processes that created a common language and format. The EA governance model dictated that both business and technology executives sign off on projects to insure accountability and ownership. Roadmaps helped clarify the enterprise architecture design and direction, which informed planning and portfolio management and created a common vision and a repeatable mechanism for future investments. The EA insured appropriate linkages between IT investment and business needs.

VIRTUALIZATION AND CLOUD COMPUTING

Physical corporate data centers are rapidly being replaced by virtual infrastructure, called virtualization. A virtual infrastructure originally meant one where software replaced hardware in a way that a “virtual machine” or a “virtual desktop system” was accessible to provide computing power. Typically, computing capabilities, storage, and networking are provided by a third party or group of vendors, usually over the Internet or through a private network. In most virtual architectures, the five core components available virtually are servers, storage, backup, network, and disaster recovery. Virtualizing the desktop is a common application of virtualization. In a virtualized desktop, the user's device locally accesses desktop software on a remote server, essentially separating the operating system from the applications. Virtualization is a useful way to design architecture because it enables resources to be shared and allocated as needed by the user, and makes maintenance easier since resources are centralized.

Cloud computing is another term used to describe an architecture based on services provided over the Internet. It is based on the concept of a virtual infrastructure. Entire computing infrastructures are available “in the cloud.”

In addition to software as a service (Saas), PaaS (platform as a service), and IaaS (infrastructure as a service) are typical services found in cloud computing. These are described more fully in Chapter 9. Using the cloud to provide infrastructure means that the cloud is essentially a large cluster of virtual servers or storage devices. Using the cloud for a platform means that the manager will use an environment with the basic software available, such as Web software, applications, database, and collaboration tools. Using the cloud for an entire application generally means that the software is custom designed or custom configured for the business but resides in the cloud.

Consumers of cloud computing purchase capacity on demand and are not generally concerned with the underlying technologies. It's the next step in utility computing or purchasing entire capability on an as-needed basis. Much like the distribution of electricity, the vision of utility computing is that computing infrastructure would be available when needed in as much quantity as needed. When the lights and appliances are turned off in a home, the electricity is not consumed. Ultimately, the customer is billed only for what is used. In utility computing, a company uses a third-party infrastructure to do their processing or transactions and pay only for what they use. And as in the case of the electrical utility, the economies of scale enjoyed by the computing utility enable very attractive financial models for their customers. As the cost of connectivity falls, models of cloud computing emerge.

Salesforce.com, Facebook. Gmail, Windows Azure, Apple iTunes, and LinkedIn are examples of applications in the cloud. Users access LinkedIn through the Web, and build networks of business professionals on the LinkedIn Web site. But LinkedIn provides additional services, such as linking a user's blog to their profile, sharing and storing documents among group's members, access applications like GoodReads to see what network peers are reading and Tripit to learn about their travel plans.

Benefits of virtualization and cloud computing are many. Businesses who embrace a virtual infrastructure can consolidate physical servers, and possibly eliminate them, greatly reducing the physical costs of the data center. There is no upgrade and maintenance cost, no power and electricity cost, no physical space needed and no storage servers needed. Typically, the network is much simpler, too since the virtual infrastructure manages the network within all the applications.

But the biggest benefit of virtualization and cloud computing is the speed at which additional capacity, or provisioning, can be done. In a traditional data center, additional capacity is often a matter of purchasing additional hardware, waiting for its delivery, physically installing it, and insuring its compatibility with the existing systems. It can take weeks. In a virtual infrastructure, the nature of the architecture is dynamic by design, making it relatively easy and quick to add additional capacity.

For example, the New York Times decided to make all public domain articles from 1851 to 1922 available on the Internet. To do that they decided to create PDF files of all the articles from the original papers in their archives. This meant they had to scan each column of the story, create a series of graphic pictures of the scanned image, and then cobble them together to create the single PDF for each story. This was a lot of work and required significant computing power. Once this batch of articles was converted and added to their existing library, the New York Times would have 11 million stories from 1851 to 1989 available free on the Internet.

The manager of this project had an idea to try using the cloud. He selected a service offered by Amazon.com, Amazon EC2, wrote some code to do the project he envisioned, and tested it on the Amazon servers. He used his credit card to charge the $240 it cost him to do this conversion. He calculated it would have taken him at least a month to do the conversion if he used only the few servers available to him in the New York Times network. However, using the Amazon cloud services, he was able to use a virtual server cluster of 100 servers, and it took just under 24 hours to do the entire 11 million articles.¹¹

But managers considering virtualization and cloud computing must also understand the risks. First is the dependence on the third-party supplier. Building applications that work in the cloud may mean retooling existing applications for the cloud's infrastructure. Although there are no standards for virtual infrastructures offered by the various vendors, one dominate vendor, as of the writing of this text, is VMware, a company that offers software for workstations, virtual desktop infrastructures, and servers. No standards for virtual infrastructure, however, means that applications running on one vendor's infrastructure may not port easily to another vendor's environment.

Architectures are increasingly including cloud computing and virtualization as alternatives to the in-house infrastructures. As coordination costs drop, and platforms in the cloud open up, cloud computing utilization will increase.

OTHER MANAGERIAL CONSIDERATIONS

The framework guides the manager toward the design and implementation of an appropriate infrastructure. Defining an IT architecture that fulfills an organization's needs today is relatively simple; the problem is, by the time it is installed, those needs change. The primary reason to base an architecture on an organization's strategic goals is to allow for inevitable future changes—changes in the business environment, organization, IT requirements, and technology itself. Considering future impacts should include an analysis of the existing architecture, the strategic time frame, technological advances, and financial constraints.

Understanding Existing Architecture

At the beginning of any project, the first step is to assess the current situation. Understanding existing IT architecture allows the manager to evaluate the IT requirements of an evolving business strategy against current IT capacity. The architecture, rather than the infrastructure, is the basis for this evaluation because the specific technologies used to build the infrastructure are chosen based on the overall plan, or architecture. As previously discussed, it is these architectural plans that support the business strategy. Assuming some overlap is found, the manager can then evaluate the associated infrastructure and the degree to which it can be utilized going forward.

Relevant questions for managers to ask include the following:

• What IT architecture is already in place?
• Is the company developing the IT architecture from scratch?
• Is the company replacing an existing architecture?
• Does the company need to work within the confines of an existing architecture?
• Is the company expanding an existing architecture?

Starting from scratch allows the most flexibility in determining how architecture will enable a new business strategy, and a clean architectural slate generally translates into a clean infrastructure slate. However, it can be a challenge to plan effectively even when starting from scratch. For example, in a resource-starved start-up environment, it is far too easy to let effective IT planning fall by the wayside. Sometimes, the problem is less a shortcoming in IT management and more one of poorly devised business strategy. A strong business strategy is a prerequisite for IT architecture design, which is in turn a prerequisite for infrastructure design.

Of course, managers seldom enjoy the relative luxury of starting with a clean IT slate. More often, they must deal in some way with an existing architecture, infrastructure, and legacy systems already in place. In this case, they encounter both opportunity—to leverage the existing architecture and infrastructure and their attendant human resource experience pool—and the challenge of overcoming or working within the old system's shortcomings. By implementing the following steps, managers can derive the most value and suffer the least pain when working with legacy architectures and infrastructures.

1. Objectively analyze the existing architecture and infrastructure. Remember, architecture and infrastructure are separate entities; managers must assess the capability, capacity, reliability, and expandability of each.
2. Objectively analyze the strategy served by the existing architecture. What were the strategic goals it was designed to attain? To what extent do those goals align with current strategic goals?
3. Objectively analyze the ability of the existing architecture and infrastructure to further the current strategic goals. In what areas is alignment present? What parts of the existing architecture or infrastructure must be modified? Replaced?

Whether managers are facing a fresh start or an existing architecture, they must ensure that the architecture will satisfy their strategic requirements, and that the associated infrastructure is modern and efficient. The following sections describe evaluation criteria including strategic time frame, technical issues (adaptability, scalability, standardization, maintainability, security), and financial issues.

Assessing Strategic Timeframe

Understanding the life span of an IT infrastructure and architecture is critical. How far into the future does the strategy extend? How long can the architecture and its associated infrastructure fulfill strategic goals? What issues could arise and change these assumptions?

Answers to these questions vary widely from industry to industry. Strategic time frames depend on industry-wide factors such as level of commitment to fixed resources, maturity of the industry, cyclicality, and barriers to entry. The competitive environment has increased the pace of change to the point that requires any strategic decision be viewed as temporary.

Architectural longevity depends not only on the strategic planning horizon, but also on the nature of a manager's reliance on IT and on the specific rate of advances affecting the information technologies on which he or she depends. Today's architectures must be designed with maximum flexibility and scalability to ensure they can handle the imminent business changes. Imagine the planning horizon for a dot-com company in an industry in which Internet technologies and applications are changing daily, if not more often. Even oil giant Valero found that flexibility and agility were critical to their business and hence to their IT architecture.

Assessing Technical Issues: Adaptability

With the rapid pace of business, it is no longer possible to build a static information system to support businesses. Instead, adaptability is a core design principle of every IT architecture, and one reason why cloud computing and virtualization are increasingly popular. A manager may think of technological advances as primarily affecting IT infrastructure, but the architecture must be able to support any such advance. Can the architecture adapt to emerging technologies? Can a manager delay the implementation of certain components until he or she can evaluate the potential of new technologies?

At a minimum, the architecture should be able to handle expected technological advances, such as innovations in storage capacity and computing power. An exceptional architecture also has the capacity to absorb unexpected technological leaps. Both hardware and software should be considered when promoting adaptability. For example, new Web-based applications emerge daily that may benefit the corporation. The architecture must be able to integrate these new technologies without violating the architecture principles or significantly disrupting business operations.

The following are guidelines for planning adaptable IT architecture and infrastructure. At this point, these two terms are used together, because in most IT planning they are discussed together. These guidelines are derived from work by Meta Group.¹²

• Plan for applications and systems that are independent and loosely coupled rather than monolithic. This approach allows managers to modify or replace only those applications affected by a change in the state of technology.
• Set clear boundaries between infrastructure components. If one component changes, others are minimally affected, or if effects are unavoidable, the impact is easily identifiable and quantifiable.
• When designing a network architecture, provide access to all users when it makes sense to do so (i.e., when security concerns allow it). A robust and consistent network architecture simplifies training and knowledge sharing and provides some resource redundancy. An example is an architecture that allows employees to use a different server or printer if their local one goes down.

Note that requirements concerning reliability may mitigate the need for technological adaptability under certain circumstances. If the architecture requires high reliability, a manager seldom is tempted by bleeding-edge technologies. The competitive advantage offered by bleeding-edge technologies is often eroded by downtime and problems resulting from pioneering efforts with the technology.

Assessing Technical Issues: Scalability

A large number of other technical issues should also be considered when selecting an architecture or infrastructure. A frequently used criterion is scalability. To be scalable refers to how well an infrastructure component can adapt to increased, or in some cases decreased, demands. A scalable network system, for instance, could start with just a few nodes but could easily be expanded to include thousands of nodes. Scalability is an important technical feature because it means that an investment can be made in an infrastructure or architecture with confidence that the firm will not outgrow it.

What is the company's projected growth? What must the architecture do to support it? How will it respond if the company greatly exceeds its growth goals? What if the projected growth never materializes? These questions help define scalability needs.

Consider a case in which capacity requirements were poorly anticipated. In early 2007, an ice storm on the East Coast of the United States forced JetBlue Airlines to scramble to take care of stranded customers, grounded planes, checked luggage, and cancelled flights. In the aftermath, executives told investors that the computers didn't fail. Indeed, they did not fail, but the system failed to scale as needed. The system was set up to accommodate 650 agents and was able to be increased to 950, but no more.¹³ It's unlikely that JetBlue, or its software provider, would have had to do any serious systems redesign to respond to the increase in demand; it simply needed to increase its infrastructure capacity. Ultimately, this planning failure cost JetBlue millions to recover from the failure and even more in defending its image, which suffered severe negative word of mouth from the poor service that resulted. It subsequently contracted with Verizon to manage its infrastructure as a way of responding to the scalability issue. JetBlue's plight underscores the importance of analyzing the impact of strategic business decisions on IT architecture and infrastructure and at least ensuring a contingency plan exists for potential unexpected effects of a strategy change.

Assessing Technical Issues: Standardization

Another important feature deals with commonly used standards. Hardware and software that uses a common standard, as opposed to a proprietary approach, are easier to plug into an existing or future infrastructure or architecture because interfaces often accompany the standard. For example, many companies use Microsoft Office software, making it an almost de facto standard. Therefore, a number of additional packages come with translators to the systems in the Office suite to make it easy to move data between systems.

Assessing Technical Issues: Maintainability

How easy is the infrastructure to maintain? Are replacement parts available? Is service available? Maintainability is a key technical consideration because the complexity of these systems increases the number of things that can go wrong, need fixing, or simply need replacing. In addition to availability of parts and service people, maintenance considerations include issues such as the length of time the system might be out of commission for maintenance, how expensive and how local the parts are, and obsolescence. Should a technology become obsolete, costs skyrocket for parts and expertise.

Assessing Technical Issues: Security

Security is a major concern for business managers and IT managers alike. Businesses feel vulnerable to attack. IT managers worry about protecting key data and process elements of the IT infrastructure. Security is a concern that extends outside the corporate boundaries; for example, customers wonder how safe their credit card numbers are when typed into a vendor's order form. Technologies have come a long way to provide security. Innovations encrypt or otherwise disguise sensitive information, financial information, and business information.

Architectures have different inherent security profiles. Securing assets in a highly centralized, mainframe architecture means building protection around the centralized core. Because data and software are stored and executed on the mainframe computer, methods of protecting these assets revolve around protecting the mainframe itself. Decentralized, server-based architecture are more difficult to secure due to the dispersion of servers. Security is a matter of protecting every server instead of one centralized system. A Web-based SOA architecture that utilizes SaaS and capacity on demand raises a whole new set of security issues. The data and applications not only reside on servers in the various vendor systems around the Web, but also the linking mechanism, the network that ties the Web together, introduces another level of security concerns.

What if, for example, someone was to steal a file of credit card numbers as they were relayed over the Internet? The risk of the interception of e-commerce data may be no greater than the risks of paper transactions: credit card receipts (and credit cards themselves) are stolen and the numbers used fraudulently. Checkbooks are stolen and signatures are fraudulently forged. Transactions with a paper trail are hardly foolproof and may indeed be riskier than e-commerce transactions. The difference is in the speed of the communication. A file with secure information can be sent anywhere in the world in a matter of seconds over the Internet, whereas the paper-based file takes longer to reach a destination. The good news is that the security of networks continues to improve. Innovations such as authentication, passwords, digital signatures, encryption, secure servers, and firewalls are already in place, and new schemes for security, such as securing specific assets instead of just securing the perimeter of a system, are being explored.

Managing security is often a matter of managing risk. It is virtually impossible to be totally secured regardless of the security model employed. Hackers and thieves will find a way around just about any security system. Therefore, managing risk often means assessing the likelihood of a breach and the cost of that breach in terms of loss and recovery. For example, one forward-thinking executive suggested that instead of trying to protect all his employees' Social Security numbers from theft, he preferred to purchase insurance to cover any losses that might result from the identity theft. He chose a service, LifeLock, that closely monitors its customers' identity, proactively takes steps to minimize identity theft, and offers a $1 million service guarantee to cover any losses that do occur.

Assessing Financial Issues

Like any business investment, IT infrastructure components should be evaluated based on their expected financial value. Unfortunately, payback from IT investments is often difficult to quantify; it can come in the form of increased productivity, increased interoperability with business partners, improved service for customers, or yet more abstract improvements. This suggests focusing on how IT investments enable business objectives rather than on their quantitative returns.

Still, some effort can and should be made to quantify the return on infrastructure investments. This effort can be simplified if a manager works through the following steps with the IT staff.

1. Quantify costs. The easy part is costing out the proposed infrastructure components and estimating the total investment necessary. Don't forget to include installation and training costs in the total.
2. Determine the anticipated life cycles of system components. Experienced IT staff or consultants can help establish life cycle trends both for a company and an industry to estimate the useful life of various systems.
3. Quantify benefits. The hard part is getting input from all affected user groups, as well as the IT group—which presumably knows most about the equipment's capabilities. If possible, form a team with representatives from each of these groups and work together to identify all potential areas in which the new IT system may bring value.
4. Quantify risks. Work with the IT staff to identify cost trends in the equipment the company proposes to acquire. Also, assess any risk that might be attributable to delaying acquisition, as opposed to paying more to get the latest technology now.
5. Consider ongoing dollar costs and benefits. Examine how the new equipment affects maintenance and upgrade costs associated with the current infrastructure.

Once this analysis is complete, the manager can calculate the company's preferred discounted cash flow (i.e., net present value or internal rate of return computation) and the payback period. Approaches to evaluating IT investments are discussed in greater detail in Chapter 7.

Applying these considerations to the fictitious TennisUp company, The last task is to weigh the managerial considerations against the same architectural goals outlined above. Figure 6.8 shows how these considerations apply to TennisUp's situation.

Again, note that not every issue in the evaluation criteria was addressed for TennisUp, but this example shows a broad sampling of the kinds of issues that will arise.

FIGURE 6.8 TennisUp's managerial considerations.

SUMMARY

• Strategy drives architecture, which drives infrastructure. Strategic business goals dictate IT architecture requirements. These requirements provide an extensible blueprint suggesting which infrastructure components will best facilitate the realization of the strategic goals.
• Enterprise architecture is the broad design that includes both the information systems architecture and the interrelationships in the enterprise. Often this plan specifies the logic for the entire organization. It identifies core processes, how they work together, how IT systems will support them, and the capabilities necessary to create, execute, and manage them.
• Three configurations for IT architecture are centralized, decentralized, and SOA (or Web-based) architectures. Applications are increasingly being offered as a service, reducing the cost and maintenance requirements for clients. Virtualization and cloud computing provide architectures for Web-based delivery of services.
• The manager's role is to understand how to plan IT to realize business goals. With this knowledge, he or she can facilitate the process of translating business goals to IT architecture and then modify the selection of infrastructure components as necessary.
• Frameworks guide the translation from business strategy to IS design. This translation can be simplified by categorizing components into broad classes (hardware, software, network, data), which make up both IT architecture and infrastructure.
• Enterprise leaders are increasingly faced with new devices that employees want to connect to the corporate network. The consumerization of IT describes the trend to redesign corporate systems for smart phone, tablets and other consumer-oriented devices.
• While translating strategy into architecture and then infrastructure, it is important to know the state of any existing architecture and infrastructure, to weigh current against future architectural requirements, and strategic time frame, and to analyze the financial consequences of the various systems options under consideration. Systems performance should be monitored on an ongoing basis.

KEY TERMS

architecture (p. 169)

bring-your-own-device (BYOD) (p. 177)

capacity-on-demand (p. 177)

centralized architecture (p. 173)

cloud computing (p. 183)

consumerization of IT (p. 177)

data center (p. 173)

decentralized architecture (p. 174)

enterprise architecture (p. 180)

infrastructure (p. 169)

peer-to-peer (p. 176)

platform (p. 172)

reuse (p. 174)

scalable (p. 188)

server-based architecture (p. 174)

service-oriented architecture (SOA) (p. 174)

software-as-a-service (p. 175)

standards (p. 188)

system software (p. 172)

TOGAF (p. 182)

utility computing (p. 184)

virtualization (p. 183)

Web-based architectures (p. 176)

Web services (p. 175)

wireless (mobile) infrastructures (p. 176)

Zachman Framework (p. 182)

DISCUSSION QUESTIONS

1. Think about a company you know well. What would be an example of IT architecture at that company? An example of the IT infrastructure?
2. What, in your opinion, is the difference between a decentralized architecture and a centralized architecture? What is an example of a business decision that would be affected by the choice of the architecture?
3. From your personal experience, what is an example of software as a service? Of BYOD?
4. Saab Cars USA, with its network of 212 dealerships and 30 service centers, dedicated itself to providing its customers a level of service reflective of the high quality of its cars. To improve productivity and reduce costs, Saab wanted to facilitate dealer access to corporate information and applications through the Internet using Web browsers. Saab knew it needed to leverage both its legacy hardware and code to make it a cost-effective e-business initiative. It outsourced to IBM Global Services to build its Intranet Retailer Information System (IRIS). IRIS is written in Java, using IBM DB2 Universal Database running on Saab's existing IBM AS/400 server. Lotus Domino is the middleware that leverages the existing infrastructure. Using a standard Web browser, any authorized employee at a Saab dealership or service center in the United States has access to enterprise applications stored on the AS/400 server at the Saab U.S. headquarters. The applications make use of a consolidated repository of vehicle, customer, warranty, sales, and service information stored in DB2 Universal Database. Says Director of IS, Jerry Rode, “DB2 Universal Database has demonstrated incredible scalability and reliability as the data management solution for our IRIS system.” Lotus Domino, residing in another logical partition on the AS/400 server, is the middleware that mediates between the back-end applications and the front-end Web interface. For example, if a customer walks in and asks for a black model 9-3 Saab with a tan leather interior; a sales associate logs into the IRIS menu created by Domino and initiates a search. Domino queries DB2 by location, model, and color and puts the results of the query into an HTML form for the dealer. Upon locating the customer's vehicle, that dealer clicks to another vehicle distribution application and orders the car to be brought on site.¹⁴
   1. Use this case to describe how Saab went from vision to infrastructure.
   2. What criteria did Saab use in selecting its infrastructure?

CASE STUDY 6-1
ENTERPRISE ARCHITECTURE AT AMERICAN EXPRESS

Enterprise architecture (EA) at American Express was the framework the organization used to align IT and the business. It provided a common language for leaders to use to collaborate and transform the business. At American Express, enterprise architects were the change agents who streamlined processes and designed ways to more effectively do business using IT resources. In 2011, American Express was named an InfoWorld/Forrester Enterprise Architecture Award recipient for its EA practices. As American Express leaders considered new payment methods using mobile devices, the EA guided their progress.

Mobile payments were forcing the payments industry to review their practices and significantly transform the way business was done. The new business environment introduced additional complexity with the addition of new delivery channels and the need for shorter time-to-market of payment products and services. American Express's business strategy for its payments products focused on delivering a “consistent, global, integrated customer experience based on services running on a common application platform.”

To achieve this goal, the EA team created reference architectures and road maps for standardized applications across the firm. They then worked with multiple business solution delivery teams to create and manage the common application architecture and create strategies that facilitated each business's objectives. Each strategy included a road map of initiatives. Initiatives included a set of actions, the metrics to evaluate the success of these actions, and the commitments IT and the businesses made to make it happen. The road map was American Express's way to standardize language, tools, lifecycle management of the applications, architecture and governance processes. They included technology, reference architecture and capabilities for the business.

The next steps for American Express were to extend the road maps to cover the maturing of SOA and to develop new reference architectures and a new taxonomy to increasingly align IT with the needs of the business. As new technologies emerged and new ways of doing business over social tools created opportunities for new payment products and services, American Express expected to continually evolve their EA.

Discussion Questions

1. What are the key components of the architecture American Express has created?
2. Why was it important to standardize so much of the architecture? What are the advantages and disadvantages of a standard EA for American Express?
3. Describe how the new architecture supports the goals and strategy of American Express.
4. What types of future payment products and services should be anticipated and prepared for by the EA group? What is your vision of how payments might work? If you were advising the CIO of American Express, what would you suggest his group prepare for?

Source: Adapted from Phil LeClare and Eric Knorr, “The 2011 Enterprise Architecture Awards” (September 19, 2011), http://www.infoworld.com/d/enterprise-architecture/the-2011-enterprise-architecture-awards-173372.

CASE STUDY 6-2
THE CASE OF EXTREME SCIENTISTS

Scientists doing research often need serious computing capability to run simulations and crunch data. Often that meant working for a large company who could provide the significant investment in information systems infrastructure. But cloud computing changed all that. Consider the case of biologist Dr. Eric Schadt, a researcher who claims that approaches to studying the complexity of living systems have failed. Studying one gene at a time doesn't explain what causes diseases, making it impossible to find the cures sought by the scientific and pharmacology communities. Dr. Schadt's vision is to manage this area of research, and the large amount of data generated, which appears to be too much for any one individual or company to manage, by creating a human social network. Dr. Schadt believes this organization reflects the complexity of the living systems he studies, and therefore it's necessary to understand it.

Dr. Schadt cofounded a nonprofit organization dedicated to biological research using an open-source sharing of data, called Sage Bionetworks. He deeply believes that sharing is the key to finding cures, and creating drugs, that will combat diseases. And his company has millions of dollars worth of data from some of the major pharmaceutical companies to use to begin their research. But by day, he's the Chief Scientific Officer of a start up, Pacific Biosciences, whose technology helps biologists look at individual molecules of DNA in real-time. His job is to work on how to use this technology for PacBio and to collaborate with others who want to use this technology for their research. So he travels a lot. But to do his research, he needs access to the capacity of a supercomputer since the amount of data he needs to use for his research is very large.

With the use of the Web, he's able to do his work anyplace. Planes are especially favored because he has significant uninterrupted time. According to one article about Dr. Schadt,

Dr. Schadt is able to initiate a complex analysis of his data using Amazon's services, which crunch the data while Dr. Schadt flies across the country. When he lands, the analysis is done and he has the results. This world be equivalent to the computing power of a scientist working on his company's multimillion dollar supercomputer, but in this case, the cost is just a few hundred dollars.

Companies like Amazon.com have become vendors of extreme computing power. Some have compared the amount of computing power Dr. Schadt uses while flying on an airplane to the amount of computing power available to a scientist at major pharmaceutical companies, where they have multimillion dollar supercomputers. With services like the computing power available in the cloud, Dr. Schadt may even have more power available to him than the scientist.

Discussion Questions

1. How would you describe the architecture Dr. Schadt uses to do his research?
2. What are the risks Dr. Schadt faces by using Amazon for his supercomputing? What are the benefits?
3. If you were advising a company trying to make a decision about using cloud computing for key business applications, what would you advise and why?

Source: Adapted from Tom Junod, “Adventures in Extreme Science,” Esquire Magazine (March 22, 2011), http://www.esquire.com/features/eric-schadt-profile-0411-4 (accessed on February 12, 2012).