Post on 07-Apr-2018
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
8/4/2019 Manz Mueller Stoeck FacebookALM Finalv2
http://slidepdf.com/reader/full/manz-mueller-stoeck-facebookalm-finalv2 2/18
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
8/4/2019 Manz Mueller Stoeck FacebookALM Finalv2
http://slidepdf.com/reader/full/manz-mueller-stoeck-facebookalm-finalv2 3/18
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
8/4/2019 Manz Mueller Stoeck FacebookALM Finalv2
http://slidepdf.com/reader/full/manz-mueller-stoeck-facebookalm-finalv2 4/18
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.
8/4/2019 Manz Mueller Stoeck FacebookALM Finalv2
http://slidepdf.com/reader/full/manz-mueller-stoeck-facebookalm-finalv2 5/18
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.
8/4/2019 Manz Mueller Stoeck FacebookALM Finalv2
http://slidepdf.com/reader/full/manz-mueller-stoeck-facebookalm-finalv2 6/18
History and Basics of Application Lifecycle Management 5
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.”
8/4/2019 Manz Mueller Stoeck FacebookALM Finalv2
http://slidepdf.com/reader/full/manz-mueller-stoeck-facebookalm-finalv2 7/18
History and Basics of Application Lifecycle Management 6
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).
8/4/2019 Manz Mueller Stoeck FacebookALM Finalv2
http://slidepdf.com/reader/full/manz-mueller-stoeck-facebookalm-finalv2 8/18
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
8/4/2019 Manz Mueller Stoeck FacebookALM Finalv2
http://slidepdf.com/reader/full/manz-mueller-stoeck-facebookalm-finalv2 9/18
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.
8/4/2019 Manz Mueller Stoeck FacebookALM Finalv2
http://slidepdf.com/reader/full/manz-mueller-stoeck-facebookalm-finalv2 10/18
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.
8/4/2019 Manz Mueller Stoeck FacebookALM Finalv2
http://slidepdf.com/reader/full/manz-mueller-stoeck-facebookalm-finalv2 11/18
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)
8/4/2019 Manz Mueller Stoeck FacebookALM Finalv2
http://slidepdf.com/reader/full/manz-mueller-stoeck-facebookalm-finalv2 12/18
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.
8/4/2019 Manz Mueller Stoeck FacebookALM Finalv2
http://slidepdf.com/reader/full/manz-mueller-stoeck-facebookalm-finalv2 13/18
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
8/4/2019 Manz Mueller Stoeck FacebookALM Finalv2
http://slidepdf.com/reader/full/manz-mueller-stoeck-facebookalm-finalv2 14/18
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.
8/4/2019 Manz Mueller Stoeck FacebookALM Finalv2
http://slidepdf.com/reader/full/manz-mueller-stoeck-facebookalm-finalv2 15/18
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.
8/4/2019 Manz Mueller Stoeck FacebookALM Finalv2
http://slidepdf.com/reader/full/manz-mueller-stoeck-facebookalm-finalv2 16/18
<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.
8/4/2019 Manz Mueller Stoeck FacebookALM Finalv2
http://slidepdf.com/reader/full/manz-mueller-stoeck-facebookalm-finalv2 17/18
<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.