A Framework for Evaluating Alternative Architectures and its Application toFinancial Business Processes

Feras T. Dabous and Fethi A. RabhiSchool of Information Systems Technology and Management

The University of New South Wales, Sydney NSW 2052 Australiaf.dabous,f.rabhi@unsw.edu.au

Abstract

Architectural design is a vital phase in the developmentof e-business applications. A suitable compromise mustbe determined taking into account business requirements,quality criteria and existing constraints (e.g. presence oflegacy systems). This paper adopts the view that for a par-ticular problem context, it is possible to consider the archi-tectural design activity as consisting of a series of choicesmade regarding a number of architectural design strategies.To make this feasible, we are focusing on problems withina restricted context. The problem context described in thepaper is very common for a category of e-business appli-cations that arise from the e-finance domain. We identify anumber of design strategies for such a problem context andshow the resulting architectures. We also present a designprocess modelled as a decision tree and show how qualitymodels can be used to select the most appropriate architec-ture. The recommendations made by the models are checkedagainst real data from existing projects.

1. Introduction

Over recent years, there has been a dramatic increase ina new class of distributed applications, called e-businessapplications, that support the needs of business communi-ties over the Web. Examples of application domains in-clude electronic banking and payment systems, sales and re-tail, supply chain management and electronic markets. De-spite the existence of different methodologies such as for-mal, structured, and object-oriented methodologies, exist-ing approaches have been caught unprepared for address-ing the needs of e-business applications, particularly in: (1)dealing with multiple development teams, possibly workingover different time periods, (2) allowing the reuse of exist-ing assets like legacy systems and databases or integratingoff-the-shelf software components, and (3) providing guid-

ance for satisfying non-functional requirements like perfor-mance, security and fault-tolerance.

This has led to a situation where architectural design fore-business applications has become a ‘black art’ with nospecific rules or guidance as to how to conduct it. Thispaper argues that the design activity could be made moresystematic by learning from real-life situations. It is oftenthe case that the same design process is applied in a well-identified problem context which is often related to specificapplication domains such as e-health and e-finance. Thispaper explores this idea further by identifying a problemcontext and providing a formal description of such a contextin Section 2. In other words, the context defines the input ofthe design process. This section also describes a commonarchitecture description notation that represents the outputof the design process. Section 3 discusses a number of de-sign strategies each of which corresponds to an alternativeto a design decision. Each strategy can be considered as astep in determining the target architecture. Section 4 de-fines a design process that is modelled as a design decisiontree. The decisions along each path of the tree determinean architecture from the original problem context. To helpusers choose the optimal solution, architectures are rankedaccording to the non-functional requirements.

Section 5 discusses a case study where the recommendedarchitectures have been compared with those selected in anumber of real-projects. Finally, Section 6 concludes thispaper.

2. Basic Assumptions and Notations Used

2.1. Problem Context

The problem context considered in this paper is far frombeing an accurate representation of reality. Its purpose isonly to give some idea on the number and type of busi-ness processes in the area of interest, the legacy systemsin use and the most important non-functional requirements

for stakeholders. The models used here are pragmatic innature and have been based on several architectural analysisand benchmarking studies conducted on a number of legacysystems. We define three important concepts1:

• functionality: corresponds to an activity within a busi-ness process that performs a specific job (i.e. it is partof the business logic). We use the notion F all = {fi :1 ≤ i ≤ |F all|} to represent the set of all functionali-ties that belong to a particular domain. The definitionof the set F all does not tell anything about the imple-mentation of any functionality.

• equivalent functionalities: refers to a group of func-tionalities that have similar business logic. Our as-sumption here is that we cannot have two exact im-plementations of the same functionalities. Two “sim-ilar” implementations usually implement two equiva-lent (yet slightly different) functionalities. We use thenotion Q = {qi : 1 ≤ i ≤ |Q|} to represent theset of all groups of equivalent functionalities. Eachqi ⊂ F all is the ıth set of a number of equivalent func-tionalities such that |qi| ≥ 1 and qa ∩ qb = φ : a �= b

and⋃|Q|

i=1 qi = F all.

• business process (BP): describes the requirements ofan e-business application in terms of the activity flowof its constituent functionalities. An activity diagramis associated with every bpi where the nodes repre-sent functionalities and the arcs determine the execu-tion flow across the functionalities. We use the setBP = {bpi : 1 ≤ i ≤ |BP |} to represent all BPs andthe function activities(bpi) ⊆ F all to identify the setof functionalities that are required by a bp i (i.e. it re-turns the set of all nodes in a bpi’s activity diagram).We also assume that every f ∈ F all has at least onecorresponding bpi ∈ BP such that f ∈ activities(bpi).In other words,

�|BP |i=1 activities(bpi) = F all.

• legacy system: refers to an existing architectural com-ponent that supports the implementation of a numberof functionalities. We asume that the design team hasnot played a role in the development of the legacy sys-tems and therefore has no access rights to the sourcecode. Interaction with a legacy system can only beachieved through their defined interfaces. We use thenotation F au ⊆ F all to represent functionalities con-tained in all legacy systems and LG = {li : 1 ≤ i ≤|LG|} as the set of legacy systems identified in thatparticular domain. Every li ⊂ F au and la ∩ lb = φ

when a �= b. There is no instance of two equivalentfunctionalities within the same legacy system meaningthat if fx, fy ∈ li then {fx, fy} � qk∀qk ∈ Q.

1these concepts may be defined differently elsewhere but for the sakeof consistency, we provide our definitions here

• access method: refers to the way an architectural com-ponent is being accessed. All access methods belongto a set AC and are ranked according to different ab-straction levels. By definition, using a low-level accessmethod is faster than using a high-level access method.In contrast, the development time of a client program islikely to take much more time in the case of a low-levelaccess method than in the case of a high-level accessmethod.

In [8], we define the following 4 classes of access meth-ods:

• AC1: includes communication at the network protocollevel such as using TCP/IP packets.

• AC2: includes the use of facilities offered by the oper-ating system(s) and Remote Procedure Calls (RPCs)

• AC3: includes the use of distributed object technologyinterfaces such as CORBA IDL and Java RMI.

• AC4: includes the use of service-oriented standardssuch as Web Service standards.

Therefore, a problem context is defined as a tuplecontext denoted by < F au, F all, Q, LG, BP >. Figure 1presents a simplified example that illustrates the problemcontext will be utilized in the next section.

Fall

Fau

f7

f5f1

q1

f6

f3

q2

LG

f4q4

f9q5

q3

f8

f2 f10

L1

f2

f4

f1

f3

L2

f5 f6

L3

f7 f8

Legend :Fall=set of functionalitiesFau= set of automated (i.e.legacy) functionaliesQ= set of equiv functionalitiesLG=set of legacy systemsBP=set of business processes

BPbp1

bp2

bp3 f7 f2 f3

f5f1

f2 f5

f4

bp4

bp5

f1 f2 f7

bp6 f8f7 f1f6

f5 f8 f7

f9

f9 f10

Supports am1access method

Supports am2access method

Supports am3access method

Figure 1. Example of a problem context spec-ification

2.2. Target architecture description

The purpose of the common architecture notation is toembody design decisions being made and facilitate the de-velopment of models that estimate the architecture’s impact

on the non-functional requirements. In this notation, an ar-chitecture is described in terms of a set of distributed com-ponents Comp = {Xi : 1 ≤ i ≤ |Comp|}. A componentXi ∈ Comp is described according to four essential fea-tures: (1) the ‘tasks’ that are supported by the component,(2) the set of components accessed by this component, (3)the set of components that access this component, and (4)the method by which each component is accessed. There-fore, we can describe each entry Xi ∈ Comp by the tuple< tasks(Xi), conTo(Xi), invBy(Xi), access(Xi) > where:

1. tasks(Xi): is a function that identifies the set of tasksthat are supported by the component X i. Each task canbe one of three types.

• The first one is the implementation of a func-tionality f ∈ F all that is denoted by C(f) andis used in three different cases. The first one iswhen f ∈ F au refers to an existing functionalitywithin a legacy system. The second one is whenf ∈ F au refers to redeveloping (i.e. reengineer-ing) an existing functionality. The third one iswhen f ∈ (F all − F au) i.e f is a new function-ality that is not implemented in any of the legacysystems.

• The second type of tasks correspond to the im-plementation of a wrapper for a functionality f ,denoted by CW (f). It is used when Xi masks outthe actual component that embeds C(f) using ahigher level access method.

• The third type of tasks correspond to implement-ing the logic of a business process bp, denoted byCBL(bp). We will use the term ‘business processenactment’ to refer to the implementation code ofthe business logic.

Therefore, each task corresponds to implementationcode resulting from applying one of the task construc-tors C, CW , or CBL on its parameters.

2. conTo(Xi) ⊂ Comp: is a function that returns theset of components that Xi invokes while executing itstasks.

3. invBy(Xi) ⊂ Comp: is a function that returns theset of components that invoke Xi while executing theirtasks.

4. access(Xi): a function that returns the accessmethod used by the component X i. Meaning thataccessType(access(Xi)) ∈ AC (see section 2.1)

For simplicity, we refer to an architecture XLG as theone in which every legacy system is represented as a com-ponent. This architecture is constructed using the followingalgorithm:

ConstructXLG (LG)• For each lx ∈ LG Do:

– Xx = createNew(); /* creates and initialised a new compo-nent*/

– access(Xx) = legacyAccess(lx); /* see section 2.1*/

– tasks(Xx) = {C(fk) : fk ∈ lx};

– XLG = XLG ∪ {Xx} /* add Xx to XLG */

Where the createNew() function invocation creates anew component Xx and initialises its four features to nil(i.e. access()= tasks()= conTo()= invBy()= nil). The setXLG still represents an incomplete architecture as othertasks (such as those for BPs enactment) have not yet beencreated.

3. Design strategies

Given a problem context, the design process starts froman empty architecture. Then, each design strategy incre-ments the current architecture Comp with a new set of tasksand components. This is repeated until an architecture thatimplements all BPs is constructed. Before we discuss theentire process, we present five simple design strategies thatare particularly suited to the problem context. Each strategyis first informally described then defined by its algorithmthat is based on the common architectural notation. Morecomplex design strategies are presented in [8].

3.1. Reuse

This design strategy emphasises on the importance ofleveraging the functionalities embedded in existing legacysystems and allowing them to be shared across BPs. It sim-ply creates |LG| entries in Comp which correspond to theset XLG ⊂ Comp defined in section 2.2. Its impact on theprevious example is illustrated in figure 2. The correspond-ing algorithm is:

Reuse()• For each Xi ∈ XLGXi ∈ XLGXi ∈ XLG:

– Comp = Comp ∪ {Xi}

3.2. Automate

This design strategy creates |F all − F au| componentseach of which supports a single new functionality (i.e. re-quired functionality that does not exist in any of existinglegacy systems). This strategy suggests that all new compo-nents provide a unified access method for these new func-tionalities (typically a high-level access method). This ac-cess method is given as a parameters to the strategy. Its im-pact on the previous example is illustrated in figure 3. Thecorresponding algorithm is:

Automate(am) /*am is the access method used by the new components */

XL

G

(null)

Other components inComp from otherdesign strategies

PossibleinvBy() links

Comp

access()= cm 3

tasks()

C(F8)

C(F7)

access()= cm 2

tasks()

C(F6)

C(F5)

access()= cm1

tasks() C(F1)

C(F4)C(F3)

C(F2)

Figure 2. ‘Reuse’ design strategy illustration

cm n

vC(F9)

cm n

C(F10)

Other components inComp from otherdesign strategies

PossibleinvBy() links

Comp

Figure 3. ‘Automate’ design strategy illustra-tion

1. For each fk ∈ (F all − F au)fk ∈ (F all − F au)fk ∈ (F all − F au):

• Xx = createNew ();

• access(Xx) = am;

• tasks(Xx) = {C(fk)};

• Comp = Comp ∪ {Xx};

3.3. Wrap

Remotely accessing the functionalities of legacy systemsis not simple and requires significant programming effortsince most of such systems provide low-level access typemethods. The wrapping concept is normally used to pro-vide a higher-level method for remotely accessing legacyfunctionalities.

This design strategy creates a total of |F au| new com-ponents in Comp, each of which corresponds to a wrappercomponent. This wrapper redirects all calls from compo-nent’s interface (high-level) to the legacy system’s interface(low-level). Its impact on the previous example is illustratedin figure 4. The corresponding algorithm is:

cmn

z vCW(F1)

cmn

vCW(F2)

cmn

vCW(F3)

cmn

vCW(F4)

cmn

vCW(F5)

cmn

vCW(F6)

cmn

vCW(F7)

cmn

vCW(F8)

Other components inComp from otherdesign strategies

PossibleinvBy() links

Comp

Other components inComp that

corresponds to XLG

Figure 4. ‘Wrap’ design strategy illustration

Wrap (am)1. For each Xi ∈ XLG such that Xi ∈ CompXi ∈ XLG such that Xi ∈ CompXi ∈ XLG such that Xi ∈ Comp do:

• For each C(fk) ∈ tasks(Xi):

– Xx = createNew();

– access(Xx) = am;

– tasks(Xx) = {CW (fk)};

– invBy(Xi) = Xx

– conTo(Xx) = Xi

– Comp = Comp ∪ {Xx}

3.4. Migrate

In cases when existing legacy systems are expected to bediscarded in the near future, the corresponding functionali-ties can be redeveloped from scratch in a process that we re-fer to as ‘migration’. There are different possibilities of re-arranging the redeveloped functionalities into new compo-nents. This design strategy implements one possible migra-tion technique that treats all functionalities equally whetherthey are legacy or new functionalities. It groups each setof equivalent functionalities q ∈ Q in one component. Eachnew component contains a task C(fk) for each fk ∈ q. Thisdesign strategy also uses a uniform access method across allnew components (typically a high-level access method). Itsimpact on the previous example is illustrated in figure 5.The corresponding algorithm is:

Migrate(am)1. For each qi ∈ Qqi ∈ Qqi ∈ Q:

• Xx = createNew ();

• access(Xx) =am;

• tasks(Xx) = {C(fk) : fk ∈ qi};

• Comp = Comp ∪ {Xx}

3.5. MinCoordinate

All previous strategies only deal with how to implementfunctionalities. This one is specifically about enacting BPs.

2

cmn

C(F6)C(F3)

cmn

C(F2)

C(F10)C(F8)

cmn

C(F9)

cmn

C(F4)

2 2

cm n

C(F1)

C(F7)C(F5)

Other components inComp from otherdesign strategies

PossibleinvBy() links

Comp

Figure 5. ‘Migrate’ design strategy illustration

It works in situations where BPs of interest are unrelatedand do not interact with each other. The Minimum Coor-dinate (MinCoordinate) design strategy gives the responsi-bility for the enactment of every bp ∈ BP to a dedicatedcomponent X . For every functionality required in the BP,there are two cases. The first case is when the functionalityis already supported by another existing component Y . Inthis case, a link is created between the components X andY . The second case is when the functionality is not im-plemented by the other components of the architecture. Inthis case, a local task will be created on X to support thatfunctionality (hence the word ”Minimum” which means thestrategy only creates one new component).

Its impact on this strategy on the previous example isillustrated in figure 6. The corresponding algorithm is:

MinCoordinate()1. Let BpComp =φ /* An empty set of same type as Comp*/

2. For each bpj ∈ BPbpj ∈ BPbpj ∈ BP :

(a) Xx = createNew ();

(b) tasks(Xx) = {CBL(bpj)};

(c) For every fk ∈ activities(bpj ) DO:

• IF (∃Xi ∈ Comp : /* When fk already exists */(CBL(q) ∈ tasks(Xi), fk ∈ q) /*fk is part of aq ∈ Q*/or (CW (fk) ∈ tasks(Xi)) /*fk has a wrapper andnot in a q ∈ Q*/(C(fk) ∈ tasks(Xi)) /* fk already exists with nowrapper and not part of a q ∈ Q */

– conTo(Xx) = conTo(Xx) ∪ {Xi};

– invBy(Xi) = invBy(Xi) ∪ {Xx};

– BpComp = BpComp ∪ {Xx};

• ELSE tasks(Xx) = tasks(Xx) ∪ {C(fk)}; /*de-velop local copy of fk*/

3. Comp = Comp ∪ BpComp;

4. Design process

Each of the design strategies considered earlier can beregarded as the outcome of an architectural design decision.

Other components inComp from otherdesign strategies

nil

CBL(BP6)

PossibleC() tasks

nil

CBL(BP5)

PossibleC() tasks

nil

CBL(BP4)

PossibleC() tasks

nil

CBL(BP3)

PossibleC() tasks

nil

CBL(BP2)

PossibleC() tasks

nil

CBL(BP1)

PossibleC() tasks

PossibleconTo() links

Comp

Figure 6. ‘MinCoordinate’ design strategy il-lustration

Table 1. Design decisions and alternatives vs.design strategies

AlternativesDesign decisions 1st alternative 2nd alternativeDD1 Use ‘Reuse’ Use ‘Migrate’DD2 Use ‘Wrap’ Do not use ‘Wrap’DD3 Use ‘Automate’ Do not use ‘Automate’DD4 Use ‘MinCoordinate’

Design decisions include whether to reuse or discard ex-isting legacy functionality, whether to wrap existing legacyfunctionality or leave it as it is, implementing new function-alities using separate components or embedding them withthe component that implements BPs enactment etc. Table 1summarises the four design decisions and the correspondingalternatives that have been considered so far.

The table shows that each of DD1, DD2, and DD3 hastwo alternative designs (two different design strategies inDD1, and using/not using a design strategy in both DD2 andDD3). On the other hand, DD4 has only one alternative.

We are now in a position to show the corresponding de-cision tree in Figure 7. This tree shows eight paths whichrepresent all possible architectures that can be constructedas a combination of the four design decisions. Five of thesegenerated paths which are marked as Pt1-Pt5 correspondto architectures that are often found in practice. The otherthree paths correspond to architectural descriptions that areeither meaningless or incomplete.

Since possible architectures can now be systematicallyidentified, non-functional requirements (part of the prob-lem context) will play a key role in evaluating architecturesand selecting the optimal one. In the case study presentedin the next section, we have selected three important non-functional requirements that play an important role in manyreal-life projects and for which various trade-offs exist:

• low development cost: this requirement originates

Reuse Migrate

~Wrap WrapWrap

MinC.

Automat ~Automat Automat Automat ~Automat Automat

MinC. MinC. MinC. MinC. MinC. MinC. MinC.

DD1

DD2

DD3

DD4

Pt3 Pt5Pt1Pt2Pt4

~Automat ~Automat

~Wrap

Figure 7. Architectural alternatives identifica-tion illustrated by decision tree

from business stakeholders, for which such cost is acritical feature if they are to maintain project withinthe budget and time frame. The development effortestimation in Person Months (PM) is critical in deter-mining the number of developers that are required andtherefore more accurate estimation of time to market.This important to maintain some competitive advan-tage, exploit some market opportunity etc.

• low maintenance costs: this requirement is usuallymandated by technical staff, as they would have to bearthe brunt of maintaining the system.

• high performance: many business processes requireefficient implementations to maintain an adequate re-sponse time, process high volumes of data etc.

Quantitative models, that estimate the appropriateness ofa solution in relation to every requirement, can be devel-oped. In this paper, we will be using the models describedin [8, 10] which can be applied to an architecture decribed inour notation. For example, determining development costswill take into account the development of functionalities(affected by the reuse of legacy systems) and wrapper com-ponents. Once these models have been developed, searchfor a solution can be systematically conducted as describedin [1].

5. Validation

The proposed design process is a pragmatic one. It is in-tended to be useful in practice by giving some guidance tothe designers about the various trade-offs involved. How-ever, it is reliant on the ability to describe a problem con-text, architectures and quality models in a reasonably accu-rate way. This is why it is important to conduct a validationexercise of the proposed approach on a real-life case study.

In this section, we first describe the application domainand the resulting problem context expressed in our notation.Then we describe three real projects and compare the archi-

tecture recommended by our approach with the one that wasactually selected.

5.1. Application domain

The selected application domain is in the area of e-finance. We focus on capital markets which are placeswhere financial instruments such as equities, options andfutures are traded [12]. Trading in capital markets com-prises a cycle of a number of phases which are: pre-tradeanalytics, trading, post-trade analytics, settlement and reg-istry. At each phase of this cycle, one or more legacy sys-tems may be involved. Therefore, a large number of BPsthat span through different stages of the trading cycle ex-ist within this domain. The implementation of these BPs ischallenging for many of the reasons outlined in our problemcontext (e.g. legacy systems are owned by different compa-nies and can only be accessed through a low-level accessmethod).

f1:TeSim1

FA

TE

f3:RealTimeSim1

f2 :CurrDaySim1

XS

TR

EA

M

f10 :Realtime3

f11 :TE3

f9:CurrDay3

AU

DIT

f12 :VisualModel4

SM

AR

TS

f4:CalibRun2

f5:RealTimeAlerts2

f6 :IntraDay2

f7 :InterDay2

f8:Analytic2

LG FallFau Q1

f6

f9

f2

Q2

f3

f10

Q3

f1

f1

Q5

f7

Q6

f4Q7

f12

Q8

f5

Q12

f14 :Regulator

Q11

f16 :StrategyCnrl

Q10

f17 :OrderExeMgtQ9

f15 :MktEventDetect

Q4f8

f13 :BAnalytic

BP

Pro

ject

AP

roje

ct C

Pro

ject

B

Activities(bp4) f17f16f15

Activities(bp3) f14f4f5

Activities(bp2)

f12 f8

f9f6

Activities(bp1) f6

f8f13f2f9

f7

Activities(bp5) f3 f1

f17f16f15

f10

f11

Figure 8. Case study context specification

We have provided a visual representation of our problemcontext in figure 8. We focus on four legacy systems thathave been customised around Australian Stock Exchange(ASX) practices. These systems are FATE [11], SMARTS[16], XSTREAM [7], and AUDIT Explorer [15]. The func-tionalities supported by each system (i.e. those relevant tothe BPs in this problem context) are illustrated in the leftpart of the figure. some of which have been reported in[20, 9].

There are five BPs of interest in this paper for which cor-responding activity diagrams are shown in figure 9 (addi-tional details and activity diagrams can be found in [8]):

BP1 (ASX trading data processing) is related toanalysing market-related data and generating somemetrics that can be used by market analysts. Thedata can be related to historic trading activities onthe ASX over a single day (intra-day data) or over along period (inter-day data). It could also come froman ASX market simulator when experimenting withhypothetical situations.

IntraDay2 CurrDay3

Analytics2

VisualModel

BP2: Visualization

Today in DaysMkt=asxMkt=asx

Old in Days

BP

5:

Tra

de

Str

ate

gy

ex

ec

tio

n

MktEventDetect

Event detected

StrategyCtrl

Ctrl msg

OrderExcMgt

RealTimeSim1 RealTime3

Subscriberevent triggered

Subscriberevent triggered

TE3

Orderpalcement

Eve

nt=

tra

de

else

Mkt= ASX-sim Mkt= ASX

Mkt= ASX-sim Mkt= ASX

TeSim1

CurrDay3InterDay2 IntraDay2

Mkt

=si

m-A

SX

Analytics2BAnalytics

Me

tric

s=

sm

art

s

Me

tric

s=

Be

ta

BP1: ASX Trading Data Processing

Mkt

=rA

SX

Old in Days

CurrDaySim1

Today in Days

BP3: Surveillance

CalibRun2

RealTimeAlerts2

Regulator

Alert raised

BP

4:

Tra

de

Str

ate

gy

form

ali

sa

tio

n

MktEventDetect

Event detected

StrategyCtrl

Ctrl msg

OrderExcMgt

Eve

nt=

tra

de

els

e

Figure 9. Activity diagrams for 5 BPs

BP2 (Visualisation of ASX trading data) is related topre-processing of ASX market data to be used by anumber of visualisation modules.

BP3 (Reporting surveillance alerts) is related to listeningfor a specific type of real-time market events (calledsurveillance alerts). Once an alert is detected, a marketanalyst performs a calibration run to verify the serious-ness of the alert, then possibly reporting the alert to theregulatory authorities.

BP4 (Trade strategy simulation) is related to analysing asimulated market and searching for a specific type ofmarket events (called trading opportunity alerts). Oncesuch an event is detected, it is analysed possibly result-ing in some action being taken on the simulated marketto take advantage of the trading opportunity. This BPis usually followed by an evaluation of the simulatedtrading strategy (by looking at the overall profit madefor example).

BP5 (Trade strategy execution) is an extension of BP4which deals not only with a simulated market but alsoa real one. In the latter case, trading opportunity alertshave to be detected and acted upon in real-time.

Next, we describe three real projects (denoted with theletter A, B and C), each of which resulted in the selectionof an architecture that implements one (or several) of theseBPs. These projects were conducted in the 2001-2004 pe-riod and funded by the Capital Markets Cooperative Re-search Centre (CMCRC) in Australia [6] as part of an in-vestigation into the interoperability of financial informationsystems.

5.2. Project A: trade data processing andsurveillance

This project was specifically aiming at the implementa-tion of BP1 and BP3. The major non-functional require-ment of concern in this project was reducing the mainte-nance effort. The development team for this project adoptedthe architecture Pt4 (see Figure 7) to guide the architecturaldesign. A product has been delivered based on this proposal(see [11]).

The upper part in Figure 10 presents the results of thethree quality models applied to the five possible architec-tures that can be derived this project’s problem context.When considering reducing the maintenance effort as themajor quality attribute of concern (top middle pie), then Pt5has the best estimate (i.e. the highest rank) generated bythe maintenance effort model followed by equal estimatesfor Pt3 and Pt4 then finally by similar estimates for Pt1 andPt2.

There are two important observations on the model-generated ranks. The first one is that Pt4 and Pt3 have asimilar maintenance effort because there are only two newfunctionalities in this problem context. As they are notshared by more than one BP, their maintenance effort is thesame whether they are embedded with the BP enactmentcode or implemented within independent components. Thesame argument applies when explaining why both Pt1 andPt2 have a similar maintenance effort. The second observa-tion is that Pt5 has not been selected in the actual projectbecause the focus of the project team on the maintenanceeffort is implicitly conditional on having a ‘moderately’ ac-ceptable development effort. By referring back to the topleft pie in figure 10, the development effort of Pt5 is almostthree times that of Pt4 (Pt5 is taking up 47% of the over-all total of the development effort of the five alternatives,whereas Pt4 is 16%).

5.3. Project B: trade data visualisation

This project was concerned with the implementation ofBP2. The major non-functional requirement that was ofconcern is attaining the best performance. The developmentteam for this project has used Pt1 to guide the architecturaldesign. A prototype implementation has been delivered atthe end of the project.

The middle part in Figure 10 presents the outputs of thethree quality models on the five possible architectures thatcan be generated from the problem context. When consider-ing high performance as the major non-functional require-ment of concern, architectures are ranked in this order: Pt1,Pt2, Pt3, Pt4, then Pt5. This is conformant with the projectteam selection of Pt1 to guide the architectural design ofthis project. The absence of new functionalities result in

devE(Comp) Pt135.3410.5%

Pt233.529.9%

Pt354.6516.2%

Pt454.3516.1%

Pt5159.2447.2%

maintE(Comp)Pt1

13.0122.1%

Pt213.0122.1%

Pt312.5221.3%

Pt412.5221.3%

Pt57.83

13.3%

avgLatency(BP) Pt12.801%

Pt215.90

8%

Pt361.7534%

Pt448.65

26%

Pt558.9531%

Pro

ject

A

devE(Comp)Pt1

7.305.2%

Pt27.905.7%

Pt323.5016.9%

Pt423.0116.5%

Pt577.5255.7%

maintE(Comp)Pt18.52

23.0%

Pt28.52

23.0%

Pt38.1221.9%

Pt48.12

21.9%

Pt53.8010.3%

avgLatency(BP) Pt13.201.9%

Pt23.201.9%

Pt455.6032.7%

Pt552.4030.8%

Pt355.6032.7%

Pro

ject

B

devE(Comp) Pt147.9011.1% Pt2

33.047.7%

Pt362.2914.4%

Pt460.0013.9%

Pt5228.2052.9%

maintE(Comp)Pt1

26.2223.0%

Pt225.3422.3%Pt3

25.0822.0%

Pt425.9622.8%

Pt511.249.9%

avgLatency(BP) Pt11.600.8%

Pt240.9020.2%

Pt367.1033.1%

Pt427.80

13.7%

Pt565.5032.3%

Pro

ject

C

Figure 10. Application of quality attributes models on project ‘A’, ‘B’, and ‘C’ separately

similar architectures for both Pt1 and Pt2 and similar ar-chitectures for both Pt3 and Pt4. Consequently, all qualitymodels would produce similar estimates in these two cases.

If we consider both the performance and developmenteffort with equal importance in this project, then the accu-mulated preferences for Pt1 and Pt2 are still clearly rankingfirst. To evolve the prototype into a product, the projectstakeholders have started considering reducing the mainte-nance effort as well. In this case, our approach suggeststhat migrating the current architecture into either Pt3 or Pt4would be an appropriate step forward.

5.4. Project C: trade strategy formalisationand execution

This project was concerned with the implementation ofBP4 and BP5. The major non-functional requirement thatwas of concern in this project is reducing the developmenteffort. The development team for this project has used Pt2to deliver a preliminary prototype (see [11]). The devel-opment team now believes moving to Pt3 would be moreappropriate to accommodate a number of future extensions.

The lower part in Figure 10 presents the output of thethree quality models on the five architectures resulting fromthis project’s problem context. When considering reduc-ing the development effort as the major non-functional re-quirement of concern, then the preferences generated by themodel are: Pt2, Pt1, Pt4, Pt3, then Pt5. This is conformantwith the project team original selection of Pt2.

This project also have performance constraints due tostringent real-time response time required from the event

detection functionalities (TE3 and TESim1). According toour model, the performance of Pt2 is only third in ranking.However, the prototype has shown acceptable performanceeven with Pt2 because it was used in an experimental envi-ronment only.

The development team’s plans to consider either Pt3 orPt4 is conformant with the outcome of the development ef-fort prediction model. The output of such model on the casestudy of this chapter recommends Pt4 and Pt3 as the firstand second ranking respectively.

5.5. Discussion

Table 2 summarises the three projects of concern in termof: the BPs used, the major quality criteria of concern,the actual alternative selected for each project, and finallythe rankings generated by applying our approach. In manycases, the actual alternative selection is not conformant withthe output ranks generated by the model when consider-ing the most important quality nominated by the projectteam. There are two reasons for such variations. The firstone is that the proposed quality models themselves are atthe architectural level and generate estimated values wheremany of the detailed design elements that could affect suchqualities are not considered. The other reason is that inmore realistic situations other quality attributes with dif-ferent importance in the project might affect the decisionof the project team. Furthermore, the project team oftenhave different stakeholders groups with different and oftenconflicting preferences on quality attributes. In conclusion,validation based on a single quality attribute that relies on

Table 2. Projects’ specifications and their se-lected architectural alternative

Projectprj BPprj Major quality Actual Model generatedselection ranking

Pt5, Pt3, Pt4,A {bp1, bp3} Maint. effort Pt4 Pt1, Pt2

Pt1, Pt2, Pt5,B {bp2} Performance Pt1 Pt3, Pt4

Pt2, Pt1, Pt4,C {bp4, bp5} Dev. effort Pt2 Pt3, Pt5

single group of stakeholders while isolating other quality at-tributes and stakeholders is a practical yet simple approachthat is often used in the industry. However, ignoring otherquality attributes and the different importance of each qual-ity attribute with respect to different stakeholders is a po-tential reason for a project failure.

It is also important to note that the three different projectsin the same domain have considered different architecturalalternatives. This variation on the adopted architectural ap-proaches for different projects would raise interoperationand reuse problems when integrating all solutions together.Figure 11 shows the estimations and rankings generated bythe quality models as if the three projects are single one(i.e. one alternative is used for the five BPs). Therefore,presenting the case study context specification as a com-bination of the three different projects A, B, and C showsthat it is possible to achieve a balance between conflictingrequirements such as development effort and maintenanceeffort. For example, the total estimation of the developmenteffort for the three selected alternatives of the three projectsis 54.25+23.01+60=137.36. This total is 47%, 79%, 17%,and 19% more than that as if the three projects use similararchitectural alternative of Pt1, Pt2, Pt3, or Pt4 respectively.Similarly, the total estimation of the maintenance effort is12.52+8.12+25.96 = 46.6. This total is 12%, 14%, 17%,and 14% more than that as if the three projects use similararchitectural alternative of Pt1, Pt2, Pt3, or Pt4 respectively.

In [8], we propose a model to predict the development ef-fort when having large number of BPs each of which has anaverage complexity. We examined this model on this casestudy and concluded that architectures that support a highlevel access method (Web Services in this case) enhance theoverall development effort as the number of emerging BPsincreases. This is clearly shown in the alternatives that use‘Wrap’ and/or ‘Automate’ design strategies. For example,we demonstrated than the development effort when having30 hypothetical BPs is 337.98, 338.48, 160.19, 146.81, and436.89 for the five alternatives respectively.

6. Conclusions, Related Work and FutureWork

The main purpose of this paper was to provide usefulinsights into the architectural design process of e-businessapplications. The proposed approach starts from a wellidentified problem context and incrementally constructs thedesired architecture through a number of steps, expressedas design strategies that are inspired from practice. Qual-ity models that represent non-functional requirements canbe used to direct this process towards an optimal solution.We have validated our approach through a complex real-lifecase study and demonstrated that our approach is not onlyable to confirm certain decisions that have been made butcan also be useful in making various predictions when con-sidering some ‘what if’ scenarios.

Related work includes tools that help designers in nav-igating and evaluating solutions in a design space, notablythe work reported in [5, 17]. Other related work includesseveral systematic pattern-based design approaches, no-tably the IBM patterns [4]. Few of those have been target-ing distributed applications such as [18] for Agent Systems.To our knowledge, there is no systematic design approachspecifically aimed at e-business applications from a practi-cal and pragmatic point of view.

We also expressed the reasons for having some varia-tions in the results of using single quality attribute basedvalidation. A more complex domain problem can ex-ist that including various groups of stakeholders with dif-ferent preferences on larger set of quality attributes withthe presence of large set of alternative architectures. Forsuch problems, Multiple-Attribute Decision Making meth-ods (MADM) [19] can be utilised in the systematic selectionand ranking process of the different architectural patterns inlight of the stakeholders’ quality preferences. Within thediscipline of software engineering, MADM methods havebeen successfully used by researchers to prioritize stake-holders’ requirements using AHP [13], to select among anumber of software architectural strategies using SAW [14],to evaluate COTS software using ELECTRE [3], and to se-lect among a number of software architectures using AHP[17]. Other work about evaluating design alternatives andmaking rational architectural design decision based on theBayesian Network technique [21]. In our work [8, 1], weleveraged two MADM methods that are SAW and AHPfrom the management science discipline [2].

There are many avenues for future work. The first one isextending the design strategies by considering other tech-niques for reusing legacy systems, developing wrappers,implementing BPs enactment logic etc. It is important topoint out that these techniques already exist (often in theform of architectural patterns) so the main problem is to beable to express them using the architecture notation. This

devE(Comp) Pt193.5812%

Pt276.589%

Pt3117.53

15%Pt4

115.3214%

Pt5403.7350%

maintE(Comp)

Pt141.7122.8%

Pt240.8322.3%

Pt339.9821.8%

Pt440.8622.3%

Pt519.8610.8%

avgLatency(BP)Pt12.401%

Pt223.36

12%

Pt362.6633%Pt4

41.7022%

Pt560.2632%

Figure 11. Application of quality attributes models on combined ‘A’, ‘B’, and ‘C’ projects

in turn may lead to extending the architecture notation andintroduce new quality models. This process need to be con-ducted iteratively and refined according to a validation ex-ercise involving real projects. One shortcoming of our ap-proach is that we are only dealing with simple BPs so futurework needs to refine the problem context and focus on a spe-cific type of BPs for example those found in Supply-Chain-Management. Other future work involve the provision ofcomputer-based tools for storing all knowledge relating todesign decisions and strategies and assisting users in the de-sign process.

References

[1] T. Al-Naeem, F. T. Dabous, F. A. Rabhi, and B. Benatallah.Quantitative evaluation of enterprise integration patterns. In7th International Conference on Enterprise Information Sys-tems (ICEIS’05), pages 398–402, Miami, USA, May 2005.

[2] D. R. Anderson, D. J. Sweeney, and T. A. Williams. AnIntroduction to Management Science: Quantitative Ap-proaches to Decision Making. South-Western EducationalPublishing, 2002.

[3] M. Blin and A. Tsoukis. Multi-criteria methodology contri-bution to the software quality evaluation. Software QualityJournal, 9(1), 2001.

[4] F. J. Budinsky, M. A. Finnie, J. M. Vlissides, and P. S. Yu.Automatic code generation from design patterns. IBM Sys-tem Journal, 35(2):151–171, 1996.

[5] L. Chung, B. A. Nixon, and E. Yu. Non-Functional Require-ments in Software Engineering. Kluwer Academic Publish-ing, Poston MA, 1999.

[6] Capital Market Cooperative Research Centre (CMCRC).http://www.cmcrc.com, 2005. Last accessed on Mar.

[7] X-STREAM system. http://www.computershare.com.au.[8] F. T. Dabous. Pattern-Based Approach for the Architectural

Design of e-Business Applications. Phd thesis, School of In-formation Systems, Technology and Management, The Uni-versity of New South Wales, Australia, 2005.

[9] F. T. Dabous, F. A. Rabhi, and H. Yu. Performance issues inintegrating a capital market surveillance system. In Proceed-ings of the 4th International Conference on Web Informa-tion Systems engineering (WISE’03), pages 287–290, Rome,Italy, December 2003.

[10] F. T. Dabous, F. A. Rabhi, H. Yu, and T. Al-Naeem. Esti-mating patterns consequences for the architectural design ofe-business applications. In 7th International Conference on

Enterprise Information Systems (ICEIS’05), pages 248–254,Miami, USA, May 2005.

[11] FinanceIT research group.http://www.financeit.unsw.edu.au, 2005.

[12] L. Harris. Trading and Exchanges: Market Microstructurefor Practitioners. Oxford University Press, 2003.

[13] J. Karlsson and K. Ryan. A cost-value approach for priori-tizing requirements. IEEE Software, 14(5), 1997.

[14] R. Kazman, J. Asundi, and M. Klein. Quantifying the costsand benefits of architectural decisions. In The 23rd Interna-tiona Conference on Sofware Engineering, pages 297–306.IEEE Computer Society, May 2001.

[15] SIRCA research center. http://www.sirca.com.au.[16] SMARTS surveillance system. http://www.smarts-

systems.com.[17] M. Svahnberg, C. Wohlin, L. Lundberg, and M. Mattsson. A

quality-driven decision-support method for identifying soft-ware architecture candidates. International Journal of Soft-ware Engineering and Knowledge Engineering, 13(5):547–573, 2003.

[18] M. Weiss. Pattern-driven design of agent systems: Approachand case study. In Conference on Advanced InformationSystems engineering (CAiSE), LNCS 2681, volume 2681 ofLNCS, pages 711–723. Springer, 2003.

[19] K. P. Yoon and C.-L. Hwang. Multiple attribute decisionmaking: An introduction. Saga Publications, 1995.

[20] H. Yu, F. A. Rabhi, and F. T. Dabous. An exchange ser-vice for financial markets. In Proceedings 6th InternationalConference on Enterprise Information Systems (ICEIS’04),pages 403–410, Porto, Portugal, April 2004.

[21] H. Zhang and S. Jarzabek. A bayesian network approach torational architectural design. IJSEKE, 15(4), 2005.