software architecture in practice, chapter 27

© Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License

Architectures for the Edge


Chapter Outline

• The Ecosystem of Edge-Dominant Systems • Changes to the Software Development Life

Cycle • Implications for Architecture • Implications of the Metropolis Model • Summary


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


Ecosystem of Edge Dominant Systems

Open ContentSystems

Core

Edge

MassesOpen Source Software

(Prosum

ers)

(Developers)

(End U

sers)

(Custom

ers)


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.


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.


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?


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?


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.


Implications for Architecture

• The architecture is divided into– Core– Periphery


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.


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.


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.



• 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.



• 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.



• 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.



• 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.



• 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.



• 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.



• 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.



• 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.


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


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.

software architecture in practice, chapter 27

Documents

rick kazman

paul clements

edge len bass

core periphery len bass

edge dominant systems

core services

dominant systems changes

core requirements