STRATEGIC REASONING IN SOFTWARE DEVELOPMENT

Yves Wautelet

‡

, Sodany Kiv

†

, Vi Tran

†

and Manuel Kolp

†

‡

Faculteit Economie en Management, Hogeschool-Universiteit Brussel, Brussels, Belgium

†

Louvain School of Management, Universit

e Catholique de Louvain, Louvain-la-Neuve, Belgium

Keywords:

Strategic modeling, Requirements engineering, Service-oriented modeling, i*, Multi-agent systems.

Abstract:

Information systems tend to be huger and of strategic importance in nowadays buisnesses. That is why soft-

ware engineering is no more only a domain for middle managers and software engieering professionals but top

managers require rich models leading to visions on which they can perform strategic analysis for determining

their adequacy with long term objectives. The i* approach with its social modeling capabilities as well as ser-

vice oriented modeling are part of this effort. The strategic services model combines those two approaches and

deﬁnes a couple of environmental factors (namely threats and opportunities) enabling strategic reasoning on

the bases of the enterprise ”high-level” added values. Such a framework offers the adequate agregation level

for enabling top managers to take the adequate long term decisions for information systems development. The

aim of this paper is to illustrate the strategic services model application as well as a strategic reasoning in the

context of the development of a collaborative software application for supply chain management. This case

study is from particular interest since it must be adopted by several actors played by cooperating or competing

companies that have to ﬁgure out the consequences of the adoption of such software.

1 INTRODUCTION

Nowadays software developments are mostly driven

by engineering concepts; however, for the last ten

years a clear trend is to spend more time and effort

on the analysis disciplines. From poor (UML) use

case analysis models to semantically rich (i*) strate-

gic dependency and rationale organizational models

the willingness to adequately represent the software

problem and its operating environment has contin-

uously increased. Even if the i* approach brings

tremendous reﬁnements in representing the problem

into its organizational setting, such a representation is

still too detailed for top management so that it is not

adequate for the understanding they require. More-

over, service-oriented computing (SOC) is becoming

increasingly popular. Flexibility offered by service-

oriented architectures has rapidly been understood

that is why it is widely used today. Services as con-

ceptual entities can also be used as the fundamental

scope elements in software development which gave

birth to service-oriented modeling (SOM). They are

based on the enterprise values and thus constitute an

adequate abstraction level for reasoning in a strategic

context.

This paper is part of the effort to offer a high level

vision of software systems matching with the enter-

prise values in the form of services. It provides a real-

life case study in the ﬁeld of supply chain manage-

ment (SCM)

which proves the applicability of the

approaches suggested in (Pastor et al., 2010; Wautelet

et al., 2008) in such a context.

The paper is structured as follows. First the need

for a high level vision is enlighten, the suitability of

service oriented modeling in such a context is moti-

vated and related work is overviewed. The paper then

turns to the case study with the presentation of the

application domain, a collaborative platform for out-

bound logistics. The strategic view encompassing a

strategic reasoning about the development of the plat-

form is exposed. Finally conclusions are taken.

2 PROBLEM STATEMENT

This section motivates the importance of the frame-

work and its application.

In this paper we refeer to outbound logistics which is a

part of SCM, this will be clariﬁed later.

215

Wautelet Y., Kiv S., Tran V. and Kolp M. (2010).

STRATEGIC REASONING IN SOFTWARE DEVELOPMENT.

In Proceedings of the 12th International Conference on Enterprise Information Systems - Information Systems Analysis and Speciﬁcation, pages

215-220

DOI: 10.5220/0002901302150220

 SciTePress

2.1 The Need for a High Level Vision

Management sciences deﬁne several layers for deci-

sion making. Indeed, decisions do not have the same

impact - from a marginal short term consequence to a

major long term impact - so that their time horizon is

variable. Traditionally, management sciences identify

three levels for decision making to discriminate time

horizons and resources that should be allocated:

• The Strategic Level. Strategic decisions are top

level. Decisions taken here concern general direc-

tion, long term goals, philosophies and values;

• The Tactical Level. At the tactical level, more

concrete decisions are taken which aim at imple-

menting the strategy deﬁned at the corporate level.

The business units adapt this strategy in terms of

policies under which the operations will happen;

• The Operational Level. These are every day de-

cisions, used to support tactical ones. Their im-

pact is immediate, short term, short range, and

usually low cost. Operational decisions can be

pre-programmed, pre-made, or set out clearly in

policy manuals.

Most software development methodologies focus

on tactical and operational aspects. The traditional

analysis disciplines as for example business modeling

and requirements deﬁned in the Rational Uniﬁed Pro-

cess (IBM, 2003) are focused on tactical aspects since

they only describe business processes or requirements

with a poor semantic i.e. use case models with no

framework for strategic reasoning.

2.2 Towards Service-oriented Modeling

The framework presented here will be based on

service oriented modeling (SOM). Following (Bell,

2008), SOM is a software development practice that

employs modeling disciplines and language to pro-

vide strategic and tactical solutions to enterprise

problems. This anthropomorphic modeling paradigm

advocates a holistic view of the analysis, design, and

architecture of all organizational software entities,

conceiving them as service-oriented assets, namely

services. Services represent the values offered by the

enterprise (being here a high level actor) to their cus-

tomers, that is why they are by nature more expressive

than computer science driven concepts. They are also

highly aggregated so that they are perfectly suitable

for a high level view.

(Pastor et al., 2010) proposes to evaluate the i* (i-

star) framework (Yu, 1995) on the basis of a series

of 9 features: reﬁnement, modularity, repeatability,

complexity management, expressiveness, traceability,

reusability, scalability and domain applicability. The

paper deﬁnes those features and they are exhaustively

evaluated on the basis of a not supported/not well sup-

ported/well supported scale. Notably they enlighten

as a main conclusion on the practical evaluation what

is clearly needed to extend the i* framework with

mechanisms to manage granularity and reﬁnement.

Indeed they point out that the negative results in the

evaluation of i* are related to the lack of mechanisms

for deﬁning granules of information at different ab-

straction levels, allowing modelers to structure the in-

formation represented in the model. One of the lacks

of the i* modeling framework is indeed that all of the

organization modeling elements are represented in the

same diagram with consequently a unique abstraction

level and poor concepts hierarchy. Moreover, they

also point out that apart from the deﬁnition of ab-

stract primitives as building blocks, analysts must be

provided with guidelines to allow them to structure a

complete Enterprise through a set of organizational

processes. These building units could then be reﬁned

into a set of more speciﬁc components that encapsu-

late a certain organizational behavior. So they con-

clude their must be some high-level enterprise view

and propose a Business Service Architecture for the

i* framework.

To that extend, they propose to focus the organiza-

tional modeling activity on the values offered by the

Enterprise to their Customers. Those values are called

(business) services. (Pastor et al., 2010) also points

out that business services can be used as basic gran-

ules of information that allow us to encapsulate a set

of i* business process models. The services the en-

terprise offers are used as high level scope elements.

Business processes fulﬁlling those services are then

decomposed and reﬁned on that basis. This approach

allows to combine the intentional and social charac-

teristics of i* with the ”traditional” business process

modeling.

(Wautelet et al., 2008) proposes the FaMOS

framework. This framework notably reﬁnes the

proposition of (Pastor et al., 2010) and proposes the

Strategic Services Diagram which supplement the ser-

vices view with the deﬁnition of threats and opportu-

nities. In this ﬁgure, those two elements are gener-

alized as an Environmental Factor. Indeed, services

face threats which is deﬁned as every environmental

factor that can avoid the adequate fulﬁlment of the

service (both in terms of achievement and quality of

service degradation) as well as opporutinities deﬁned

as an environmental factor that can potentially higher

QoS.

This paper constitutes an elaborated case study of

the strategic services diagram which is one compo-

ICEIS 2010 - 12th International Conference on Enterprise Information Systems

216

nent of the FaMOS framework proposed in (Wautelet

et al., 2008)

3 APPLICATION DOMAIN

This section introduces the application domain, out-

bound logistics, as well as the third party components

used in the context of the collaborative platform de-

velopment. Note that for space reasons the domain

description has been brought to its simplest form the

strategic reasoning in section 4 goes into much more

details. A complete description of the application

domain and its associated workﬂows is depicted in

(Wautelet, 2009).

3.1 Outbound Logistics

Outbound logistics is the process related to the move-

ment and storage of products from the end of the pro-

duction line to the end user. In the context of this pa-

per we mostly focus on transportation. The actors of

the supply chain play different roles in the outbound

logistic ﬂow. The producer will be a logistic client in

its relationship with the raw material supplier, which

will be considered as the shipper. The carrier will re-

ceive transportation orders from the shipper and will

deliver goods to the client, while relying on the infras-

tructure holder and manager. In its relation with the

intermediary wholesaler, the producer will then play

the role of the shipper and the wholesaler will be the

client.

Supplier

Shipper

Producer

Client

Shipper

Wholesaler

Client

Shipper

Final client

Client

Carrier

Scheduler

Strategic planner

Infrastructure manager

Operational planner

Strategic planner

Logistic

request

Transport

Coordination

Order

Figure 1: Material ﬂows in the outbound logistics chain.

Figure 1 summarizes the material ﬂows between

the actors of the outbound logistics chain. The idea

underlying the software development is to favour

these actors’ collaboration. Indeed, collaborative de-

cision will tend to avoid local equilibriums (at ac-

tor level) and wastes in the global supply chain op-

timisation, giving opportunities to achieve the great-

est value that the chain can deliver at lowest cost (see

(Pache and Spalanzani, 2007)). More information on

Expeditions Representative

Treat Orders

Scheduler

Treat Expeditions

Plan Logistic Requests

Shipper

is-A

Carrier

is-A

Planner

Manage Transports

is-A

Manage Transports Services

Infrastructure Manager

Manage Resources

Customer

Orders Representative

TMS

Track Transports

WMS

FMS

ERP

Transfer Orders

Manage Warehouse

Manage Fleet

Figure 2: Strategic Services Diagram for the Collaborative

Application Package.

the applicative package development can be found in

(Wautelet, 2009).

4 STRATEGIC REASONING IN

SOFTWARE DEVELOPMENT

This section introduces a strategic level vision of the

collaborative platform to be developed; ﬁrstly the

model based on services is overviewed, secondly a

strategic reasoning overviews the consequences its

adoption represents both in terms of threats and op-

portunities.

4.1 The Collaborative Application

Package Services

The Strategic Services Diagram (SSD) of Figure 2

overviews the application package through multiple

Services. We use the SSD which presents on highest

aggregation level the services provided by the overall

application with the actors involved in the software

package as well as the potential threats and oppor-

tunities they are facing. By essence, the SDD helps

to understand the purpose of the software project in

terms of highly aggregated elements called Services.

The theoretical model also allows to model the poten-

tial problems (i.e. Threats) they can face; the poten-

tial improvements (i.e. Opportunities) and the social

structure (i.e. the Dependencies) which govern Actor

interactions. This highest level view allows all project

stakeholders to share a common aggregate view of

what the applicative package should offer as well as

their dependency relationships. The darkest services

are the ones that can be fulﬁlled by already identiﬁed

third party components. We will, in the context of this

case study focus on Track Transport. This service is

provided by the Transportation Management System

(TMS) to the Shipper and the Carrier.

STRATEGIC REASONING IN SOFTWARE DEVELOPMENT

217

A deﬁnition of the concepts relative to outbound

logistics - notably the actors in bold and the data

structures in italic - depicted in the services descrip-

tion hereafter was made in section 3.1. Each service

represents a complex workﬂow that is summarized

here in a few sentences, the complete workﬂows are

available in (Wautelet, 2009). The applicative pack-

age services are:

• The Treat Orders service represents the process

to plan the coming material ﬂows by building up

Logistic Requests on the basis of the customers

orders. The Carriers’ Expedition Representative

is the responsible actor;

• The Treat Expeditions service represents the pro-

cess to build Transportation Calls on the available

Logistic Requests. The Carriers’ Expedition Rep-

resentative is the responsible actor;

• The Plan Logistic Requests service represents

the process to evaluate the possibilities (even-

tually by relaxing constraints) of accepting the

transmitted Transportation Calls. The Shipper’s

Orders Representative is the responsible actor;

• The Manage Transports Services service repre-

sents the process to update the Carriers’ Trans-

portation Services offer in function of the general

environment (demand and capacity on particular

origins and destinations, new transportation pos-

sibilites, etc). The Carriers’ Planner is the re-

sponsible actor;

• The Manage Transports service represents the

process to plan the Carriers’ physical Transports

linked to its Transportation Services to answer to

the accepted Transportation Calls demand. The

Carriers’ Scheduler is the responsible actor;

• The Manage Resources service represents the

process to ensure an adequate planning of re-

quired resources (working teams, docks, cranes,

etc.) for the planned Transports. The Infrastruc-

ture Manager is the responsible actor;

• The Track Transports service represents the pro-

cess to track in real time the transported goods

and perform a series of activities such as dynamic

replenishments, alternative route calculation, etc.

The Actor’s TMS is the responsible actor;

• The Manage Fleet service represents the process

to accomplish a series of speciﬁc tasks in the man-

agement of a carrier vehicle ﬂeet as for example

telematics (tracking and diagnostics), driver man-

agement, fuel management, vehicle maintenance

and so on. The Actor’s FMS is the responsible

actor;

• The Manage Warehouse service represents the

process to manage the movement and storage of

materials within the warehouse and processing the

associated transactions, such as shipping, receiv-

ing, putaway and picking. The Actor’s WMS is the

responsible actor;

• The Transfer Orders service represents the pro-

cess to manage all the input data ﬂows that must

be transferred from the ERP system or to the ac-

tor ERP system. The Actor’s ERP is responsible

actor.

4.2 Strategic Reasoning

At strategic level, we mainly study the long-term

strategic impact of adopting the collaborative soft-

ware package through its relevant services for the

concerned actors. This study is mainly concerned

with two aspects that are balanced and that must be

evaluated and focused on when taking the strategic

decisions, namely opportunities and threats. Indeed,

e-collaboration in SCM can potentially deliver series

of advantages as information sharing, real-time deci-

sion making, online auctions and notably global op-

timization. Nevertheless, this advantage and others

can have drawbacks for some of the concerned actors

and they may thus not want to adopt it or, in case of

adoption, have disastrous consequences on their busi-

nesses. To that end, a ﬁrst strategic analysis - inde-

pendent of any cost evaluation - on the basis of the

proposed services, the opportunity they represent and

the threats they face and targeted to the involved ac-

tors is made here.

As deﬁned in the FaMOs framework (Wautelet

et al., 2008) one of the most important beneﬁts of

the SSD is to directly incorporate opportunities and

threats as elements of the model. For clarity rea-

sons we will however not represent them graphically

into the model but list them and draw an opportuni-

ties/services matrix as well as a threats/services one.

This analysis is generic in the sense that we adopt the

point of view of the leading actor (that can be visu-

alized in the SSM) for each of the opportunities and

threats we evaluate at the light of a particular service.

The added value/risk exposure for each particular

service to each particular opportunity/threat is then

evaluated on the basis of a low/medium/high/none

scale. The opportunity/threat hierarchy is established

through an ”Opportunity/Threat Table” assigning to

each service an opportunity added value/threat expo-

sure probability. We basically deﬁne four values for

opportunities added value/threats exposure probabil-

ity:

ICEIS 2010 - 12th International Conference on Enterprise Information Systems

218

• Low: ”L” in a yellow ﬁlled cell, has a weight of

• Medium: ”M” in a orange ﬁlled cell, has a weight

of 2;

• High: ”H” in a red ﬁlled cell, has a weight of 4;

• Non-existing: an empty cell, this service is not

concerned by this opportunity/threat, has a weight

of 0.

Global optimization cannot be introduced as such

as an opportunity to the involved actors. However,

that target has a particular interest for the environ-

ment in the sense that optimized transports leads to

less wastes which lowers negative externalities. In-

deed, since a variety of stakeholders are involved into

the package, each of them must be demonstrated its

”local” advantage to adhere. More precisely, we iden-

tify here the following opportunities and their associ-

ated weight:

• Real-time Information Transmission. Informa-

tion has become a strategic resource of our mod-

ern times so that information availability through

adequate transmission represents a strategic tool

for each of the actors involved in the supply chain.

The applicative package thus represents an oppor-

tunity since it enables to lower information trans-

mission time. This opportunity has been given a

weight of 5;

• Business Process Optimization. Reengineering

business processes notably through standardized

information transmission can lead to avoid wast-

ing resources (among which human ones) so that

time and money can be spared. This opportunity

has been given a weight of 4;

• Symmetric Information. The use of the ap-

plicative package ensures that when an actor has

a speciﬁc demand of services it is transmitted

to whole of the concerned actors. For example

the shippers’ logistic requests are transmitted to

whole of the carriers so that each of them can pro-

pose its transport services until an agreement has

been found. Information symmetry tends to lower

the eventuality that suppliers are unfairly favored.

This opportunity has been given a weight of 3;

• Uniﬁed Data Structures. The use of uniﬁed data

structures ease the everyday communications be-

tween supply chain actors and constitute a stan-

dardized formalization that can serve as a legal

basis. This opportunity has been given a weight

of 2;

• Integrated Information Portal. The use of a sin-

gle portal for managing all the aspects of an ac-

tors’ business eases the everyday transactions and

lowers maintenance costs so that resources can be

spared. This opportunity has been given a weight

of 1.

Opportunity weight

Treat Orders

Treat Expeditions

Plan Logistic Requests

Manage Transports Services

Manage Transports

Manage Ressources

Manage Warehouse

Track Transports

Manage Fleet

Transfer Orders

Real-Time Information Transmition 5 HMH HHMHMM

Business Process Optimization 4 HHH L HHH L

Symetric Information 3 MMMMH H

Unfiied Data Structures 2 L H H MHHMMMH

Integrated Information Portal 1 HHHHHHMMMM

Overall Service Opportunity Added Value 48 44 54 18 60 60 32 30 16 20

Figure 3: The Opportunities/Services Matrix.

The opportunities/services matrix presented in

Figure 3 allows determining a hierarchy among the

services to determine the one which could beneﬁt of

the most added value by adopting the collaborative

software package solution. The Manage Transports

and Manage Resources services have an added value

of 60 which underlies the solution could potentially

bring the most added value for carriers and infrastruc-

ture managers. The matrix also shows that the iden-

tiﬁed opportunities are adding substantial value to all

of the collaborative application package’s services so

that each of the collaborating actors can potentially

have an interest by the adoption of the solution which

however has only sense if all of them use it or at least

feed it with data ﬂows.

Global optimization and the adoption of a global

applicative package can however have a series of

drawbacks. These are studied hereafter in the form

of threats. More precisely, we identify here the fol-

lowing threats and their associated weight:

• Loss of Local Optimality. Actors are continu-

ously seeking for optimal solutions within their

business processes especially when competition is

high and concerns rather standardized services as

for example for carriers. A global optimization

process could lead actors of the supply chain to a

worse situation that when they only managed their

own business strategy so that they would reject

such a tool. This threat has been given a weight of

• Loss of Local Autonomy. The autonomy of an

actor refers to its capability to make and inﬂuence

decisions. The provided information of an actor to

the other can lead its autonomy to be adjusted in

one sense or the other so that it can be an oppor-

tunity or a threat (we nevertheless only consider

the ”threat side” here). In other words, increased

transparency can lead to a loss of autonomy. This

STRATEGIC REASONING IN SOFTWARE DEVELOPMENT

219

threat has been given a weight of 3;

• Transmission of Strategic Information. By ad-

vertising all of the transportation offer and de-

mand, one could determine information that the

company’s would prefer to remain conﬁdential.

This threat has been given a weight of 3;

• System Intrusion. An intrusion takes place when

a user of an information system takes an action

that he is not legally allowed to take. The intruder

may come from outside, or it may be an insider

exceeding his limited authority when taking ac-

tion. The intruder’s actions may be detrimental to

the health of the system or to the services it offers.

This threat has been given a weight of 2;

• Data Loss. Facing huge data transfers between

actors some required data can be lost or never fur-

nished. This threat has been given a weight of 2;

• System Failure. The information system may be

down and cannot be used for some time. This

threat has been given a weight of 2.

Threat weight

Treat Orders

Treat Expeditions

Plan Logistic Requests

Manage Transports Services

Manage Transports

Manage Ressources

Manage Warehouse

Track Transports

Manage Fleet

Transfer Orders

Loss of Local Optimality 4 L HHHHHML

Loss of Local Autonomy 3LHHHMHHL

Transmission of Strategic Information 3MHHHMLMMLL

System Intrusion 2 MMMMHMMM L M

Data Loss 2LLLLL

System Failure 2 L L L L MMMM

OverallServiceRiskExposure 14271844464136423116

Figure 4: The Threats/Services Matrix.

The threats/services matrix presented in Figure 4

allows determining a hierarchy among the services

to determine the one which is the most exposed to

risks. The Manage Transports service has an overall

risk of 46 which underlies risks are potentially high-

est for carriers. The matrix also shows that the iden-

tiﬁed threats have an impact on all of the collabora-

tive application package’s services so that each of the

collaborating actors has to overview the drawbacks

and compare them to the potential beneﬁts to run its

cost/beneﬁts study.

5 CONCLUSIONS

Software engineering tends to devote more and more

time and effort on analysis disciplines. In such a con-

text, it is no more only the concern of software an-

alysts, architects, developers and other project man-

agers but top management has to understand the long

term implications of software systems that can be de-

veloped. SOC promises to change the way business

and technology vendors buy, sell, deploy, and man-

age application portfolios. For the ﬁrst time, business

users will be able to summon applications to support a

business process rather than launch a business process

constrained by the application. That is why the appli-

cation of such technology into large hybrid software

projects combining self-developed services with third

party vendors components is particularly interesting.

In this context, we applied a SOM framework onto

the development of a SCM platform for providing an

high-level view to top management for strategic rea-

soning. The main contribution of the paper is the case

study itself showing the approach proposed in (Pastor

et al., 2010) and in (Wautelet et al., 2008) is applica-

ble in a large industrial context.

The Strategic Services Model and its use are how-

ever just a preliminary step of a broader methodology

using more detailed i* diagrams at analysis level as

well as design diagrams and project management.

REFERENCES

Bell, M. (2008). Service-oriented modeling: Service analy-

sis, design and architecture. John Wiley & Sons Inc.

IBM (2003). The rational uniﬁed process. Rational Soft-

ware Corporation, Version 2003.06.00.65.

Pache, G. and Spalanzani, A. (2007). La gestion des chanes

logistiques multi-acteurs : perspectives stratgiques.

Presses Universitaires de Grenoble (PUG).

Pastor, O., Estrada, H., and Mart

ınez, A. (2010). The

strengths and weaknesses of the i* framework: an ex-

perimental evaluation. in Giorgini P., Maiden N., My-

lopoulos J., Eric Yu editors, Social Modeling for Re-

quirements Engineering, in Cooperative Information

Systems series, MIT Press.

Wautelet, Y. (2009). Development of a multi-actor e-

collaboration platform: Final report (business work

unit 3, tasks 3.4.1 and 3.4.2). Waloon Region

TransLogisTIC Report Version 2.0, Center for Excel-

lence in Supply Chain Management, Louvain School

of Management, Universit

e catholique de Louvain.

Wautelet, Y., Achbany, Y., and Kolp, M. (2008). A service-

oriented framework for mas modeling. In Cordeiro, J.

and Filipe, J., editors, ICEIS (3-1), pages 120–128.

Yu, E. (1995). Modeling strategic relationships for process

reengineering. PhD thesis, University of Toronto, De-

partment of Computer Science, Canada.

ICEIS 2010 - 12th International Conference on Enterprise Information Systems

220