A Social Organization Perspective on Software Architectures

Abstract

This paper proposes a set of concepts for describing a software architecture as a social organization. This social structure consists of actors who have goals to fulfil and social dependencies describing their obligations. The framework is an adaptation of i* [17] proposed as a modeling language for early requirements. Based on this framework, the paper advocates architectural styles for software which adopt concepts from organization theory and strategic alliances literature. The styles are modeled in i* and formalized in terms of Telos metaconcepts. Each proposed style is evaluated with respect to a set of software quality attributes, such as predictability, adaptability and openness. The use of these styles is illustrated and contrasted with two examples of software architectures reported in the literature.

Full text

Page 1

A Social Organization Perspective on Software Architectures

Manuel Kolp
Dept. of Computer Science
University of Toronto
10 King’s College Road
Toronto M5S3G4, Canada
mkolp@cs.toronto.edu

jbc@cin.ufpe.br
Jaelson Castro
Centro de Informática
Universidade Federal de
Pernambuco
Av. Prof. Luiz Freire s/n
Recife PE, Brazil 50732-970
John Mylopoulos
Dept. of Computer Science
University of Toronto
10 King’s College Road
Toronto M5S3G4, Canada
jm@cs.toronto.edu


Abstract

This paper proposes a set of concepts for describing a
software architecture as a social organization. This social
structure consists of actors who have goals to fulfil and
social dependencies describing their obligations. The
framework is an adaptation of i* [17] proposed as a
modeling language for early requirements. Based on this
framework, the paper advocates architectural styles for
software which adopt concepts from organization theory
and strategic alliances literature. The styles are modeled
in i* and formalized in terms of Telos metaconcepts. Each
proposed style is evaluated with respect to a set of
software quality attributes, such as predictability,
adaptability and openness. The use of these styles is
illustrated and contrasted with two examples of software
architectures reported in the literature.


1. Introduction

We are interested in narrowing the semantic gap
between a software architecture and the requirements
model from which it was derived. One way to achieve this
is to adopt the same concepts for describing requirements
and software architectures. This paper reports on an
experiment to use concepts from i*, a modeling
framework for early requirements, to model software
architectures.
i* offers concepts such as actor, goal, and social
dependency intended to model social structures involving
social actors, their goals and social inter-dependencies. To
adopt this framework for software architectures, we first
propose a set of architectural styles inspired by
organizational theory and strategic alliance literature, and
formalize these as Telos [9] metaconcepts. To guide the
selection process among the styles, we evaluate them with
respect to a number of software qualities. Finally, we
illustrate their use by applying them to two examples of
software architectures reported in the literature.
This research is being conducted in the context of the
Tropos project [1], which is developing a requirements-
driven methodology for software systems.
Section 2 presents
architectural styles described in terms of the strategic
dependency model from i* and specified in Telos. Section
3 introduces a set of desirable software quality attributes
for comparing them. Section 4 overviews a mobile robot
and an e-business examples while Section 5 sketches the
Tropos project within which this research has been
conducted. Finally, Section
contributions of the paper and points to further research.

2. Organizational Styles

Organizational theory (such as [7, 10]) and strategic
alliances (e.g., [5, 16]) study alternatives for (business)
organizations. These alternatives are used to model the
coordination of business stakeholders -- individuals,
physical or social systems -- to achieve common goals.
Using them, we view a software system as a social
organization of coordinated autonomous components (or
agents) that interact in order to achieve specific, possibly
common goals. We adopt (some of) the styles defined in
organizational theory and strategic alliances to design the
architecture of the system, model them with i*, and
specify them in Telos [9].
In i*, a strategic dependency model is a graph, in
which each node represents an actor, and each link
between two actors indicates that one actor depends on
another for something in order that the former may attain
some goal. We call the depending actor the depender and
the actor who is depended upon the dependee. The object
around which the dependency centers is called the
dependum. By depending on another actor for a
dependum, an actor is able to achieve goals that it is
otherwise unable to achieve, or not as easily or as well. At
our organization-inspired
6 summarizes the

Page 2

the same time, the depender becomes vulnerable. If the
dependee fails to deliver the dependum, the depender
would be adversely affected in its ability to achieve its
goals.
The model distinguishes among four types of
dependencies -- goal-, task-, resource-, and softgoal-
dependency -- based on the type of freedom that is
allowed in the relationship between depender and
dependee. Softgoals are distinguished from goals because
they do not have a formal definition, and are amenable to
a different (more qualitative) kind of analysis [2].
For instance, in the structure-in-5 style (Figure 1), the
coordination, middle agency and support actors depend on
the apex for strategic management purposes. Since the
goal Strategic Management is not well-defined, it is
represented as a softgoal (cloudy shape). The middle
agency actor depends on both the coordination and
support actors respectively through goal dependencies
Control and Logistics represented as oval-shaped icons.
The operational core actor is related to the coordination
and support actors respectively through the Standardize
task dependency and the Non-operational service resource
dependency.
In the sequel we briefly discuss ten common
organizational styles.
The structure-in-5 (Figure 1) style consists of the
typical strategic and logistic components generally found
in many organizations. At the base level one finds the
operational core where the basic tasks and operations --
the input, processing, output and direct support
procedures associated with running the system -- are
carried out. At the top of the organization lies the apex
composed of strategic executive actors.

Apex
Standardize
Coordination
Strategic
Management
Agency
Middle
Supervise
Operational
Core
Service
Non-operational
Logistics
Support
Control

Figure 1. Structure-in-5.

Below it sit the control/standardization, management
components and logistics, respectively coordination,
middle agency and support. The coordination component
carries out the tasks of standardizing the behavior of other
components, in addition to applying analytical procedures
to help the system adapt to its environment. Actors joining
the apex to the operational core make up the middle
agency. The support component assists the operational
core for non-operational services that are outside the basic
flow of operational tasks and procedures.
Figure 2 specifies the structure-in-5 style in Telos [9].
Telos is a language intended for modeling requirements,
design, implementation and design decisions for software
systems. It provides features to describe metaconcepts that
can be used to represent the knowledge relevant to a
variety of worlds – subject, usage, system, development
worlds - related to a software system. Our styles are
formulated as Telos metaconcepts, primarily based on the
aggregation semantics for Telos presented in [8].
The structure-in-5 style is then a metaclass -
StructureIn5MetaClass - aggregation of five (part)
metaclasses: ApexMetaClass, CoordinationMetaClass,
MiddleAgencyMetaClass,
OperationalCoreMetaClass,
composing the structure-in 5 style depicted in Figure 1.
Each of these five components exclusively belongs
(exclusivePart) to the composite (StructureIn5MetaClass)
and their existence depend (dependentPart) on the
existence of the composite. A structure-in-5 specific to an
application domain will be defined as a Telos class,
instance of StructureIn5MetaClass (See Section 4).
Similarly each structure-in-5 component specific to a
particular application domain will be defined as a class,
instance of one of the five StructureIn5Metaclass
components.

TELL CLASS StructureIn5MetaClass
IN Class WITH /*Class is here used as a MetaMetaClass*/
attribute
name: String
part, exclusivePart, dependentPart
ApexMetaClass: Class
CoordinationMetaClass: Class
MiddleAgencyMetaClass: Class
SupportMetaClass: Class
OperationalCoreMetaClass: Class
END StructureIn5MetaClass
Figure 2. Structure-in-5 in Telos.

Figure 3 formulates in Telos one of these five
structure-in-5 components: the coordination actor.
Dependencies are described
specifications for i* models [17]. The coordination actor
is a metaclass, CoordinationMetaclass. According to
Figure 1, the coordination actor is the dependee of a task
dependency StandardizeTask and a goal dependency
ControlGoal, and the depender of a softgoal dependency
StrategicManagementSoftGoal.

SupportMetaClass
one for
and
actor each
following Telos

Page 3

TELL CLASS CoordinationMetaclass
IN Class WITH /*Class is here used as a MetaMetaClass*/
attribute
name: String
taskDepended
s:StandardizeTask
WITH depender
OperationalCoreMetaClass: Class
END
goalDepended
c:ControlGoal
WITH depender
MiddleAgencyMetaClass: Class
END
softgoalDepender
s:StrategicManagementSoftGoal
WITH dependee
ApexMetaClass: Class
END
END CoordinationMetaclass

Figure 3. Structure-in-5 coordination actor in Telos.

The flat structure has no fixed structure and no
control of one actor over another is assumed. The main
advantage of this architecture is that it supports autonomy,
distribution and continuous evolution of an actor
architecture. However, the key drawback is that it requires
an increased amount of reasoning and communication by
each participating actor.
The pyramid style is the well-known hierarchical
authority structure exercised within organizational
boundaries. Actors at the lower levels depend on actors of
the higher levels. The crucial mechanism is direct
supervision from the apex. Managers and supervisors are
then only intermediate actors routing strategic decisions
and authority from the apex to the operating level. They
can coordinate behaviors or take decisions by their own
but only at a local level. This style can be applied when
deploying simple distributed systems.
Moreover, this style encourages dynamicity since
coordination and decision mechanisms are direct, not
complex and immediately identifiable. Evolvability and
modifiability can thus be implemented in terms of this
style at low costs. However, it is not suitable for huge
distributed systems like multi-agent systems requiring
many kinds of agents. Even tough, it can be used by these
systems to manage and resolve crisis situations. For
instance, a complex multi-agent system faced with a non-
authorized intrusion from external and non trustable
agents could dynamically, for a short or long time, decide
to migrate itself into a pyramid organization to be able to
resolve the security problem in a more efficient way.
The joint venture style (Figure 4) involves agreement
between two or more principal partners to obtain the
benefits of larger scale, partial investment and lower
maintenance costs. Through the delegation of authority to
a specific joint management actor that coordinates tasks
and operations and manages sharing of knowledge and
resources they pursue joint objectives and common
purpose. Each principal partner can manage and control
itself on a local dimension and interact directly with other
principal partners to exchange, provide and receive
services, data and knowledge. However, the strategic
operation and coordination of such a system and its
partner actors on a global dimension are only ensured by
the joint management actor. Outside the joint venture,
secondary partners supply services or support tasks for the
organization core.

Delegation
Authority
Partner_1
Principal
Partner_2
Principal
Partner_n
Ressource
Exchange
Principal
Partner_1
SecondarySecondary
Partner_n
Knowledge
Sharing
Management
Joint
Support
Coordination
Added
Value
Contractual
Agreement
Supplying
Services

Figure 4. Joint Venture.

The takeover style involves the total delegation of
authority and management from two or more partners to a
single collective takeover actor. It is similar in many ways
to the joint venture style. The major and crucial difference
is that while in a joint venture identities and autonomies of
the separate units are preserved, the takeover absorbs
these critical units in the sense that no direct relationships,
dependencies or communications are tolerated except
those involving the takeover.
The arm’s-length style implies agreements between
independent and competitive but partner actors. Partners
keep their autonomy and independence but act and put
their resources and knowledge together to accomplish
precise common goals. No authority is delegated or lost
from a collaborator to another.
The bidding style (Figure 5) involves competitivity
mechanisms and actors behave as if they were taking part
in an auction. The auctioneer actor runs the show,
advertises the auction issued by the auction issuer,
receives bids from bidder
communication and feedback with the auction issuer.
The auctioneer might be a system actor that merely
organizes and operates the auction and its mechanisms. It
can also be one of the bidders (for example selling an item
which all other bidders are interested in buying). The
auction issuer is responsible for issuing the bidding.
actors and ensure

Page 4

Start Bid
at the lowest
price
Run
Auction
Bidder_1
Bidder_2
Bid Higher
No Higher
Bid
Bidder_n
Auctioneer
Issuer
Best
Possible
Bid
Service/
Product

Figure 5. Bidding.

The hierarchical contracting style (Figure 6)
identifies coordinating mechanisms that combine arm’s-
length agreement features with aspects associated with
pyramidal authority. Coordination mechanisms developed
to manage arm’s-length (independent) characteristics
involve a variety of negotiators, mediators and observers
at different levels handling conditional clauses to monitor
and manage possible contingencies, negotiate and resolve
conflicts and finally deliberate and take decisions.
Hierarchical relationships, from the executive apex to the
arm’s-length contractors (top to bottom) restrict autonomy
and underlie a cooperative venture between the
contracting parties. Such dual and admittedly complex
contracting arrangements can be used to manage
conditions of complexity and uncertainty deployed in
high-cost-high-gain (high-risk) applications.

Controller
Negociator
Deliberator
RoutingBrokering
Observer
Executive
Mediator
Conflict
Solving
Contractor_1 Contractor_2Contractor_3
Contractor_n
Authority
Strategic
Decisions
Coordinate
Monitoring
Matching
Raw
Data

Figure 6. Hierarchical Contracting.

The vertical integration style merges, backward or
forward, one or more system actors engaged in related
tasks but at different stages of a production process. A
merger synchronizes and controls interactions between
each of the participants that can be considered
intermediate workshops. Vertical integrations take place
between exchange partners, actors symbiotically related.
The co-optation style (Figure 7) involves the
incorporation of representatives of external systems into
the decision-making or advisory structure and behavior of
an initiating organization. By co-opting representatives of
external systems, organizations are, in effect, trading
confidentiality and authority for resource, knowledge
assets and support. The initiating system, and its local
contractors, has to come to terms with what is doing on its
behalf; and each co-optated actor has to reconcile and
adjust his own views with the policy of the system he has
to communicate.

Knowledge
Sharing
Support
Cooptated_1
Contractor_1
Contractor_n
Services
Foreign
Provides
Assets
Cooptated_2
Cooptated_n
Ressource
External

Figure 7. Cooptation.

3. Evaluating Architecture

The organizational styles defined in Section 2 can be
evaluated and compared using the following software
quality attributes identified for architectures involving
coordinated autonomous components (e.g., Web, internet,
agent or peer-to-peer software systems) :
1 - Predictability [15]. Autonomous components like
agents have a high degree of autonomy in the way that
they undertake action and communication in their
domains. It can be then difficult to predict individual
characteristics as part of determining the behavior of a
distributed and open system at large.
2 - Security. Autonomous components are often able
to identify their own data sources and they may undertake
additional actions based on these sources [15]. Protocols
and strategies for verifying authenticity for these data
sources by individual components are an important
concern in the evaluation of overall system quality since,
in addition to possibly misleading information acquired by
components, there is the danger of hostile external entities

Page 5

spoofing the system to acquire information accorded to
trusted domain components.
3 - Adaptability. Components may be required to
adapt to modifications in their environment. They may
include changes to the component’s communication
protocol or possibly the dynamic introduction of a new
kind of component previously unknown or the
manipulations of existing components.
- Coordinability. Autonomous components are not
particularly useful unless they are able to coordinate with
other components. This can be realized in two ways:
4 - Cooperativity. They must be able to coordinate
with other entities to achieve a common purpose.
5 - Competitivity. The success of one component
implies the failure of others.
6 - Availability. Components that offer services to
other components must implicitly or explicitly guard
against the interruption of offered services. Availability
must actually be considered a sub-attribute of security [2].
Nevertheless, we deal with it as a top-level software
quality attribute due to its increasing importance in multi-
agent system design.
7 - Integrity. A failure of one component does not
necessarily imply a failure of the whole system. The
system then needs to check the completeness and the
accuracy of data, information and knowledge transactions
and flows. To prevent system failure, different
components can have similar or replicated capabilities and
refer to more than one component for a specific behavior.
8 - Modularity [14] increases efficiency of task
execution, reduces communication overhead and usually
enables high flexibility. On the other hand, it implies
constraints on inter-module communication.
9 - Aggregability. Some components are parts of
other components. They surrender to the control of the
composite entity. This control results in efficient tasks
execution and low communication overhead, however
prevents the system to benefit from flexibility.

1 2 3
Flat -- -- -
Struct-5 + +
Pyramid ++ ++ + ++
Joint-Vent + + ++ +
Bid -- -- ++
Takeover ++ ++ -
Arm’s-Lgth - -- +
Hierch Ctr +
Vert Integr + + -
Coopt - - ++ ++ +
4

+ -
5

6
+
+ ++ ++ ++
+ --
++
- -- ++
+
++ -- ++ +
+ +
- + --
-- -
7
+ ++
8 9
-
-
-
-
+ ++

- ++
++ --
-
+
+
+ +

+
--

+
--
--
Table 1. Correlation catalogue.
Table 1 summarizes the correlation catalogue for the
organizational patterns and top-level quality attributes we
have considered. Following notations used by the NFR
(non functional requirements) framework [2], +, ++, -, --,
respectively model partial/positive, sufficient/positive,
partial/negative and sufficient/negative contributions.

4. Examples

To motivate our organizational styles, we consider two
application domains where distributed and open
architectures (e.g., Web, internet, agent or peer-to-peer
software systems) are becoming increasingly important:
mobile robots and e-business systems.
We first consider the mobile robot example presented
in [13]. That case study describes notably the layered
architecture (Figure 8) implemented in the Terregator and
Neptune robots and used more recently to design the
architecture of the Xavier office delivery robot [11].


Figure 8. Classical mobile robot layered architecture.

According to [13] at the lowest level, reside the robot
control routines (motors, joints,...). Levels 2 and 3 deal
with the input from the real world. They perform sensor
interpretation (the analysis of the data from one sensor)
and sensor integration (the combined analysis of different
sensor inputs). Level 4 is concerned with maintaining the
robot's model of the world. Level 5 manages the
navigation of the robot. The next two levels, 6 and 7,
schedule and plan the robot's actions. Dealing with
problems and replanning is also part of the level-7
responsibilities. The top level provides the user interface
and overall supervisory functions.