Manz Mueller Stoeck FacebookALM Finalv2

8/4/2019 Manz Mueller Stoeck FacebookALM Finalv2

http://slidepdf.com/reader/full/manz-mueller-stoeck-facebookalm-finalv2 1/18

Technische Universität München

Fakultät für Informatik

Lehrstuhl für Wirtschaftsinformatik (I 17)

Prof. Dr. Helmut Krcmar

Seminararbeit

im Rahmen der Veranstaltung

Challenges for the CIOin Wirtschaftsinformatik

THEMA

Aufgabensteller: Prof. Dr. Helmut KrcmarBetreuer: Wolfgang Palka

Bearbeiter: Manz, VolkerMüller, Max

Stoeck, Jakob



List of Figures 1

Table of Contents

List of Figures ................................................................................................................................ 2 1 Introduction............................................................................................................................ 3 2 History and Basics of Application Lifecycle Management ................................................ 4

2.1 The Roots of Application Lifecycle Management ........................................................... 4 2.2 A definition of Application Lifecycle Management ........................................................ 5 2.3 A framework of core Application Lifecycle Management concepts ............................... 6 2.4 An exemplary overview of Application Lifecycle Management Tools ........................... 6

3 ALM 2.0 .................................................................................................................................. 7 3.1 Motivation for Application Lifecycle Management 2.0 ................................................... 7 3.2 Brief Comparison ALM and ALM2.0 .............................................................................. 7 3.3 Vendors and Tools............................................................................................................ 9 3.4 Extension: ALM 2.0+ ....................................................................................................... 9

4 ALM at Facebook ................................................................................................................ 10 4.1 What 20 minutes on Facebook look like ........................................................................ 10 4.2 How ALM components look like at Facebook .............................................................. 10

4.2.1 Service Creation ...................................................................................................... 10 4.2.2 Service Management ............................................................................................... 11

4.3 ALM Benefits ................................................................................................................. 12 5 Conclusion ............................................................................................................................ 14 6 Bibliography ......................................................................................................................... 15 7 Bearbeitungsaufteilung ....................................................................................................... 17



List of Figures 2

List of Figures

Figure 1 : Product lifecycle management process steps (adapted from Georgalas, 2009) ............. 4 igue 2 ew iie 2011) ................................................................................ 6 Figure 3 Favourite Methodologies (Dave West with Jeffrey S. Hammond, 2010) ........................ 7 Figure 4: ALM 1.0 (Schwaber, 2006) ............................................................................................. 8 Figure 5: ALM2.0 (Schwaber, 2006) .............................................................................................. 9



Introduction 3

1 Introduction

Founded as a social utility in 2004, Facebook wants to help people connect and communicate

e efficietly with peple ud the. The cpy‟s develpe te is t build techl -

ogies that facilitate the sharing of information through the social graph, the digital mirror of peo-

ple's real-world social connections. Facebook, the product, is made up of core site functions andapplications. While core site functions and core applications are always developed internally, the

company relies on a strong community of external developers who build third-party applications

for Facebook. Facebook is one of the highest-volume sites in the world and its infrastructure has

to support this rapid growth. The company is the largest user in the world of memcached, an

open source caching system, and has one of the largest MySQL database clusters anywhere. The

site is largely written in PHP though the engineering team developed a way to programmatically

transform PHP source code into C++ to gain performance benefits. Lately Facebook started de-

veloping and marketing its platform ambitions. This platform should enable third-party compa-

nies and external developers to deeply integrate with the Facebook website (this paragraph wasadapted from Facebook Company Information).

However, Facebook is facing a big challenge, which is a result of the fast-paced internal devel-

opment and its ambitions to become the identity standard on the web. Over the years Facebook

developers established an aggressively agile and rapid application and product development pro-

cess. These fast and unbureaucratic processes ensure that Facebook can keep pace with the re-

quirements of its ever growing user-base, however it makes it quite difficult for third-party de-

velopers to keep track of all changes, to collaborate with Facebook and finally build new appli-

cation based on its social graph.

In this paper we demonstrate how Application Lifecycle Management 2.0 can support the Face-book Product Team in streamlining their application development. Thereby Facebook can lever-

age efficiency gains throughout its product lifecycle and ensure that third parties can easier build

pducts bsed ceb‟s stdds, becuse f bette tceability of changes of its dynam-

ic platform.



History and Basics of Application Lifecycle Management 4

2 History and Basics of Application Lifecycle Management

This chapter sets out the theoretical foundations to the paper at hand. The chapter is divided into

sections discussing the roots of Application Lifecycle Management (ALM), a contemporary de-

finition of ALM as well as framework of its core concepts. At the end of this chapter, this paper

will provide an overview of some exemplary ALM suites and tools.

2.1 The Roots of Application Lifecycle Management

pplicti ifecycle geet stes f Pduct ifecycle geet P). P is

the activity of managing a product throughout its lifecycle – f cdle t gve“ St, 2005).

PLM itself originally developed out of the need streamline initially separate and scrappy activi-

ties, systems and processes to overcome problems of information loss, misinterpretation of cus-

te euieets ucdited decisi ig with pduct geet tes

iie, 2011).

Recently scholars describe PLM as a centralized attempt to manage all artifacts and other prod-uct-related data throughout all required process steps. PLM empowers product stakeholders to

monitor and steer the entire process of product creation, product handling, distribution of the

product, and recording product-related data after the release (Sääksvuori and Immonen, 2004).

As Figure 1 shows, PLM comprises all steps in the live of a product from initial concept to re-

tirement (Georgalas, 2009).

Figure 1 : Product lifecycle management process steps (adapted from Georgalas, 2009)

However, PLM initially focused on the management of mechanical, electrical and electronic

products. Researchers like Abramovici (2007) predict that futue P fews d tls will

ffe ipved suppt f the geet f ulti-discipliy pducts f the fields,

such s sftwe web pplictis iie, 2011).

As the development, launch, operations and maintenance of software and web applications re-quires close collaboration between different disciplines and specialists, those industries highly

require custom-made solutions for managing their products. For example, product managers,

architects, developers, project managers and testers produce different kinds of information dur-

ing product development.

Regularly, the development of multidisciplinary products is supported with various development

and product information management systems and tools. Those reach from Requirements Man-

ageet tls ve figuti geet tls d evelpet tls t Testig tls,

d Test t dtbses iie, 2011). All these systems have in common that they are

primarily targeted to only one special phase of the product lifecycle. Therefe the li‟s she f these artifacts from these systems is not interconnected, but rather kept in single data silos.




Furthermore product abstractions of certain elements of the product come in a variety of data

forms and on different levels of abstraction. It could be visual design files from the design de-

partment, project management data from the product manager or testing and analysis data from

the marketing team. Practically, it is impossible to reflect the entire product management process

on merely a single type of representation. Products and the associated process steps are too com- plex i thei tue. Tht is the es why schls fte descibe the eed f ultiple levels f

bstcti i lifecycle geet iie, 2009).

To improve product management efficiency researchers like Schwaber (2006) suggest that prod-

uct information management databases should be interlinked in in order to better assist, for ex-

ample, reporting of lifecycle artifacts like the implementation of certain desig specifictis

iie, 2011).

Keeping artifacts and product management-related data consistent across a number of product

information management systems would demand for extensive integrations of the systems at

hand. Because of the tremendous mass of product information copying data and dealing withduplicates is not a valid option. Therefore researchers suggest that it is reasonable to use item

identifiers for each single artifact and product information piece. By doing so all product data

could evetully bece tceble. This tcebility epwes pduct stehldes t etieve

up-t-dte ifti f the iitil dt suce dtbse. This iiizes the is f ig

decisis bsed utdted dt iie, 2009).

ALM frameworks and tools are an attempt to grant that traceability. However, ALM aims to be

more. Together with process automation as well as reporting and analytics, traceability forms

one of the three main pillars of ALM (Schwaber, 2006)

Just as PLM, ALM comprises the management of processes, from idea creation to implementa-

tion and back. ALM as a whole can be responsible for storing, versioning, and tracking relation-

ships between all product life-cycle assets. These may include information on multiple levels of

abstraction such as requirements, models, source code, test plans, test scripts, and build files. It is

also part of ALM to manage, monitor and report the processes by which these artifacts are

changed (Schwaber, 2006).

2.2 A definition of Application Lifecycle Management

Finding a comprehensive definition of ALM is a challenging task. Scholars as well as practition-

ers have substantially different views about the matter. According to Chappell (2008) superficialdefinitions merely put ALM and the traditional software development lifecycle on a par. Yet on

closer examination it becomes obvious that ALM comprises much more than just that. Chappell

2008) futhe sttes tht pplicti‟s lifecycle icludes the etie tie duig which

organization is spending ey this sset, f the iitil ide t the ed f the pplicti‟s

life.“

Schwbe 2006) defies s “the cditi f develpet life-cycle activities, includ-

ing requirements, modeling, development, build, and testing, through enforcement of processes

that span these activities, management of relationships between development artifacts used or

pduced by these ctivities; d eptig pgess f the develpet efft s whle.”




Generally it is accepted that the concept of ALM was estblished t idicte the cditi f

ctivities d the geet f tifcts duig the sftwe pduct‟s lifecycle d thughut

its petis iie, 2011).

2.3

A framework of core Application Lifecycle Management conceptsUntil today only sll ube f fews hve bee develped. e f the st

piet es is iie‟s, which initial version is from 2009. It was revised several times

over the years. The latest version is from 2011 and consists out of six principal elements that

characterize ALM. The four basic ALM layers in the middle of Figure 2 form the hierarchical

levels f the eleets with the uppe “cuicti” lye usig tifcts pvided by

the lwe level lyes. The eleets the side, ely “pcess suppt” d “tl itegti”

hve t pvide efficiet wig d geet eviet by euippig the hiechicl

lyes peseted i the iddle t suppt vell lifecycle pcess d tl itegti

iie 2011).

Figure 2 2011)

2.4 An exemplary overview of Application Lifecycle Management Tools

Most ALM vendors that offer ALM solutions nowadays offer entire ALM suites. Those consist

of a large set of tools, which besides others comprise requirement management, architecture,

coding, testing, tracking and release management. Most ALM suites are marketed as the unified

approach to the entire life cycle. Such a suite should give all stakeholders involved in the appli-

cation lifecycle, such as coders, analysts or testers, the chance to constantly be fully aware of the

current status of the application (Kim and Choi 2010). Sample ALM suites comprise Borland

StarTeam Enterprise Advantage, IBM Rational ClearCase Change Management Solution, Micro-

soft Visual Studio Team Foundation Server, and Telelogic SYNERGY (Schwaber 2005).



ALM 2.0 7

3 ALM 2.0

3.1 Motivation for Application Lifecycle Management 2.0

The concepts of traditional ALM are designed for fully planned, structured and rather static ar-

chitectures and software platforms. Requirements, Development, Buidling, Testing, Deplymentand Operation also make sense in modern, rapidly developed and fast evolving applications. The

fast growing market and number of web applications has a steadily increasing developer com-

munity and highly discontinuously customers. Especially one factor is giving companies the

competitive advantage: Speed.

Shorter product and feature cycles can be the crucial edge on the market, winning new customers

and expanding networks. Rapid Prototyping and Agile software development are two examples

showing the current trend of application development methods. This chapter shows the new con-

cepts and trends in ALM 2.0. (Rossberg, 2008)

Figure 3 Favourite Methodologies (Dave West with Jeffrey S. Hammond, 2010)

Furthermore West and Hammond (2010) analyzed recent studies by the favourite methodologiesof software development in companies according to the worldwide Global Technographics Sur-

vey they rely on. Figure 3 shows that more than 1/3rd

of all respondents use Agile development

methods where in contrast traditional iterative and waterfall procedures make another third, ten-

dency descending (Dave West 2011).

That fact shows how important apropriate lifecycle management tools for the next generation

software methodologies have become and that markets are still growing.

3.2 Brief Comparison ALM and ALM2.0

Figure 4 shows the traditional ALM suites with 5 separated core processes. Software develop-ment processes like the waterfall model or v-model contain similar steps or methodologies with

http://dict.leo.org/ende?lp=ende&p=Ci4HO3kMAA&search=discontinuously&trestr=0x801

http://dict.leo.org/ende?lp=ende&p=Ci4HO3kMAA&search=competitive&trestr=0x1001

http://dict.leo.org/ende?lp=ende&p=Ci4HO3kMAA&search=edge&trestr=0x1001

http://dict.leo.org/ende?lp=ende&p=Ci4HO3kMAA&search=crucial&trestr=0x8004

http://dict.leo.org/ende?lp=ende&p=Ci4HO3kMAA&search=crucial&trestr=0x8004

http://dict.leo.org/ende?lp=ende&p=Ci4HO3kMAA&search=edge&trestr=0x1001

http://dict.leo.org/ende?lp=ende&p=Ci4HO3kMAA&search=competitive&trestr=0x1001

http://dict.leo.org/ende?lp=ende&p=Ci4HO3kMAA&search=discontinuously&trestr=0x801



ALM 2.0 8

separate repositories for different stages in the life of a software application. Consequently, re-

dundancies and inconsistencies are not avoidable and transparency suffers from this layout.

Figure 4: ALM 1.0 (Schwaber, 2006)

In addition to that are often problems integrating and connecting tools which are specialized on

single tasks so that they can collaborate accurately.

ALM 2.0 promises to increase flexibility and efficiency with it high degree of integration and the

use of open software and standards. Particularly companies like Facebook have a indirectly con-

tributed to the development of the new standard by publishing its requirements and practices.

Figure 5 depicts a highly integrated and more connected solution for modern ALM platforms.Several repositories can be included and processes are more cohesive. Moreover new characte-

ristics are (Schwaber, 2006):

plug-in support of tools

Common Services

Flexibility on Repositories

Open standards

Externalized Workflow

As a result the customer has faster access on needed features and increased performance on dep-

loyments. The integration of external tools is immensely facilitated and processes can now sharecommon components to avoid duplicates.



ALM 2.0 9

Figure 5: ALM2.0 (Schwaber, 2006)

3.3 Vendors and Tools

Currently vendors are in the process of adopting existing ALM tools to the concepts of ALM 2.0.

Many vendors are still now in the evolution process but there are definitely approaches and plans

(Schwaber, et al., 2008): Borland Management Solutions, puwe‟s ptil elivey n-

ager, HP Quality Center, IBM Jazz or Microsoft Visual Studio Team System never really made it

t the defiite stte f „ 2.0 edy‟. Instead, customers discovered the possibilities of ERP

systems providing process-rich, integrated solutions to support certain business processes used

for ALM. (Dave West with Jeffrey S. Hammond, 2010)

The main problematic in switching to one fully integrated solution is to merge existing reposito-

ries. In addition to that one of the main challenges is still to cover all combinations of used plat-

forms, programming environments, and runtimes, not to mention the costs.

3.4 Extension: ALM 2.0+

Taking a closer look at particular features of agile development reveals teamwork and collabora-

tion as the most important and updated roles which are part of agile development methods and

can be characterized as follows: (Dave West with Jeffrey S. Hammond, 2010)

Capture task-based work

Improve inspection frequency with iterative development

Harvest build and integration information from continuous integration

Test-driven development and enforce test artifacts Support frequent planning and reporting

As a result work planning and collaboration features are some of the main extensions in the

ALM 2.0+ standard.



ALM at Facebook 10

4 ALM at Facebook

Facebook started in a dorm room 7 years ago. It is now in the top five of the most-trafficked sites

in the world. (Stark, J., 2005) One recent challenge is "going from a purely engineering-driven

culture - writing software for users sharing information - to now operating this truly large infra-

structure. Those are two very different things. You make tradeoffs in IT to speed developmentthat often can lead to disaster later when you have to operate five years later." (Nash, K. 2008)

The following section explains how Facebook tackles this problem and if ALM could help in this

situation.

4.1 What 20 minutes on Facebook look like

Shared links: 1,000,000 every 20 minutes

Tagged photos: 1,323,000

Event invites sent out: 1,484,000 Wall Posts: 1,587,000

Status updates: 1,851,000

Friend requests accepted: 1,972,000

Photos uploaded: 2,716,000

Comments: 10,208,000

Message: 4,632,000 (Facebook 2010)

To encompass those high performance requirements, Facebook developed many tools and

processes in-house. Though Facebook is a big supporter of Open Source and published many of

their achievements in tool development (Facebook 2011), few official information is available

about their internal processes for developing and maintaining the platform. Below is a summary

of typical ALM components and how they are managed at Facebook.

4.2 How ALM components look like at Facebook Coming from the definition of ALM as: "The administration and control of an application from

inception to its demise. It embraces requirements management, system design, software devel-

opment and configuration management and implies an integrated set of tools for developing and

controlling the project." (PC Magazine 2011) we structure Facebook's processes in a SoftwareEngineering part here called "Service Creation" and an Operations part called "Service Manage-

ment".

4.2.1 Service Creation

Facebook publishes major updates every tuesday with smaller updates being delivered daily.

Those fast iteration cycles are important to achieve Facebook's goal of being an innovation lead-

er. "We'd rather innovate and have a little mess to clean up than run something reliable but

stale." (Nash, K. 2008)



ALM at Facebook 11

4.2.1.1 Requirements

Non-functional requirements are reported to be less strict than in other technology companies.

While Google has strict rules for its software infrastructure to use (Metz, C. 2009), Facebook

engineers monitor their usage and figure out what they really need. Those needs are often sepa-

rate platforms for separate tasks (Hoff, T. 2010).

There are few Product Managers (ratio 1:10 (Lee, Y. 2011)) which may elect functional re-

quirements. They have much independence and freedom. "The key to being influential is to have

really good relationships with engineering managers. [They need] to be technical enough not to

suggest stupid ideas. side f tht, thee‟s eed t s f y peissi pss y e-

views when establishing roadmaps/backlogs." (Lee, Y. 2011)

4.2.1.2 System Design

System design varies vastly between different tasks: Often the matching infrastructure which the

feature should live upon is created first instead of designing the feature for a given infrastructure.This was the case with most big Facebook features, e.g. messaging (HBase (Metz, C. 2010)).

4.2.1.3 Implementation

Implementation is done with different programming languages, GNU C/C++, Ericsson Erlang,

GHC Haskell, Sun Java, INRIA OCaml, Perl PHP, Python, and Ruby being supported the most

(Facebook2 2011). Since those are fundamentally different languages, implementation differs

greatly. To help with cross-language development Facebook developed Thrift, a cross-language

development framework (Pingdom 2010).

4.2.2 Service Management Engineers are responsible for a feature as a whole and usually do all the jobs including design,

implementation, quality assurance (QA) and roll-out themselves. There is no dedicated QA team.

Every developer is responsible for his code.

4.2.2.1 Roll-Out

Facebook developed a series of techniques to roll out a new feature without negative impact on

performance or user retention. First, they test different varieties of the site in so-called A/B tests

(Pingdom 2010) to get information about changes in the usage.

Another method are "dark launches" which roll out a new feature but hide it for the end user.Facebook engineers are convinced that those are more efficient and effective than a QA envi-

ronment (Pingdom 2010) because you get performance data in advance without having to impact

the user experience.

Every Facebook engineer can do seamless pushes to the live site (Nash, K. 2008) to update his or

another part of the platform. To notice strange behavior in advance, a gradual roll out is per-

formed in nine phases (Nash, K. 2008) whereas the first phase pushes to only six of over 60k

servers.



ALM at Facebook 12

4.2.2.2 Operations

Facebook is a big supporter of profiling not only the development but also the live system (Ping-

dom 2010) taking performance hits into account to get as much info possible. Additionally to the

usual metrics like logs and performance graphs, the operations team can see changes of user be-

havior and react to it (Lee, Y. 2011).

A rollback to a precedent phase from "Roll-Out" is possible anytime. "We know there's going to

be broken things that happen fairly regularly. We are ready. We have emotional shields for

them." (Nash, K. 2008)

The operations team is situated in different locations between Sao Paolo and London to follow

the sun for better working schedules.

4.2.2.3 Optimization

To optimize the platform gradual feature disabling (Pingdom 2010) is available. All the commu-

nication between Facebook engineers happens via Facebook itself to strengthen it as a communi-

cation platform (Nash, K. 2008).

Everyone can change any code anytime. Though versioning and automated tests help in main-

taining a working platform Facebook engineers learn in the bootcamp that "With great power

comes great responsibility" and that they should act with care (Lee, Y. 2011).

4.3 ALM Benefits As we learned in the first part of this paper, introducing ALM may help for transparency and

consistency issues. General benefits of a more strict ALM approach for Facebook can be seen as:

More Transparency of the life cycles of the service

Synchronization between application and design

Tracing of developments

Higher incorporation of global distribution of developers

The internal application life cycle solutions seem to work very well for the engineering-driven

culture at Facebook which poses the question if the advantages above are worth a change of

those solutions.

Since 2006, Facebook has opened its platform to developers. They may develop apps and inte-grate pages with a variety of languages and possibilities. Though, the Facebook platform as a

basis for app development has been criticized for years [(Medeiros, M. 2010), (Mackel, B.

2010)] because of its volatility of changes and few informations about when those changes come

and how they affect app development.

One of the main advantages for a more rigid ALM approach would be the inclusion of those ex-

ternal app developers in the development cycle. Standardizing and a better information policy

with ALM could potentially lead to a more productive and quality app environment. To quote

the official statistics: "People on Facebook install 20 million applications every day. Since social

plugins launched in April 2010, an average of 10,000 new websites integrate with Facebook every day." (Facebook3 2011) If Facebook could provide external developers with a more stable



ALM at Facebook 13

platform, this massive demand could forge some new apps which go far beyond the usual fun

app right now. Facebook once more could be the innovation-leader in collaboration and consum-

er innovation techniques.



Conclusion 14

5 Conclusion

Facebook is all about communication, innovation and speed. It is designed to integrate the plat-

form into everyday usage and is even used for coordinating its own engineers. The fast-driven

expansion worked very well for the last years both technically and economically. We showed

that Facebook grew to a dimension where purely engineering-driven roadmaps are hard to coor-dinate with other stakeholders.

It is time to think of Facebook not only as a provider but also as a platform to create. With this

definition, the vast majority of Facebook developers are not in-house. Facebook has given the

base to become succesful for quite a few companies. As was layed out, guiding this potential

developer base in the right direction can make the platform even stronger and more innovative.

A strategy which can only be used when knowing the internal roadmap, maintaining a reliableplatform and communicating changes early. As has been shown, the recent developments in

ALM 2.0 give a framework which could handle an agile development practice while leveraging

the communication between stakeholders and supporting a new expansion strategy as a service

provider.



<Bibliography 15

6 Bibliography

Abramovici, M. (2007): Future Trends in Product Lifecycle Management (PLM), The Future of

Product Development: Proceedings of the 17th CIRP Design Conference, Berlin, Germany,

March 26 – 28, pp. 665 – 674.

Chappell, D. (2008): What is application lifecycle management, Chappell & Associates, White

paper.

Dave West with Jeffrey S. Hammond, Mary Gerush, and Sander Rose. 2010. The Time Is Right

For ALM 2.0+. s.l. : Forrester Research, 2010.

Dave West (2011) It’s Time To Take Agile To The Next Level , in Forrester Research

Facebook (2010): A Snapshot of Facebook in 2010. http://www.facebook.com/notes/democracy-

uk-on-facebook/a-snapshot-of-facebook-in-2010/172769082761603 last access: 26-05-2011.

Facebook (2011): Open Source. http://developers.facebook.com/opensource/ last access: 26-05-

2011.Facebook2 (2011): Engineering Puzzles.

http://www.facebook.com/careers/puzzles.php?puzzle_id=11 last access: 26-05-2011.

Facebook3 (2011): Statistics. http://www.facebook.com/press/info.php?statistics last access: 26-

05-2011.

Georgalas, J. and Achilleos, A. (2009): Agile Product Lifecycle Management for Service Deli-

very Frameworks: History, Architecture and Tools, BT Technology Journal, Vol. 26, No. 2,

Springer, 2009.

Hoff, T. (2010): Facebook's New Real-Time Messaging System: HBase To Store 135+ Billion

Messages A Month. http://highscalability.com/blog/2010/11/16/facebooks-new-real-time-

messaging-system-hbase-to-store-135.html last access: 26-05-2011.

iie, J. (2011): Towards an Application Lifecycle Management Framework, Espoo 2011.

VTT Publications 759

iie, J. (2009): Extending Global Tool Integration Environment towards Lifecycle Man-

agement, OTM 2009 Workshops, LNCS 5872, pp. 238 – 247, 2009. © Springer-Verlag Berlin

Heidelberg 2009

Kim, J. and Choi, S. (2010): An Implementation Strategy of Evidence-Based Application Life-

cycle Management, Security-Enriched Urban Computing and Smart Grid, Communications inComputer and Information Science, Volume 78. ISBN 978-3-642-16443-9. Springer Berlin Hei-

delberg, 2010, p. 560

Lee, Y. (2011): How Facebook Ships Code. http://framethink.wordpress.com/2011/01/17/how-

facebook-ships-code/ last access: 26-05-2011.

Mackel, B. (2010): Facebook Development Sucks.

http://www.bushmackel.com/2010/01/11/facebook-development-sucks/ last access: 26-05-2011.

Medeiros, M. (2010): Facebook, you are doing it wrong.

http://blog.millermedeiros.com/2010/05/facebook-you-are-doing-it-wrong/ last access: 26-05-

2011.



<Bibliography 16

Metz, C. (2009): Google mocks Bing and the stuff behind it.

http://www.theregister.co.uk/2009/06/27/google_mocks_microsoft_online_infrastructure/ last

access: 26-05-2011.

Metz, C. (2010): Facebook's new comms: 'our largest ever engineering project'.

http://www.theregister.co.uk/2010/11/15/facebooks_largest_ever_engineering_project/ last

access: 26-05-2011.

Nash, K. (2008): Facebook tech infrastructure needs constant care.

http://www.itworld.com/internet/54625/facebook-tech-infrastructure-needs-constant-care last

access: 26-05-2011.

PC Magazine (2011): Application Lifecycle Management Definition.

http://www.pcmag.com/encyclopedia_term/0,2542,t=application+lifecycle+management&i=571

58,00.asp last access: 26-05-2011.

Pigd 2010): Explig the sftwe behid ceb, the wld‟s lgest site.

http://royal.pingdom.com/2010/06/18/the-software-behind-facebook/ last access: 26-05-2011.

Rossberg, Joachim. 2008. Pro Visual Studio Team System Application Lifecycle Management.

s.l. : Apress, 2008.

Schwaber, Carey and Gilpin, Mike. 2008. ALM 2.0: Getting Closer, But Not There Yet. s.l. :

Forrester Research, 2008.

Schwaber, C. (2006): The Changing Face of Application Life-Cycle Management, Forrester Re-

search Inc., White Paper, 18 August. 2006

Schwaber, C. (2005): The Expanding Purview Of Software Configuration Management, White

Paper, 22 July. 2005

Ssvui, A. and Immonen, A. (2004): Product Lifecycle Management, Springer-Verlag, Ber-

lin.

Stark, J. (2005): Product Lifecycle Management – 21st Century Paradigm for Product Realisa-

tion, Springer-Verlag London Limited.



Bearbeitungsaufteilung 17

7 Bearbeitungsaufteilung

Kapitel Bearbeiter/in

2 Max Müller

3 Volker Manz

4 Jakob Stoeck

Documents

Manz Mueller Stoeck FacebookALM Finalv2