ANALYZING IMPACT OF INTERFACE IMPLEMENTATION

EFFORTS ON THE STRUCTURE OF A SOFTWARE MARKET

OSS/BSS Market Polarization Scenario

Oleksiy Mazhelis, Pasi Tyrväinen

University of Jyväskylä, Jyväskylä, Finland

Jarmo Matilainen

Mikkelin Puhelin Oyj, Mikkeli, Finland

Keywords: Vertical integration and disintegration, software implementation efforts, market polarization,

telecommunications software, operations support systems, business support systems.

Abstract: A vertical software market is usually subject to the process of disintegration resulting in a market where

different layers of software are provided by independent software vendors. However, as argued in this paper,

the process of this vertical disintegration may be affected by high investments to software interface

implementation and maintenance. Should the required efforts be large, the threshold for entering the market

increases, thereby hampering the vertical disintegration process. This study examines the impact of the

interface implementation efforts on the vertical market evolution in the case of the so-called operations support

systems and business support systems (OSS/BSS) software, which are employed by the telecom operators in

order to support their daily operations. The efforts are compared for two prototypical software vendors serving

incumbent operators and new operators respectively. Total efforts are an order of magnitude larger in the

former case. Furthermore, even if only latest network protocols are taken into account, the efforts are

significantly larger in the former case, therefore requiring several times greater number of employees to

implement them. Therefore, a conclusion is made that the OSS/BSS market is likely to polarize into the vertical

submarket of large software vendors serving incumbent operators, and the submarket of small vendors serving

young operators. The latter submarket, due to the lower entry threshold for new vendors is more likely to be

vertically disintegrated.

1 INTRODUCTION

Software markets generally develop from vertically

integrated towards vertically disintegrated (Macher

and Mowery, 2004). According to the model based

on the analysis of different verticals of the Finnish

software industry (Tyrväinen et al., 2004, 2008), for

instance, innovative software is initially developed

not by software vendors but in house by companies

representing the business in the market vertical in

order to automate and improve their business

processes and thereby achieve competitive

advantage over the competition in the specific

industry. Vertical disintegration implies that the

software is decomposed into horizontal layers;

software in different layers is provided by

independent software vendors and it is integrated

with the other layers via standardized interfaces.

Numerous vendors operate horizontally in multiple

industries, which provide a larger market for them

while some of vendors are still specialized to serve a

single industry.

Several factors such as high degree of customer-

specific tailoring, the need to coordinate innovation

efforts spanning over several layers in a vertical

(Mazhelis et al., 2007), etc., are likely to hamper the

vertical disintegration of the software. In this paper,

we focus on studying another potential hindering

factor, namely, the high complexity of the software

interfaces. We assume that, whenever a software

vendor provides software to a customer, this

software needs to be integrated with a number of

heterogeneous subsystems deployed by the

customer. If the number of integration interfaces is

Mazhelis O., Tyrväinen P. and Matilainen J. (2008).

ANALYZING IMPACT OF INTERFACE IMPLEMENTATION EFFORTS ON THE STRUCTURE OF A SOFTWARE MARKET - OSS/BSS Market

Polarization Scenario.

In Proceedings of the Third International Conference on Software and Data Technologies - SE/GSDCA/MUSE, pages 80-87

DOI: 10.5220/0001890200800087

 SciTePress

high, a vast amount of special knowledge is needed

in the vendor organization. High integration efforts

consume also the limited amount of compentent

employes of the vendor organization decreasing the

number of customers which it is capable to serve. As

a result, only few large vendors can survive in such

market, and the evolution towards horizontalized

market with standardized interfaces and established

standard architectures (see e.g., dominant design in

Murmann and Frenken 2006) may be delayed or

may never materialize.

The impact of the software interface

implementation efforts on the structure of the market

is studied in this paper on the example of the

telecom operator software. The so-called operations

support systems and business support systems

(OSS/BSS) are used by the telecom operators for

operating and monitoring their networks, as well as

for managing their performance, quality of service,

faults, configuration, roaming, accounting, customer

relationships, frauds, etc. (Terplan, 2001). Though

the OSS/BSS software has been used for several

decades, the software still remains to a large extent

vertically integrated. E.g. activation and

configuration software, performance and fault

management software is often produced by the

vendors of network element hardware.

In this paper, we study whether the high

complexity of the OSS/BSS software interfaces may

serve as a potential hindering factor for OSS/BSS

market horizontalization. We assume that OSS/BSS

software provided by a software vendor for an

incumbent operator needs to be integrated with a

large number of heterogeneous subsystems. Due to

the high interface implementation efforts, the

number of companies capable of providing

necessary integration decreases, and hence the

OSS/BSS market horizontalization may be delayed.

Based on the above assumption, a hypothesis is

made that the OSS/BSS market will split into the

submarket of incumbent operators with vertically

integrated systems, and the submarket of new

operators with vertically disintegrated systems.

Consequently, the OSS/BSS market is likely to be

polarized into many smaller players and few very

big players, serving two distinct types of customers

– respectively incumbent and new operators.

In order to verify the hypothesis, the interface

implementation efforts for incumbent and new

operators are compared in the paper. For this,

interface implementation efforts for the activation

and billing mediation segments are estimated. It is

found that the efforts needed for new operators are

significantly lower as compared with the efforts

required for the incumbents. As a result, a tentative

conclusion is made that the vertical disintegration is

more likely in the domain (submarket) of young

operators, and consequently, OSS/BSS market is

likely to become polarized into many small and few

very big software vendors.

The paper is organized as follows. In the next

section, an approach to interface implementation

efforts estimation is introduced. This appoach is

applied in section 3, in order to assess and compare

the efforts of implementing OSS/BSS mediation

interfaces. Some business implications of the results

of this study are provided in section 4, followed by

the conclusions in section 5.

2 INTERFACES AND THEIR

IMPLEMENTATION EFFORTS

In order to verify the hypothesis that the process of

market horizontalization may be hindered due to the

set of interfaces which need to be supported, we

consider the efforts which a software vendor needs

to devote to interface implementation and

maintenance. The effort estimations are employed as

an indicator reflecting the likely size of the software

vendors capable of providing these interfaces.

Higher interface implementation efforts resulting in

the greater size of the software vendors are assumed

to reduce the number of software vendors in the

market, and hence delay the horizontalization of the

market. Furthermore, horisontalization in two

submarkets can be compared on the basis of the

interface implementation efforts: the greater the

efforts, the more likely delays in the

horizontalization. Eventually, the submarket with the

lighter interface implementation efforts may

horizontalize while the submarket with greater

efforts may remain vertically integrated, thereby

resulting in a market polarization.

In this paper, an interface is defined as a stack of

protocols and associated data formats that govern a

communication between software subsystems.

Protocols in the stack may have different versions;

two interfaces comprised of the same protocols of

distinct versions are referred to as variations of the

interface.

Given an interface to be supported, human

resources are required not only to implement or

configure the software providing the interface, but

also afterwards – for maintenance, for

reconfiguration of a standardized interface, or in

order to perform new integration projects involving

ANALYZING IMPACT OF INTERFACE IMPLEMENTATION EFFORTS ON THE STRUCTURE OF A SOFTWARE

MARKET - OSS/BSS Market Polarization Scenario

the interface. Therefore, human resources are needed

for each interface for the entire lifetime of that

interface.

Below, the approach to estimating interface

implementation efforts is described, and the

OSS/BSS interfaces that are being analyzed are

introduced.

2.1 Estimating Interface

Implementation Efforts

Let us consider the total efforts a software vendor

devotes to interface implementation, namely:

 The initial implementation of interfaces (i.e.

initial implementation of protocol stacks),

 The development of the new variations of

interfaces (corresponding to new versions of

protocols),

 Configuration of the interfaces for individual

customers (mainly data format are adapted to

the needs of an individual customer),

 Maintenance of interfaces.

The efforts needed for implementing an interface

greatly depend on the type of protocols being used.

Many types of protocols may need to be

implemented, among them are proprietary, OSI

based (FTAM, CMISE/CMIP), CORBA, web-based

(HTTP, SOAP, LDAP, RADIUS), and other

standards-based protocols (FTP, GTP, MAP, etc.).

Besides, protocols may have several versions, hence

resulting in a number of coexisting interface

variations.

In order to assess the total interface development

and maintenance efforts, we need to first determine:

 for each type of protocols, the number of

versions/variations;

 for each variation, the efforts (initial, variant

development, configuration, maintenance)

needed.

The above estimates need to be time-stamped, so

that the year-by-year dynamics of the efforts could

be studied.

For each interface, by consulting publicly

available data and by inquiring domain experts, the

main types of the protocol stacks and the number of

protocol variations can be determined, and the

efforts needed for each of the variations may be

estimated. The number of protocols and their

variations are calculated as follows.

The number of new standard protocols

stdnew

of a specific type is equal to 1, if the protocol has

adopted during the specified period of time, and is

equal to 0 otherwise.

The number of new proprietary protocols

proprnew

N of a specific type developed within

period

(

)

stopstart

, yy

(in years) is estimated as:

(

)

()

startstop

typesprotocolall

total

yearperproprnewstopstartproprnew

NyyN

′

−

′

×=

∑

(1)

where:



begin

and

end

Y are the beginning and the end

of the protocol lifetime, respectively,



(

)

endstopstop

,min Yyy =

′



(

)

beginstartstart

,max Yyy

′



total

N is the total number of variations of a

specific type of protocols, and



yearperproprnew

N is the average number of new

proprietary protocols being developed each

year (assumed to be equal 2 in this study).

It is assumed for simplicity that protocol

variations are uniformly distributed throughout the

lifetime of the protocol. Then, for each protocol

type, the number of protocol variations

var

N for a

given period

(

)

stopstart

, yy

is estimated as:

(

)

()

startstop

beginend

total

stopstartvar

yyN

′

−

′

−

(2)

It is assumed that development of a new

variation also requires configuration, therefore

the number of configurations is

(

)

(

)

stopstartvarstopstartconf

,, yyNyyN

. It is further

assumed that all the interfaces require maintenance

efforts, which are constant during the lifetime of the

protocol, and are decreasing afterwards at the rate

negatively proportional to the time elapsed:

(

)

() ()

[]

()

⎪

⎩

⎪

⎨

⎧

−+

≤

∫

′

end

endbeginnew

new

beginvarvar

varnewstopstartmaint

if ,

if ,,

where,,

stop

start

YYN

YttYN

tYNtN

dttNtNyyN

(3)

ICSOFT 2008 - International Conference on Software and Data Technologies

Here,

(

)

stopstartnew

, yyN denotes, depending on the

protocol, either

(

)

stopstartproprnew

, yyN

(

)

stopstartstdnew

, yyN

For each protocol type, the total interface

implementation efforts

within a period

(

)

stopstart

, yy

are estimated by summing the initial

implementation efforts

e , the efforts

var

e needed

for implementing variations, the configuration

efforts

conf

e , and the maintenance efforts

maint

e :

(

)

(

)

()

stopstartmaintmaint

stopstartconfconf

stopstartvarvar

stopstartnew0stopstart

yyNe

yyNeyye

(4)

Finally, the total interface implementation efforts

for all types of protocols within a period

(

)

stopstart

, yy

are estimated by summing up the

efforts of different types of protocols:

(

)

(

)

∑

typesprotocol all

stopstartstopstart

,, yyeyyE

(5)

The estimation of the interface implementation

efforts can be then used in estimating the size of the

software vendor organization. Namely, assuming a

specific percentage of employees devoted to

interface implementation efforts, the size of the

research and development (R&D) department(s) and

the total size of the organization can be estimated.

2.2 OSS/BSS Mediation Interfaces

In order to verify the hypothesis of OSS/BSS market

polarization into a horizontal submarket of many

smaller players and a vertical submarket of few very

big players, we consider the interfaces of their

respective customers – i.e. incumbent and new

operators.

The assumption is that the “older” the operator,

the larger number of heterogeneous subsystems the

operator has adopted and has to maintain; this

heterogeneity stems e.g. from the mergers and

acquisitions, upgrades to new versions and types of

equipment, etc. The incumbent operators have

highly complex systems composed of a large

number of diverse subsystems with complex (also

proprietary) interfaces between them. Young

operators who may have started with greenfield

implementation, on the other hand, are likely to

operate with a more manageable infrastructure with

a smaller number of harmonized subsystems where

standard interfaces are used more often. Interface

implementation efforts differ dramatically among

the two.

Another differentiation factor between

incumbent operators and young operators is the

change of business models. Incumbent operators

typically have a lot of business models which are

based on billable tickects collected from hardware.

Those tickets are then billed based on different

agreements with customers – this kind of business

model is for example the traditional fixedline PSTN

– business. Young operators often base their

business on flat rate business models, because the

volume’s doesn’t support heavy investments on

ticketing based systems. The business model is more

or less like any other service business for example

like Cable TV –business. This differentiation can be

seen in the amount of the interafaces and also in the

complexity in the interface structure.

As a result, new entrants (software vendors),

who have a rather limited number of personnel

available, are likely to be able to cover integration

work only in upcoming markets where the

integration work is simplified by the use of web-

based integration technologies (based on IETF

standards) as well as by the use of business process

management tools.

There are a number of interfaces present in

OSS/BSS systems; however, for simplicity, the

analysis in the paper is restricted to the four

interfaces, which need to be implemented by the

mediation software subsystems (see Figure 1 below):

 Charging

– Collection interface between Mediation

and Network Elements (NEs)

– Charging interface between Mediation

and Billing Systems (also fraud, revenue

assurance, dataware, interconnect etc.

systems)

 Configuration

– Configuration interface between

Mediation and NEs

– Activation interface between Mediation

and Service Order Management System

(e.g. inside CRM, Billing, sales

applications)

ANALYZING IMPACT OF INTERFACE IMPLEMENTATION EFFORTS ON THE STRUCTURE OF A SOFTWARE

MARKET - OSS/BSS Market Polarization Scenario

Figure 1: Interfaces implemented by the mediation software.

A product of a software vendor may interface

only with a few other types of physical entities

(network elements, billing systems, repositories,

etc.). However, for each of these interfaces, a variety

of application protocols may need to be supported,

ranging from proprietary protocols and flat files, to

FTP, telnet, CMISE/CMIP, to IETF protocols such

as HTTP, SOAP, LDAP, RADIUS etc. The data

may be transferred over various network protocols

(X.25, TCP/IP or UDP, SS7, etc.) using different

data presentation formats (ASN.1, TAP, IPDR,

NetFlow records, etc.). Moreover, each of the

protocol stacks may have numerous versions

resulting in numerous interface variations. As a

result, the software vendor may need to develop and

maintain hundreds of different interface variations.

3 POLARIZATION OF OSS/BSS

MARKET: COMPARING

EFFORTS OF INTERFACE

IMPLEMENTATION

The data used in this study originates from the

SmarTop project (http://www.jyu.fi/titu/smartop),

which explores the evolution of telecom operator

software focusing on the development of the

software market in this domain. Various data

collection techniques were employed including the

analysis of the Dittberner Associates’ OSS/BSS

Knowledgebase

(http://www.dittberner.com/reports/about53.php),

documentation by TeleManagement Forum

(http://www.tmforum.com/), and other publicly

available web-sources, also complemented with the

data gathered through interviews.

The collected data was used in order to estimate

the dynamics of interface implementation efforts,

which a mediation software vendor should be able to

devote if it is to serve i) the incumbent operators and

ii) the young operators. According to the data, a few

dozens of the protocol types and over three hundreds

of interface variations need to be supported if the

software is offered to the incumbent operators.

Based on the available data, interface

implementation efforts (in person-years) have been

estimated for approximately 60% of the protocol

types that are implemented by the mediation

software vendor. Furthermore, we assume that this

data obtained covers approximately 80% of the

variations implemented by the mediation software

vendor company. In order to compensate for the

protocols/variations which were left outside of

consideration, the resulting effort estimations were

scaled accordingly.

The results of effort estimation are shown in

Figure 2. In the graph, the efforts of interface

implementation are shown for two cases:

 All types of interfaces are supported (dashed

line).

 Only interfaces based on standard IETF

protocols (RADIUS, LDAP, HTTP, SOAP,

etc.) are supported (solid line).

The software vendors aiming at serving the

incumbent operators need to implement all types of

the interfaces; therefore, the efforts such a vendor

needs to devote are considered in the first case

(dashed line). On the other hand, the vendors serving

new operators may have to implement only a (IETF)

subset of the protocols, and therefore the

corresponding efforts are considered in the second

case (solid line). The total efforts in the first case

were found to be 32 times greater than the efforts in

the second case.

Mediation

NEs: switch, hlr, router, ldap, radius, e-mail

Billing mediation

Provisioning & Activation

mediation

Billing systems,

fraud mgt systems,

revenue assurance,

dataware sytsems,

Interconnect billing, etc.

Service Order

Management System

(e.g. in CRM)

Service Activation

Configuration Collection

Charging

ICSOFT 2008 - International Conference on Software and Data Technologies

Figure 2: Efforts devoted to interface implementation by a mediation software company. In red: all types of interfaces are

supported. In blue: only interfaces following IETF standards are supported.

The estimation of the interface implementation

efforts can be used in order to estimate the size of

the organization in both cases. Having assumed a

specific portion of staff devoted to interface

implementation efforts in the company’s R&D, the

size of the R&D department(s) and consequently the

total size of the organization can be estimated.

Assuming that 5-10% of personnel are dealing with

interface implementation and maintenance:

 In the first case, the organization is likely to

have a few hundreds of employees.

 In the second case, the size of the organization

is estimated to be a few dozens of employees

(assuming that all protocols are to be

developed within two years).

Therefore, only relatively big companies are

capable of serving the incumbent operators, due to

the large efforts required. Furthermore, since the

current players have been implementing interfaces

for many years and have accumulated a large

“interface portfolio”, it is unlikely that a new player

can compete with these players – the newcomer is

unlikely to possess enough resources for

implementing all (or a significant portion of) the

interfaces.

On the other hand, it is much easier for new

software vendors (especially those with highly

limited resources) to serve the new operators which

require only IETF interfaces to be implemented. As

a result, a significant number of newcomers are

likely to compete for the market of such new

operators.

It is important to note that in the process of

analyzing the mediation software interfaces, a

number of assumptions had to be made, such as the

assumptions on the number of types of the interfaces

and their variations, the assumption of the

homogenity of the interfaces across the operators of

the same kind (i.e. incumbents and commencing),

the assumption on the size of the R&D units in

relation to the overall size of the software vendors,

etc. Should some of the assumption be invalid, it

may adversely affect the result of comparing the

interface implementation efforts. Therefore, the

conclusion on the likelyhood of OSS/BSS market

polarization should be considered with care.

4 BUSINESS IMPLICATIONS

4.1 General

In the paper, the efforts of software interface

implementation and maintenance are considered as a

factor influencing the structure of the software

market. Higher interface implementation efforts play

the role of a threshold for the vendors entering the

market of incumbent operators thereby effectively

disabling the entries by small commencing vendors

(see also Figure 3 below). In a longer run, such a

threshold can be assumed to reduce the number of

software vendors in the market, causing a delay in

the vertical disintegration of this market.

Furthermore, according to the results of the

analysis, a market polarization scenario is likely

whenever a fraction of the customers in the market

require a large number of complex interfaces to be

supported, while the other customers request only a

small set of simpler interfaces, Therefore, a new

100

1990

1994

1998

2001

2002

2005

Yea

All protocols

Onl

IETF protocols

()

max

ANALYZING IMPACT OF INTERFACE IMPLEMENTATION EFFORTS ON THE STRUCTURE OF A SOFTWARE

MARKET - OSS/BSS Market Polarization Scenario

Figure 3: Incumbent operators are served by large software vendors, while the small vendors entering the OSS/BSS market

will target commencing operators.

software vendor entering such polarized market may

benefit from focusing on the submarket with the

lighter interface implementation efforts. This is

likely to increase the number of vendors in this new

segment, thereby increasing competition which can

be visible in form of wider variety of offering and

price erosion. This chain of events is likely to

benefit the new operators and lower the threshold for

new operators to enter the market, which will

increase the volume of the market segment.

4.2 Telecom OSS/BSS Software

Market

In summary, the achieved results suggest that the co-

existence of incumbent and new operators with

distinct requirements for the interfaces to be

implemented is likely to result in the co-existence of

a few big and a large number of small software

vendors serving these two types of operators.

The analysis points to a likelihood of niches in a

software market, especially if the software is

dependent of the use of specific hardware equipment

as the physical networks of the operators. Software

vendors that have long term partnerships with

incumbent companies that are active in the industry

(operators, software and hardware vendors) are

likely to possess richer knowledge of their legacy

technologies and systems, and these software

vendors are likely to maintain their position in their

segment of the market. However, this knowledge

does not guarantee that they sustain their positions in

the overall market: new solutions by new business

entrants starting with greenfield implementations

may require another set of competencies, for

example the ability to implement open source

solutions as a service for the young operators.

Furthermore, the competition comes not only from

the the old timer telecom software vendors, but also

from generic software providers.

5 CONCLUSIONS

According to industry evolution theories, a vertical

software market gradually undergoes the process of

vertical disintegration resulting in a set of horizontal

software layers with standard interfaces, where the

software at each layer can be provided by an

independent software vendor. However, due to

various reasons, the process of vertical disintegration

may be delayed, and in extreme cases may never

complete.

This paper suggests that the interfaces, which the

software at one or few of the layers needs to provide

may become an obstacle for the vertical

disintegration. Because of the great efforts that may

be needed for interface development and

maintenance, only few big software vendors may be

capable of competing in the market. As a result, the

conditions necessary for vertical disintegration may

never materialize.

The impact of interface implementation efforts

on vertical disintegration has been studied in this

paper in the case of the telecom OSS/BSS software.

The results of analysing the efforts support the

Software

vendor

Operator

Incumbent

operator

Commencing

operator

Complex vertical

intertwined legacy

systems

Streamlined or

standardized

layered systems

Integration of

new systems

requires

significant efforts

Integration of

new systems is

straightforward

Large

(incumbent)

vendors

Small

(entrant)

vendors

SW 1

…

Proc. 1 Vendor 1

SW nProc. n Vendor n

SW 1

Process 1

Process n

… SW n

HW kHW i … …

Vendor 1..n

Vendor i..k

Vertical software

ICSOFT 2008 - International Conference on Software and Data Technologies

hypothesis that, due to the co-existence of

incumbent operators with highly complex interfaces

and new telecom operators with relatively

lightweight requirements for the interfaces to be

implemented, the market of the OSS/BSS software

is likely to be split into two polarized submarkets:

the submarket of incumbent operators served by a

few large software vendors, and the submarket of

young operators served by a large number of small

software vendors. As a result of the difference in the

efforts, the submarket of young operators is likely to

horizontalize, while the submarket of incumbent

operators is likely to remain vertically integrated.

Besides prohibitively large interface

implementation and maintenance efforts, the vertical

disintegration of a software market may be

hampered by other obstacles, such as the internal

complexity of the business processes being

automated by the software, the need to maintain

compatibility with older systems, the need to comply

with the legislation mandating the use of specific

systems, etc. These factors, however, have been left

out of the scope of this paper, and therefore further

study is needed in order to address them.

ACKNOWLEDGEMENTS

The authors would like to thank Prof. Olli

Martikainen for valuable comments and suggestions,

as well as to Mirja Pulkkinen for her great efforts to

improve the paper. The study was conducted as a

part of SmarTop research project

(http://www.jyu.fi/titu/smartop) funded by The

Finnish Funding Agency for Technology and

Innovation (Tekes) and sponsored by Nokia Siemens

Networks, Tecnomen, Comptel, Nethawk, and

Mikkelin Puhelin.

REFERENCES

Macher, J., D. C. Mowery, D., 2004. Vertical Specialization

and Industry Structure in High Technology Industries.

Advances in Strategic Management, vol. 21, pp. 317-

356.

Mazhelis, O., Tyrväinen, P., Viitala, E., 2007. Modeling

software integration scenarios for telecommunications

operations software vendors. In IEEE International

Conference on Industrial Engineering and

Engineering Management (IEEM 2007).

Murmann, J.P. and Frenken, K. 2006. Toward a systematic

framework for research on dominant designs,

technological innovations, and industrial change.

Research Policy, 35 (7), 925-952.

Terplan, K., 2001. OSS Essentials - Support System

Solutions for Service Providers. New York, NY: John

Wiley & Sons.

Tyrväinen, P., Warsta, J., Seppänen, V., 2004.

Toimialakehitys ohjelmistoteollisuuden vauhdittajana.

Uutta liiketoimintaa lähialoilta.

Tyrväinen, P., Warsta, J., Seppänen, V., 2008. Evolution

of Secondary Software Businesses: Understanding

Industry Dynamics. Forthcoming in Proceedings of

IFIP WG 8.6 Conference, Open IT-Based Innovation,

Madrid 22-24.10. 2008.

ANALYZING IMPACT OF INTERFACE IMPLEMENTATION EFFORTS ON THE STRUCTURE OF A SOFTWARE

MARKET - OSS/BSS Market Polarization Scenario