Your SlideShare is downloading. ×
Software Architecture in Practice, Chapter 27
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Software Architecture in Practice, Chapter 27

463
views

Published on


0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
463
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
78
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Architectures for the Edge© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License
  • 2. Chapter Outline• The Ecosystem of Edge-Dominant Systems• Changes to the Software Development Life Cycle• Implications for Architecture• Implications of the Metropolis Model• Summary © Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License
  • 3. Edge Dominant Systems• An Edge Dominant System is one that depends on input from users for its success. – Crowdsourced • Wikipedia • You Tube – Open Source • Apache web server • Hadoop © Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License
  • 4. Ecosystem of Edge Dominant SystemsOpen OpenContent Masses SourceSystems Software Edge (Developers) (Customers) (Prosumers) (End Users) Core © Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License
  • 5. Metropolis Diagram• Representation of three communities – not an architecture diagram – Customers and end users – Developers – “prosumers” – people who both produce and consume content• Three different types of stakeholders – Outermost contribute content but not requirements – Middle are the prosumers. The goals of the organization is to make facilitate their interactions. – At the core is software with a collection of APIs. These APIs allow the prosumers to interact with each other and to provide content for the outermost ring. © Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License
  • 6. Roles Have Different “Permeability”• In open source systems it is possible to move from – consumer to contributor (outside ring to middle ring) – Contributor to committer (middle ring to developer of inner ring).• In open content systems – Possible to move from consumer to contributor (outside ring to middle ring) – Not possible to move into core developer through contributions to content. © Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License
  • 7. Key Questions• Assume your organization wishes to foster edge-dominant systems.• Two key questions: – How should we architect the core? – What development principles should we adopt for the periphery/edge? © Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License
  • 8. Changes to the Software Development Life Cycle• Assumptions in the normal SDLC are not true in an edge dominant system – Requirements can be basically known in advance. In edge dominant systems the requirements represent desires of a large community and can never be knowable. – Software is developed, tested, and released in planned increments. Edge-dominant systems evolve through local, incremental changes. What, for example, is the latest “release” of Wikipedia? © Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License
  • 9. More Changes to the SDLC– Projects have dedicated, finite resources. Edge- dominant systems grow with use and contributions. The number of contributors is potentially unlimited.– Management can manage the resources. Contributors may have a pool of potential changes but they choose from that pool or create new potential changes at their will. © Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License
  • 10. Implications for Architecture• The architecture is divided into – Core – Periphery © Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License
  • 11. Core Requirements - 1• The core provides services and quality attributes for the periphery. Core services are slow to change since there are a great many peripheral applications that depend on them.• Constructed by a small tight-knit team.• Highly modular and layered so that changes can be made with minimal side effects.• Highly robust with respect to errors in its environment. The core will be (mis)used by many different applications whose interactions are not foreseeable. © Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License
  • 12. Core Requirements – 2• Documentation must be available for each API. The lack of documentation must not be a barrier to entry for new peripheral developers.• There must be a discovery service. – Some services are going to be redundant and others are going to be unavailable. – A discovery service enables navigation and flexibility. – A registration service allows services to register upon initialization.• Error detection is complicated. – Deep service chains means determining source of error is difficult. – Constant testing of the services is necessary.• Peer services might be potential Denial of Service attackers. Throttling, monitoring, and quotas must be employed. © Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License
  • 13. Implications of the Metropolis Model – 1• Indifference to phases: – The metaphor is a bull’s eye, not waterfall, spiral, or other development model. – Focus managerial attention on the explicit inclusion of customers (the periphery and the masses) for system development. © Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License
  • 14. Implications of the Metropolis Model – 2• Crowd management: – Policies for crowd management must be aligned with the organization’s strategic goals and must be established early. – Business models must be examined to consider policies and associated system development tasks for crowd engagement, performance management monitoring, community protection, etc. – For-profit organizations must carefully align tasks with the volunteers’ values and intentions. © Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License
  • 15. Implications of the Metropolis Model – 3• Core versus Periphery: – The core must be small and tightly controlled by a group who focus on modularity, core services, and core quality attributes. – The periphery can establish different processes and roles for each sub-group within it. These are essentially unsupervised. © Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License
  • 16. Implications of the Metropolis Model – 4• Requirements Process: – The requirements for a Metropolis system are asserted by the periphery. – They emerge from the forums (mailing lists, wikis, etc.) around each sub-community of the periphery. – Such forums must be made available—typically provided by members of the core. © Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License
  • 17. Implications of the Metropolis Model – 5• Focus on Architecture: – The core architecture is the fabric that holds together a Metropolis system. – It must be consciously designed to accommodate the specific characteristics of open content and open source systems. – There should be a lead architect, or a small team of leads, who can manage project coordination and who have the final say in matters affecting the core. © Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License
  • 18. Implications of the Metropolis Model – 6• Distributed Testing: – The core/periphery distinction provides guidance for testing activities. – The core must be heavily tested and validated, since it is the fabric that holds the system together. – The core should be kept small. – The project should have frequent (perhaps nightly) builds and frequent releases. – Bug reporting should be built in to the system and require little effort on the part of the periphery. © Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License
  • 19. Implications of the Metropolis Model – 7• Automated Delivery: – Delivery mechanisms must be created that work in a distributed, asynchronous manner. – Any delivery mechanism must be tolerant of older versions, multiple co-existing versions, or even incomplete versions. © Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License
  • 20. Implications of the Metropolis Model – 8• Management of the periphery: – The core exercises very little control over the periphery. – There is a governance policy set by a governing board if the project is non-profit and set by the owning organization if the project is for profit. © Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License
  • 21. Implications of the Metropolis Model – 9• Enforcement models – Proactive enforcement. Proactive enforcement inhibits contributions by the prosumers or the peripheral developers unless they meet certain criteria. – Reactive enforcement. Reactive enforcement dictates the response in case there is a violation of the organization’s policy. © Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License
  • 22. Analogy with a Zoning Board• Modern cities have zoning boards to control allowable usage and development within their borders.• The Metropolis will likely have a similar structure.• We examine the structure of a zoning board to gain insight into how a Metropolis will work. © Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License
  • 23. Zoning Board Stakeholders selects Appointing Member authority serves Expert on advisor produces funds Funding by government Building Zoning Board code Requests Requests variances Approves/ variance or denies zoning change Enforces building code requestsBuilding inspector Developers Citizen or citizen groups
  • 24. Summary• Open source and crowd sourced systems can be viewed as instances of the Metropolis model.• This model has implications with respect to architecture and other life cycle activities.• A city zoning board provides a useful analogy. © Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License