© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License
Architectures for the Edge
© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License
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
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
Ecosystem of Edge Dominant Systems
Open ContentSystems
Core
Edge
MassesOpen Source Software
(Prosum
ers)
(Developers)
(End U
sers)
(Custom
ers)
© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License
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
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
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
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
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
Implications for Architecture
• The architecture is divided into– Core– Periphery
© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License
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
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
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
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
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
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
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
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
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
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
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
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.
Zoning Board
Building inspector
Building code
Member serves on
Appointing authority
DevelopersCitizen or citizen groups
produces
selects
Enforces building code
Requests variance or zoning change
Funding by government
funds
Expert advisor
Zoning Board Stakeholders
Requests variances Approves/deniesrequests
© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License
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.