=Paper=
{{Paper
|id=Vol-484/paper-8
|storemode=property
|title=WebComposition/EMS: A Value-Driven Approach to Evolution
|pdfUrl=https://ceur-ws.org/Vol-484/paper8.pdf
|volume=Vol-484
}}
==WebComposition/EMS: A Value-Driven Approach to Evolution==
https://ceur-ws.org/Vol-484/paper8.pdf
WebComposition/EMS:
A Value-Driven Approach to Evolution
1 2
Stefan Wild , Martin Gaedke
1, 2
Chemnitz University of Technology
09111 Chemnitz, Germany
1 2
swild83@gmail.com, martin.gaedke@cs.tu-chemnitz.de
Abstract. The evolution of Web applications is the continuous process of
maintaining available and developing new functionalities. Already implemented
functionalities are provided by the units of the distributed Web system, i.e. its
components and services, which have to be maintained to assure a stable
operation. Furthermore, to react on upcoming needs existing units are adapted
or new ones are developed and integrated. Depending on the unit of evolution,
more or less efforts are invested. Alas, the benefit caused by units evolved
becomes only apparent after some time and usually solely with regard to the
entire product. However, the values of units of evolution are subject to change
during their life cycles because they are influenced by several parameters like
audience acceptance, development and maintenance costs. That is, before a
positive or negative impact on the product revenue can really be perceived, the
values of Web application services and components already underlie changes.
So, it would be profitable to take notice of such value alternations to be able to
anticipate revenue tendencies as early as possible and consequently to initiate
appropriate actions on time.
Keywords: evolution, portfolio management, maintenance, agile development,
components, services
1 Introduction
Today's modern Web applications are compositions of components and services that
are responsible for providing various functionalities [1]. Once a Web application has
been deployed it is in global competition with other worldwide available products that
offer similar functionalities. To keep up with competitors, existing functionalities are
maintained and promising functionalities are added to the distributed Web system
during its life cycle. The units of a Web application, i.e. its components and services,
are adapted or created to react on new user needs and enhanced technologies [2]. A
Web application and hence its units are evolved to fulfill changing and emerging re-
quirements on content, user experience, and infrastructure while ensuring that the ac-
ceptance remains constant or increases.
However, it is a complex business to perform the evolution of a Web application.
The evolution is very difficult, error-prone, and expensive as maintenance and new
design decisions have to be drawn in an agile manner. Due to the limited time frame
for introducing new functionalities and accordingly having a lead over the competi-
tors, the evolution of a Web application must always be driven in the right direction.
This direction might change frequently through various influences, like the market or
additional user expectations. On the other hand, the effects of actions during the evo-
lution of a Web application often become obvious too late and are too general. Only
after some time, the consequences of an evolution, i.e. its success indicators, are re-
flected in the profit or loss of a product. Unfortunately, these indicators are solely re-
lated to the Web application at all and not apportioned to each of its units. Thus, it is
hard to distinguish valuable from loss-generating units. As a result of that, further in-
vestments of resources are not made on a sound basis.
In this paper, we introduce WebComposition/EMS, which is a value-driven ap-
proach to evolution addressing these problems with concepts borrowed from portfolio
management. This agile approach continuously monitors each component and service
of a Web application and records each such unit's values of the composition over
time. As such, maintenance decisions can be supported by visualizing the history of
past values of components or services or even the Web application's overall composi-
tion. By applying techniques from finance mathematics it might also be possible to
estimate trends towards positive or negative tendencies of the Web application.
In the following section the process of managing the portfolio is described. The
elements managed in the portfolio of a Web application, i.e. the units of evolution, are
discussed in Section 3. Finally, in Section 4, our idea is summarized and an outlook
on further research in the topic “WebComposition/EMS” is given.
2 Treating Web applications as Portfolios
A Web application is a superset of all its units which, in turn, are supersets of the de-
mands they fulfill. By regarding the functionality being provided by such a unit simi-
lar to a stock, a value could be assigned to it. This value is limited to a specific point
in time, i.e. it is time-dependent. Therefore, the values of units can be seen similar to
stock prices. When adopting this picture to the entire Web application, a Web applica-
tion's value could be determined as the sum of the values of its units. In the life cycle
of a distributed Web system, this value would rise or fall depending on the progres-
sion of the values of all its units. Many stocks of different types might be hosted and
managed under one product umbrella. So, the entire application could be imagined as
a stock portfolio, a portfolio of units which make certain functionalities available.
A portfolio is defined in business as a collection of assets and investments all
owned by the same individual or organization [3][4]. When a Web application is re-
garded as a portfolio, its assets – the stocks – are its functionalities. To manage the
portfolio by analyzing, selecting, monitoring, and measuring the performance of as-
sets that have been placed together, we have at first to find out what investments are
currently available [5]. Applying this management aspect to our case, then we have to
investigate which components and services are provided by a Web application.
Functionalities have been realized to fulfill certain demands. These requirements
and expectations are formulated as user stories. By examining all user stories, all
demands, and, therefore, all functionalities can be identified. Usually, the services and
components of a Web application accommodate these functionalities and make them
available through well-defined interfaces. In our context we call such providers of
functionality units. To simplify further consideration, we assume that only one
functionality is provided per unit. That is, the portfolio is composed of various units
representing all available functionalities. To evaluate the quality of the evolution of a
distributed Web system, the portfolio and consequently all its units have to be
analyzed.
Performing a quantifiable analysis requires the specification of a measure. There-
fore, a time-limited value is assigned to the portfolio and to all its units. The value of
a portfolio )ݐ(can be calculated by summing the values of its units of evolution
ݑ ( )ݐas shown in (1).
= )ݐ( ݑ ()ݐ (1)
ୀଵ
Since the fundamental idea of portfolio management is to maximize the group's
return, given a certain level of risk, )ݐ(has to remain constant or grow in the course
of time [5]. The same would be optimal for each unit's value ݑ ()ݐ, but this is rather
uncommon. In contrast to it, after the introduction of units – their initial public offer-
ing – trends, unbalances, and flows between them might now be recognized and can
be analyzed. Raw indications about conflicts between units in form of value
movements are perceivable already at the portfolio level. In this manner, the non-
beneficial units or units that bar the way for new ones can be identified. The success
of newly integrated functionality becomes measurable and comparable.
Resulting from the ongoing analysis of the units of evolution, management conse-
quences on the collection of assets within the portfolio can be drawn. Decisions on the
evolution of a Web application will be value-driven, i.e. if a unit is not valuable in
various aspects, e.g. usage, need, etc., the investments into it will be reduced or
stopped entirely, whereas a beneficial or promising one will be supported and fi-
nanced further. Management actions will refine the distribution of units within the
portfolio to ensure that it is well-positioned. However, to be able to perform such
management decisions we need to determine the values of the units of evolution.
3 Units of Evolution
After all units of evolution have been identified and are managed in the portfolio on
the basis of a value assigned to them, we describe in this section how such a value
)ݐ(ݑis determined. The value of a unit can be seen as the result of an abstract
function ݂. Parameters of that function are time-dependent values for each dimension
of a unit ݀ . This means that the function's result is the value of a time-dependent
point within an n-dimensional space spanned by vector ܦ ሬԦ as shown in (2). The point
will be motion during the evolution of a unit, because of variations within the
dimensions. Thus, the calculation result and hence the value assigned to a unit will
change, too. Taking the picture on stocks again, the value alternations of units of
evolution can be considered as exchange rate fluctuations. In this way trends become
visible. But, to get the result of the function we need to know which dimensions have
to be regarded.
ሬԦ, ݐ൯ ܦ
݂ = )ݐ(ݑ൫ܦ ሬԦ = (݀ଵ , … , ݀ ) (2)
A unit can be described by various attributes, like expensive or seldom used. Most
of them are able to be grouped, so that a couple of disjoint sets of attributes can be
created. Sets of attributes, which have a direct influence on the value of a unit act as
dimensions ݀ . So far we have identified these dimensions which have an effect on
maintenance and development decisions:
• Need. The number and weight of demands that result from user, environmental,
and operational influences. The weight could be expressed in terms like “must
have”, “nice to have”, etc.
• Dependency. Functionalities provided by other services or components a unit
depends on. These components or services might be present in the same Web
application, but they could also be available in another.
• Size. The extent of a unit.
• Usage. The frequency and duration of the use of a unit which is directly provided
by a Web application or integrated from other sources as done in mashups.
• Resource Investment. How much time and man power are spent to maintain a
service or component and to develop it further.
• Risk. The risk of failure during evolution of a unit, which depends on whether a
unit is present in the Web application itself or provided externally.
• Maintainability. Grade of ease to service a unit. Functionalities of externally
available units have not to be maintained, but their interfaces.
• Extensibility. Simplicity to extent a unit by certain functions.
• Reliability. Number of issues emerged within a specific period of time.
Although these dimensions are disjoint, they might have a cause-effect-relation-
ship between each other, e.g. if the need of a unit grows its usage might increase, too.
A lot of additional aspects could be derived from a unit's dimensions immediately and
when regarding the values of dimensions of related units, e.g. the complexity, impor-
tance, and overall costs of a unit. By setting values of particular dimensions or aspects
of a unit in relation to other components and services a fine-grained comparison and
analysis could be performed. In this way, dimension- and aspect-specific statements
can be made about units of evolution.
For such an analysis a couple of variables have to be present. To get the values of
each dimension they have to be retrieved from reliable sources. In some cases these
sources might not be directly accessible, e.g. risk or reliability data. As a conse-
quence, some measurements have to be performed. Due to the fact that the dimen-
sions are different more than one measurement method is required, e.g. for usage and
dependency. Unfortunately, the requirements to perform successful measurements of
dimensions are not fulfilled in all cases. That is, for instance, to perform a usage mea-
surement a special infrastructure for data capturing and recording must be provided.
After all relevant target variables have been captured; they can be used as input
parameters of ݂ to determine the general value of a unit. Within this function weights
have to be assigned to each dimension and relationships between dimensions have to
be mapped. The result of the function should deliver a quantifiable indication of the
unit's value with regard to other units within the composition of a Web application.
4 Summary and Outlook
An agile approach to drive the evolution of a Web application through managing it as
a portfolio of its services and components has been presented. By assigning values to
each of them by means of an abstract function over their dimensions, we were able to
distinguish profitable units from unprofitable ones. With a continuous analysis of the
entire portfolio we could verify whether or not the current distribution of its units and
the resources allocated to them for their evolution make economic sense. If necessary,
we would be in the position to adjust resource investments immediately.
There is a big need for further research to substantiate this approach and prove it
in practice. Therefore, an evolution management system – EMS – is currently realized
as part of the WebComposition approach. The suitability of methods and formulas of
the portfolio management on the topic of Web engineering will be tested to verify the
WebComposition/EMS approach. In this context, further investigations are directed to
get an impression on what units are present and how to determine their precise value
and hence the value of the entire application. Techniques to measure the value of each
unit's dimension will be assessed, applied and possibly developed.
References
1. Gaedke, M., Turowski, K.: Specification of Components Based on the WebComposition
Component Model, IRMA International Conference, Toronto (2001)
2. Gaedke, M., Gräf, G.: Development and Evolution of Web-Applications using the
WebComposition Process Model. pp. 9--10. WWW9-WebE, Amsterdam (2000)
3. InvestorWords: Portfolio Definition, http://www.investorwords.com/3741/portfolio.html
4. Krebs, J.: Agile Portfolio Management, pp. 61--62. Microsoft Press, Redmond (2009)
5. CreditQuest: Portfolio Management, http://www.creditquest.com/harland-commercial-
lending-resource-library/operation-risk-default-probability-harland