Centralize or Decentralize? A Requirements Engineering Perspective on Internet-Scale Architectures

1
Centralize or Decentralize?A Requirements
Engineering Perspective on Internet-Scale
Architectures

• Eric Yu
• University of Toronto
• July 2000

2
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

3
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, ...

4
-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
• ltmost of the talks in this Workshopgt
• Yimam Kobsa talk shows this approach is too
  coarse-grained for guiding design (first
  contrasts decent. and cent., then adopts hybrid.)

5
From Yimam Kobsa TWIST2000 presentationAnalys
is
Background
First appr.
Alternatives
DEMOIR
Summary
6
From Yimam Kobsa TWIST2000 presentation
Analysis (contd.)
Background
First appr.
Alternatives
DEMOIR
Summary
7
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--gt requirements/ attributes
• then use them in the reverse direction during
  design
• Examples
• replication --gt for speed of global access
• distribute data close to source or user --gt for
  local processing
• redundancy --gt for reliability
• centralized management --gt to reduce mgmt costs
• single database --gt to avoid inconsistencies
• fewer sites --gt to reduce security exposure
• But need finer-grained reasoning

8
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

9
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

10
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

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

12
Knowledge-Based Approach for Requirements-Driven
Design (contd)

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

13
Example telecom software productDetailed design
reasoning in software architecture

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

14
(No Transcript)
15
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)

16
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

17
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

18
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 gt need extended
  ontology
• goal-oriented --gt agent-oriented

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

20
Example Smart CardsSome basic relationships
among stakeholders
21
Agent-Oriented Analysis (contd)

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

22
Example Smart CardsDetailed relationships from
viewpoint of each player
23
Analyzing security trust in deploying Smart
Card technology
Attack!
Defense!
24
One particular Smart Card deployment
configuration Phone company as Terminal Owner,
Data Owner, Card Issuer, Card Manufacturer, and
Software Manufacturer
When several roles are played by the same
player, some attacker-defender pairs disappear.
25
tools
26
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