Metropolis model


Published on

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Metropolis model

  1. 1. The Metropolis Model: ANew Logic for SystemDevelopment Rick Kazman Hong-Mei Chen University of Hawaii University of Hawaii and SEI/CMU
  2. 2. Trends Two trends are transforming our world:  the rise of the socio- technical ecosystem  the business trend towards service orientation
  3. 3. The Rise of the NetworkYochai Benkler’s The Wealth of Networks:  we are in the midst of a “radical transformation” of how we create our information environment  this transformation is restructuring society; models of production and consumption  Benkler calls this commons-based peer production
  4. 4. Service-Dominant Logic Service industries account for 55% of economic activity in the United States Businesses have moved from a goods- dominant view, to a service-dominant view In this new view customers are seen as co- creators of value
  5. 5. A Sea Change These changes are much more than just a shift from goods to services. They are a reframing of the purpose of the enterprise and its role in value creation. They are creating new phenomena, e.g. super-linear growth in projects, emergent behaviors in systems, …
  6. 6. Implications for Software Engineering Existing system development models are all broken in a crowdsourced world. These models assume:  projects have dedicated finite resources  management can “manage” these resources  requirements can be known  software is developed, tested, and released in planned increments  system growth is sub-linear
  7. 7. A New Model We suggest that a new model of the software lifecycle is needed: the Metropolis Model. This model helps us think about system creation that is commons-based and peer produced:  E.g. YouTube, Twitter, Facebook, Wikipedia, Orkut, Craigslist, Reddit, LinkedIn, WordPress, Pinterest, Flickr…
  8. 8. Metropolis Model Characteristics1. Mashability2. Conflicting, Unknowable Requirements3. Continuous Evolution4. Focus on Operations5. Open Teams6. Sufficient Correctness7. Unstable Resources8. Emergent Behaviors
  9. 9. 1. Mashability Old: we make systems difficult to tear apart, for historical, intellectual property and security reasons. New: “mashability” is a core capability of commons-based peer produced systems  mashups are accepted practice  web-services are proliferating (e.g., Google Maps APIs).  open source projects make it easy to interoperate; they are “nonrival”
  10. 10. 2. Conflicting, Unknowable Requirements Old: iterative lifecycles accept requirements change, but in any given iteration they try to collect and analyze those requirements. New: requirements in a peer-produced system emerge from its individuals, operating independently  requirements are never knowable in any global sense  they will inevitably conflict, just as the requirements of a city’s inhabitants often conflict
  11. 11. 3. Continuous Evolution  Old: systems evolved in planned releases  New: systems are constantly changing  resources are non-centralized and so a peer-produced system is never stable  one can not conceive of its functionality in terms of “releases” any more than a city has a release  parts are being created, modified, and torn down at all times
  12. 12. 4. Focus on Operations Old: focus on development/maintenance New: focus on system operations as a core competency  Google, eBay, Amazon .... must be “always on”  implies high availability, scalability, and seamless evolution
  13. 13. 5. Open Teams Old: closed team of developers who work from a consistent set of requirements New: volunteer projects and decentralized production processes with no managers  teams are diverse with differing, sometimes irreconcilable, views  even for-profit companies need to lead and motivate knowledge workers
  14. 14. 6. Sufficient Correctness Old: Completeness, consistency, and correctness as goals New: Perpetual beta  collaborative tagging does not depend on widespread agreement among the taggers  Wikipedia never claims to be complete or even fully correct
  15. 15. 7. Unstable Resources Old: Resources and their deployments are planned New: Applications that are peer-produced are subject to the whims of the peers  large numbers tend to ameliorate the actions of any individual  despite the lack of guarantees, unstable resource pools have resulted in significant computational achievements
  16. 16. 8. Emergent Behaviors Old: Goal was deterministic behavior New: Emergent behavior is normal and desirable  SecondLife, eBay, MySpace, and Twitter have seen complex human and system behaviors emerge that were beyond the vision and intent of their creators
  17. 17. A New Logic for System Development Logic: the formal principles of a branch of knowledge; a particular mode of reasoning viewed as valid or faulty -- Merriam-Webster Old models (and their principles) are inadequate What are the principles upon which we can build a new model?
  18. 18. Metropolis Model Structure Open Source Open Content Kernel Periphery Periphery: Developers Prosumers Masses: Customers Masses: Users Masses
  19. 19. Metropolis Model Principles1. Egalitarian Management2. Bifurcated Requirements3. Bifurcated Architecture4. Fragmented Implementation5. Distributed Testing/V&V6. Distributed Delivery/Maintenance7. Ubiquitous Operations
  20. 20. 1. Egalitarian Management Management of projects is not top-down Work is not assigned; people undertake the work they choose Status and rights are earned
  21. 21. 2. Bifurcated Requirements Requirements are bifurcated into: 1) kernel service requirements  deliver little or no end-user value  focus on quality attributes and tradeoffs  slow to change 2) periphery requirements  contributed by the peer network  deliver the majority of the function and end-user value  rapidly changing
  22. 22. 3. Bifurcated Architecture Architecture is bifurcated into: 1) kernel infrastructure  designed by a small, coherent team  highly modular  provides the foundation for the achievement of quality attributes 2) peripheral services  enabled by and constrained by the kernel  otherwise unspecified
  23. 23. 4. Fragmented Implementation The majority of implementation (the periphery) is “crowdsourced” to the world  using their own tools, to their own standards, at their own pace Implementers of the kernel are close-knit and highly motivated
  24. 24. 5. Distributed Testing/V&V The kernel must be highly reliable  this is tractable The reliability of the periphery is indeterminate  “sufficient correctness” is the norm
  25. 25. 6. Distributed Delivery/Maintenance The kernel must be stable:  seldom changing, and when it does change it must be backwards compatible At the periphery, perpetual beta is the norm:  constant stream of independent, uncoordinated “releases”  no notion of a stable system state
  26. 26. 7. Ubiquitous Operations Traditional systems—even highly reliable ones—could be “taken down” occasionally for maintenance and upgrades. Metropolis systems are “always on”, even when upgrading  upgrades are not ubiquitous Systems must scale with the number of users.
  27. 27. Implications of the Metropolis Model For some projects there are no implications There will always be projects that are:  high security  highly proprietary  safety critical  too burdened by legacy
  28. 28. Implications - 2 However, there is an increasingly broad and important class of projects to which the Metropolis model does apply. So, the question is: what should crowdsourced projects do differently from the way projects are built and managed today?
  29. 29. Implications – 3. Main implication: separation of kernel and periphery Consequences on:  Project management  Requirements Kernel  Architecture  Testing/V&V Periphery  Delivery/Maintenance Masses  Operations
  30. 30. Implications: Project Management A Metropolis project implies a virtual organization. To manage such a project the periphery must share in its success. The project must:  be (largely) self-governing and self-adaptive  have a clear task breakdown structure, but a minimum of hierarchy and bureaucracy  have technology for communication and coordination
  31. 31. Implications: Requirements Requirements are primarily asserted by the participants, not elicited from their users. Requirements emerge through their emails, Wikis, and discussion forums.  So such forums must be made available, and the participants should be encourage to participate
  32. 32. Implications: Architecture The kernel architecture must be built with a small, experienced, motivated team who focus on modularity  enable the parallel activities of the periphery. There should be a lead architect (or a small number of leads)  manage project coordination  have the final say in matters affecting the kernel
  33. 33. Implications: Implementation The project can guide, but not command, implementation. This implies the need for  a focus on communication, negotiation, and leadership.  good tutorials and examples  an attention to usability (simplicity, learnability) of the kernel
  34. 34. Implications: Testing/V&V Kernel must be tested heavily and validated  it is the fabric that holds together the system This can, however, be made tractable  keep the kernel small  have frequent builds
  35. 35. Implications: Delivery/Maintenance Delivery mechanisms must be created that accept:  incompleteness,  multiple versions, and  incompatibilities of the installed base as the norm.
  36. 36. Implications: Operations Operations must focus on high reliability of the kernel  accepting the fact that the periphery will often fail Monitoring and control mechanisms need to be created  so that bugs in the periphery can not undermine the kernel.
  37. 37. Final Thoughts Lifecycle models arise in reaction to ambient market conditions. The Metropolis Model is formally capturing a phenomenon that is already occurring: the dramatic rise of commons-based peer production. If an organization wants to take advantage of this it needs to understand it, and needs to understand how to foster it.
  38. 38. Thank You thoughts? comments? questions? …
  39. 39. Reference R. Kazman, H-M Chen, “The Metropolis Model: A New Logic for the Development of Crowdsourced Systems”, Communications of the ACM, July 2009, 76-84.