Centralize or Decentralize? A Requirements Engineering Perspective on Internet-Scale Architectures Eric Yu University of Toronto July 2000.

Centralize or Decentralize?

A Requirements Engineering Perspective on Internet-Scale

Architectures

Eric Yu

University of TorontoJuly 2000

Themes of this talk

•Architectural decisions are (should be) driven by Requirements Need to make the linkages

• more explicit, and• better supported

•Need to collect fine-grained design knowledge to support systematic design

“Knowledge-based” approach representational framework analysis and design techniques collections of design knowledge methodologies tools

Non-Functional Requirements*

•Designing large-scale systems involves tough tradeoffs among many interacting forces

performance cost usability reliability security maintainability evolvability time-to-market ...

* also called “-ilities”, Extra-Functional Requirements, Quality Attributes, ...

“-ilities” are most often viewed as evaluation criteria for

architectures

•Most discussions of architectures take these Requirements as evaluation criteria, ie. present an architectural solution then argue for its benefits (and drawbacks) with

respect to these qualities/ attributes

•For example… <most of the talks in this Workshop> [Yimam Kobsa] talk shows this approach is too coarse-

grained for guiding design (first contrasts decent. and cent., then adopts hybrid.)

From [Yimam & Kobsa TWIST2000] presentation

AnalysisFactor Agents Aggregated

Locality (processing/load distribution) Facilitated limited

Mining personal resources easier difficult

Personal Privacy preservation At the hand of the expert At the hand of maintainer

No single point of failure Single point of failure(backup mechanisms needed)

ScalabilityRobustness (in face offailure)

Extendability Easy by adding new agents Depends on design

Central administration No Yes

Experts feeling in control Yes Mostly not

Background

Alternatives

DEMOIR

First appr.

Summary

From [Yimam & Kobsa TWIST2000] presentation Analysis (contd.)

Factor Agents(alt 1)

Aggregated(alt 2)

Organization-wide access to expertiseinfo.

Limited (e.g. to expertnetwork, etc.)

facilitated

Multi-purpose/optimal utilization ofexpertise info (analysis, visualization,browsing, etc.)

Limited facilitated

Sources of expertise evidence mined Mostly limited to personalresources

Organizational resources(repositories, databases,Web/Internet, etc.)

Query Performance (scalability) Low (due to the need toconsult many agents)

High due to single location ofinformation

Knowledge-based/statisticaltechniques support

poor Good

Coordination overhead High (e.g. getting agentsfind and interact with oneanother)

low

Background

Alternatives

DEMOIR

First appr.

Summary

To centralize or decentralize… ?•Should first ask: What requirements are you trying to

address?•Design question: Given the requirements, what are

the suitable solutions?• Need to relate architectural solutions ---systematically to-->

requirements/ attributes• then use them in the reverse direction during designExamples:

replication --> for speed of global access distribute data close to source or user --> for local processing redundancy --> for reliability centralized management --> to reduce mgmt costs single database --> to avoid inconsistencies fewer sites --> to reduce security exposure

•But need finer-grained reasoning

Need for Requirements Engineering frameworks

•Tradeoffs among competing requirements occur at many places and at various stages during requirements analysis and system design decision-making process

•Need systematic framework to support: managing large no. of requirements (Func. & Non-

Func.) detecting & analyzing their interactions using requirements to guide exploration, pruning &

evaluation of design alternatives dealing with change

Goal-Oriented Requirements Analysis•Treat requirements as Goals, refine and reduce until

operationalized, taking interactions into account[Chung Nixon Yu Mylopoulos 2000 Non-Func. Reqmts for SE], also CACM Jan. 99

Trusted Personnel[Ticket Itinerary Info]

Bonded Personnel[Ticket Payment Info]

Fault TolerantProcessor[Ticket Info Processor]

Redundant Disk Array[Ticket Info Storage]

.........

Security[Ticket Info]

Integrity [Ticket Info]

Confidentiality[Ticket Info]

Confidentiality [Ticket Itinerary Info]

Confidentiality [Ticket Payment Info]

Availability[Ticket Info]

Reliability[Ticket Info Processing]

Tamper Resistant [Ticket Info Processing]

...Costs [Ticket System]

Scalability [Ticket System]

-

-

From viewpoint of Goal-Driven Design...

•Centralize vs. Decentralize refer to broad classes of design techniques or design

patterns that have been invented over the years in a number of design areas• transaction processing performance• long-term storage• system availability• security• management functions

•Specific techniques for addressing each of these may have classes of solutions that are centralized or decentralized

•Each technique tends to address one primary requirement, but typically have impacts on other requirements. Need systematic support to discern, clarify, analyze the interacting issues

Knowledge-Based Approach for Requirements-Driven Design

•A representational framework (notations, models, languages, ontologies) - expressive enough to deal with the subject matter: reqmts, elaboration steps, design techniques, design steps and process, alternatives, relationships, etc.

•Analysis and Design techniques that make use of the semantics of the modelling constructs to support the engineering activities,eg. analyzing interactions among reqmts, generating design options, evaluating implications of design alternatives,...

•Collections of reusable design knowledge (KhBs) from case studies to generic knowledge eg. common types of requirements and their possible elaboration, design principles, methods, rules, techniques, patterns of solutions to common design problems, architectures, frameworks, etc.

Knowledge-Based Approach for Requirements-Driven Design

(cont’d)•Methodologies for guiding the use of the framework,

principles, techniques, etc., in various settings

•Tools that use the structure & semantics of the knowledge to automate some aspects of the engineering activities, eg. visualization, animation, simulation, verification, support for reasoning (qualitative, quantitative, case-based…) and basic management facilities (maintaining design history, traceability, navigation, query, retrieval, version & change management…)

Example: telecom software productDetailed design reasoning in software

architecture

• task-decomposition• means-ends• contributions to softgoals

Requirements and Organizational Issues

•Requirements comes from many quarters in user organization

• various kinds of users,• operations personnel• management ...

in development organization• developers• product managers• project managers• quality assurance• marketing …

•Tradeoffs involve negotiations among stakeholders (e.g., [Boehm])

•Organizational issues affect technical decisions in significant ways (e.g., [Conway])

For Internet-scale systems… organizational issues even more

complex•Many distinct economic and legal entities

involved in the development, use, and management

•Each player has its own interests to pursue•No single overview, or even understanding

(e.g., new functionality being added via plug-&-play)

•Centralize vs. Decentralize question applies to technical as well as organizational domains

Many ways of dividing up the scope of control at various levels•ownership domains•administrative and business management domains• trust domains, from viewpoint of each (class of)

stakeholder: application providers, network operators, user

organizations, end-users, intermediaries

•developer domains - div. of responsibilities in development

•operations management domains - e.g., failure recovery, performance optimization, load balancing, etc.

• technical architecture domains at various levels - subsystems, components, modules

Domains have intertwined relationships

•For example, trust domains may coincide with administrative

domains ownership domains may overlap with design domains

•Alignments are sometimes intended, other times incidental usually imperfect restructured (or may drift) over time.

•Complex organizational issues => need extended ontology goal-oriented --> agent-oriented

Agent-Oriented Analysis• Intentional actor as a modelling abstraction to deal

with locality and distribution at an intentional level.•Actors have goals, beliefs, abilities, commitments.•Actors depend on each other for goals to be

achieved, tasks to be performed, and resources to be furnished.

Example: Smart CardsSome basic relationships among stakeholders

Resource Dependency

Task Dependency

Actor

LEGEND

Agent-Oriented Analysis (cont’d)

•Each actor pursues its own interests, while considering the consequences of its decisions and actions because of its relationships with other actors.

•The deliberations of each actor is modelled analogously to the goal-graph structure of NFR framework.

•The design space is carved up into many localized spaces.

•The intentional relationships among actors define the interfaces among localized spaces.

•Actors have limited knowledge about internal rationales of other actors.

Example: Smart CardsDetailed relationships from viewpoint of each player

LEGEND

Analyzing security & trust in deploying Smart Card technology

One particular Smart Card deployment configuration: Phone company as Terminal Owner, Data Owner, Card Issuer, Card Manufacturer, and Software Manufacturer

tools

Summary

•Knowledge-based approach to SE representational framework - Goals and Agents as

key constructs in the ontology analysis and design techniques collections of design knowledge methodologies - Requirements-Driven tools

•Key Challenges: collecting, organizing knowledge for system design

(including various reasons for centralizing vs. decentralizing)

Providing analysis and design support