TELECOMMUNICATIONS SERVICE CREATION: TOWARDS

EXTENSIONS FOR ENTERPRISE ARCHITECTURE MODELING

LANGUAGES

Vanea Chiprianov

1,2

, Iyas Alloush

3,1

, Yvon Kermarrec

1,2

and Siegfried Rouvrais

Institut Telecom, Telecom Bretagne, Universit´e Europ´eenne de Bretagne

Technopole Brest Iroise, CS 83818 29238, Brest Cedex 3, France

UMR CNRS 3192 Lab-STICC, Brest, France

Faculty of Information Technology Engineering, Damascus University, Damascus, Syria

Keywords:

Enterprise Architecture, Domain Speciﬁc Modeling Language, Model Driven Engineering.

Abstract:

From the 90’s, the telecommunications service creation industry has undergone radical change. Services have

shifted from being based on a switching environment to being mainly based on software. To remain compet-

itive in these new dynamic conditions of an open market, telecommunications organizations need to produce

high quality services at low prices within short periods of time. Concerning Service Providers, they need an

overall representation of service creation taking in all business, management, and technical activities. To re-

duce their concept-to-market time for new services, they also need tools specialized for their tasks and domain.

In this position paper, we argue that a telecommunications proﬁle for an Enterprise Architecture modeling lan-

guage answers these needs. We also design a telecommunications proﬁle for ArchiMate that offers conformity

to standards through the reuse of a recognized Enterprise Architecture modeling language. Moreover, this pro-

ﬁle provides easier adoption by Service Providers due to inclusion of domain speciﬁc concepts. The proﬁling

mechanism we propose may be used for deﬁning language extensions speciﬁc to other industries as well.

1 SERVICE CREATION

CHALLENGES IN A

SOFTWARE WORLD

From the 90’s, the telecommunications (telecom) ser-

vice creation industry has undergone radical change

(H˚allstrand and Martin, 1994). Traditionally, services

were offered on equipment from switch manufactur-

ers. The complexity of the switching environment al-

lowed only the switch manufacturer to develop ser-

vices. Nowadays, services have become more soft-

ware based. This changes the focus from switching

environments to computer environments. To remain

competitivein these new dynamic conditions, telecom

organizations have to produce high quality services at

low prices within short periods of time.

Service creation is a complex activity not only be-

cause of the technical activities involved, but also of

the number of actors and the difference in each ac-

tor’s perspective and objectives. To simplify this situ-

ation, roles have been identiﬁed to allow separation of

the different perspectives from the organizations con-

cerned (H˚allstrand and Martin, 1994):

• End User: the actual user of a service; primarily

interested in service functionality, quality and cost.

• Service Subscriber: the person or organization who

contracts and pays for the service. It may need to

customize and change services.

• Service Provider: the organization that provides

value-added services. The traditional Operator is

not the only actor in the role of Service Provider,

separate (network independent) organizations also

act in this role. The Service Provider is primarily

interested in considerations related to the End User

(e.g. anticipating and determining requirements for

new services, promotion of services in the market-

place) and deployment (e.g. validation of services

against requirements, testing of services in the tar-

get network, the interaction between new and ex-

isting services in the network).

• Service Developer: the organization who performs

all the actions necessary to create a new service.

They are interested in rapid prototyping and cus-

tomization of services.

• Network Provider: the organization who operates,

administers and maintains telecom networks; pro-

Chiprianov V., Alloush I., Kermarrec Y. and Rouvrais S..

TELECOMMUNICATIONS SERVICE CREATION: TOWARDS EXTENSIONS FOR ENTERPRISE ARCHITECTURE MODELING LANGUAGES.

DOI: 10.5220/0003441100230028

In Proceedings of the 6th International Conference on Software and Database Technologies (ICSOFT-2011), pages 23-28

ISBN: 978-989-8425-76-8

 2011 SCITEPRESS (Science and Technology Publications, Lda.)

vides bearer and management services.

• Manufacturer: the traditional telecom manufac-

turer which provides a platform upon which ser-

vices can execute. They are interested in providing

platforms that are open and ﬂexible.

• Tools Vendor: the organization who produces tools

which are used by the various actors in the service

industry. They are interested in producingtools that

cover speciﬁc tasks but are adaptable to each orga-

nization’s needs.

In such a complex stakeholder ecosystem, to as-

sist service creation, a complex software Service Cre-

ation Environment is required. We focus in this paper

on the role of Service Providers. Their requirements

(as identiﬁed by (H˚allstrand and Martin, 1994)) for

Service Creation Environments include:

1. An overall model : They are interested in selling

and marketing their services. A graphical model

describing the service creation process from a mar-

ket standpoint is useful. This model should include

all business planning and economic analysis activ-

ities. In addition, network planning should also

be represented by a separate model. These models

should be integrated with the model of the technical

activities involved in development so that an over-

all model of service creation taking in all business,

management, and technical activities is obtained.

2. Domain speciﬁcity : They want to reduce the

concept-to-market time, as the market windows are

decreasing from years to months. This means that

tools specialized for the task and domain are essen-

tial, like those for specifying service functionality.

3. Rapid prototyping : They need a rapid prototype of

a service, to asses its potential market success.

To answer the Overall model requirement 1, we

propose to rely on Enterprise Architecture (EA)

frameworks and modeling languages. However, these

are general purpose, without any speciﬁcity to the

tasks and domain of telecom. To answer the Domain

speciﬁcity requirement 2, we propose deﬁning a Do-

main Speciﬁc Language (DSL), dedicated to telecom

speciﬁc tasks. To integrate these two approaches, we

propose deﬁning the telecom DSL as a proﬁle to an

existing EA modeling language. Among the many

methods for deﬁning a language, the one which seems

to fulﬁll best the Rapid prototyping requirement 3 of

Service Providers is the Meta-modeling approach.

EA frameworks and modeling languages are dis-

cussed in Section 2. DSLs are treated in Section

3. The Meta-modeling approach for the deﬁnition of

DSLs is discussed in Section 4. The proposed tele-

com proﬁle is presented in Section 5. Perspectives

and expected impacts are indicated in Section 7.

2 ENTERPRISE ARCHITECTURE

FRAMEWORKS AND

MODELING LANGUAGES

EA answers the Overall model requirement 1 of Ser-

vice Providers. An Enterprise Architecture (EA) ap-

proach consists of a set of models describing the

structure and functions of an enterprise. These mod-

els are organized into levels, from more generic (e.g.

objectives) to more speciﬁc (e.g. technology used).

Integrating all the models from these levels results

into an overall model of service creation taking in all

business, management, and technical activities. An

EA approach is beneﬁcial for: system complexity, ag-

ile business alignment with technology platforms, in-

teroperability and integration of constituting systems

of an enterprise, common understanding.

However, there are several EA methods and

frameworks (e.g., TOGAF, RM-ODP, Zachman

Framework, eTOM). The enhanced Telecom Opera-

tions Map (eTOM) (TMF Forum, 2008) deﬁnes pro-

cesses and functional areas related to the manage-

ment of telecom speciﬁc data. However, as argued

by (Bertin et al., 2010) for example, eTOM focuses

on the internal activities of an enterprise for provid-

ing services, and it does not cover the core value of a

service as seen by the End User.

The Open Group Architecture Framework (TO-

GAF) (The Open Group, 2009b) provides methods

for assisting in the acceptance, production, use and

maintenance of an EA. At the core of TOGAF is the

Architecture Development Method (ADM), consist-

ing of eight phases and providing one of the most

complete (Sessions, 2007) guiding step-by-step pro-

cess for creating an EA. A comparison between TO-

GAF and several architecture initiatives (e.g., RM-

ODP, Zachman Framework) is provided by (The

Open Group, 2007). TOGAF is one of the strongest

(Urbaczewski and Mrdalj, 2006) frameworks on the

business and technical layers, providing much detail

for them. As these layers are most important for our

industrial Service Provider partners, we retain TO-

GAF for our approach.

EA frameworks deﬁne processes, guides, meth-

ods, etc. They are theoretical in nature, and to apply

them modeling languages are needed. There are many

modeling languages, both EA speciﬁc (e.g., Archi-

Mate, IDEF, UEML) and for general purpose (e.g.

UML). UML is a family of graphical modeling lan-

guages allowing structural and behavioral speciﬁca-

tion. While modeling a telecom service using it is

possible, UML is not purposely conceived to offer the

EA abstraction levels and relations between them.

One EA speciﬁc modeling language is ArchiMate.

ICSOFT 2011 - 6th International Conference on Software and Data Technologies

It shares (Berrisford and Lankhorst, 2009) important

concepts with TOGAF, and thus ”the two are usable

together”. It models three phases of TOGAF Archi-

tecture Development Method into three layers: Busi-

ness, Application and Technology. It regulates inter-

operability between them by deﬁning possible depen-

dencies. Due to its proximity with TOGAF, we retain

ArchiMate for our approach.

3 TOWARDS PROFILES FOR

ENTERPRISE ARCHITECTURE

MODELING LANGUAGES

In this section, we argue the need to extend EA mod-

eling languages with domain speciﬁcity at the techni-

cal level. As extensions mechanisms we investigate

DSMLs and proﬁles.

An EA modeling language offers the advantage

of a uniﬁed language, capable of describing a wide

range of domains. It makes possible to create in-

tegrated models of the enterprise, which can be un-

derstood by all stakeholders. While this is very use-

ful at the business level, at the technical level, where

more detail is needed to describe a system, this uni-

ﬁed language lacks the semantic strength required.

By lacking semantic strength we understand that the

concepts present in the language are too abstract and

they need reﬁnement and speciﬁcation. To cover this

lack, an EA modeling language development method

(Khoury, 2007) proposes to use a uniﬁed modeling

language at the business level, while at more detailed

levels use DSMLs and methods.

A Domain Speciﬁc Language (DSL) is ”a lan-

guage that offers, through appropriate notations and

abstractions, expressive power focused on, and usu-

ally restricted to, a particular problem domain”

(Deursen et al., 2000). A Modeling Language is, ”a

graphical language for visualizing, specifying, con-

structing, and documenting the artifacts of a software-

intensive system” (Booch et al., 2005). A Domain

Speciﬁc Modeling Language (DSML) is therefore

taken in this position paper to be a graphical language

that offers, through appropriate notations and abstrac-

tions, expressive power focused on a particular prob-

lem domain, to visualize, specify, construct and doc-

ument the artifacts of a software-intensive system.

DSMLs allow experts in general, and Service

Providers in our case, to express, validate, modify

solutions and achieve tasks speciﬁc to their domain,

as the Domain speciﬁcity requirement 2 demands.

A DSML requires less cognitive (Green and Petre,

1996) effort from experts than a more general purpose

language, as it offers a higher closeness of mapping

between the problem world and the program world.

Thus quality, productivity, reliability, maintainability,

reusability can be enhanced.

In accordance with the EA modeling language de-

velopment method proposed by (Khoury, 2007), we

propose deﬁning a telecom DSML corresponding to

the technology level of ArchiMate. This raises the

question of integration between the telecom DSML

and ArchiMate. To answer it, we propose deﬁning

the telecom DSML as a proﬁle to ArchiMate.

A proﬁle (Alhir, 2002) is a generic extension

mechanism for customizing reference languages with

constructs that are speciﬁc to particular domains, plat-

forms. Extension mechanisms allow reﬁning the ref-

erence language in a strictly additive manner, so that

they can’t contradict standard semantics. Although

proﬁles are usually associated with UML, they can be

generalized to other modeling languages as well. We

use the term proﬁle in its general meaning (as exten-

sion), and not in its UML-bound sense.

Proﬁles put a strictly additive constraint on exten-

sions to reference languages. This means that pro-

ﬁle tools, deﬁned as extensions to existing tools for

the reference language, only have to process the ad-

ditions. There is no need to change in other way the

tools for the reference language. The initial cost of

DSML tool implementation as proﬁle is lower than

that for a standalone DSML. Also, interoperability

between several DSMLs, deﬁned as proﬁles, is facili-

tated by the reference language. The constructs com-

mon between the reference language and each DSML

respectively, and the connections between the con-

structs from the reference language, facilitate deﬁning

connections (interoperability) between proﬁles.

To conclude this section, we highlight the need for

EA modeling languages to have stronger semantics

to describe in more detail the system under study at

lower (e.g. technical) levels of abstraction. As these

detailed descriptions are speciﬁc to each domain, ex-

tensions (proﬁles) to EA modeling languages, speciﬁc

to each domain, are necessary.

4 LANGUAGE DEFINITION

USING THE META-MODELING

APPROACH

Language extensions have to be deﬁned using a for-

malism and tools have to be provided for them. These

concerns are speciﬁc rather to Tools Vendors, but

choices taken here also inﬂuence Service Providers.

There are several methods for deﬁning a language.

TELECOMMUNICATIONS SERVICE CREATION: TOWARDS EXTENSIONS FOR ENTERPRISE ARCHITECTURE

MODELING LANGUAGES

Compiler theory uses: abstract and concrete syn-

taxes, and semantics. It provides (meta-)tools (e.g.,

lex, yacc) that generate language-speciﬁc tools (e.g.,

lexical, syntactical parsers). However, it deals with

textual languages, whereas Service Providers, as in-

dicated by the Overall model requirement 1, need

graphical models, so a graphical language.

In the Meta-modeling approach for graphical

modeling languages deﬁnition (Clark et al., 2001), the

abstract and concrete syntaxes from compiler theory

are described using meta-models. One way of de-

scribing operational semantics is by generating code

from the new language to existing (programming)

languages, and so producing an executable form of

the model. The Meta-modeling approach also pro-

vides (meta-)tools (e.g., Eclipse Modeling Frame-

work (EMF), Xpand) that generate language-speciﬁc

tools (e.g., graphical editor, code generation). This

reduces signiﬁcantly the time, effort and cost of con-

structing language-speciﬁc tools.

In our telecom context, for Tools Vendors, an

even more important characteristic of the Meta-

modeling approach is its advantage of rapid prototyp-

ing. Through the use of meta-tools, language-speciﬁc

tools can be rapidly generated. Telecommunications

services are rapidly evolving and new requirements

of Service Providers have to be met by Tools Ven-

dors. When language deﬁnition evolves, it impacts

the meta-models describing the syntax and the se-

mantics. Due to the generative, meta-tool based ap-

proach, language-speciﬁc tools can be re-generated to

include the new language features, with limited mod-

iﬁcations, fast and inexpensive.

The model driven paradigm presents advantages

to Service Providers also. Using a Meta-modeling

deﬁned language, Service Providers can describe a

service graphically, independently of technical de-

tails and constraints (or what in Model Driven En-

gineering - MDE is called a Platform Independent

Model (PIM)). Then they can partially generate code

to simulate and test the new service for several dif-

ferent platforms (Platform Speciﬁc Models (PSMs) in

MDE). In this way, Service Providers can rapidly gen-

erate prototypes of new services, as the Rapid proto-

typing requirement 3 demands.

5 A TELECOMMUNICATIONS

ARCHIMATE PROFILE

As a consequence to discussions from previous sec-

tions, we propose deﬁning a telecom ArchiMate pro-

ﬁle relying on a Meta-modeling approach. ArchiMate

is already deﬁned using the Meta-modeling approach,

and it has a meta-model describing its abstract syntax.

It also provides two mechanisms for proﬁling: adding

attributes to ArchiMate concepts and relations, and

specialization of concepts. In our approach, we use

the specialization mechanism.

For example, Figure 1 presents concepts from the

ArchiMate technology layer meta-model (The Open

Group, 2009a): 1) Structural: InfrastructureInterface,

Node, CommunicationPath, Network; 2) Behavioral:

InfrastructureService; 3) Informational: Artifact.

These can be derived using inheritance by tele-

com IP Multimedia Subsystem (IMS) (3GPP, 2010)

speciﬁc concepts: 1) Structural: Proxy-Call/Session

Control Function (P-CSCF), PSTN/CS Gateway, Me-

dia Gateway Control Function (MGCF), Break-

out Gateway Control Function (BGCF), Applica-

tionServer, Session Initiation Protocol Application

Server (SIPAS), Open Service AccessService Ca-

pability Server (OSASCS), IP Multimedia Service

Switching Function (IMSSF), Interrogating-CSCF (I-

CSCF), Serving-CSCF (S-CSCF), Signaling Gateway

(SGW), Subscription Locator Function (SLF), Me-

dia Resource Function (MRF), Media Resource Func-

tion Controller (MRFC), Home Subscriber Server

(HSS), Media Gateway (MGW), Media Resource

Function Processor (MRFP), which are derived from

the ArchiMate Node concept, NodeInterface, Pro-

tocol, Session Initiation Protocol (SIP), Diameter,

Conﬁguration Access Protocol; 2) Behavioral: Start-

Session, Policy Decision Function (PDF), Com-

pressMessage, AuthenticateUser, SIP Request Check

(SipReqCheck), Billing, SelectCsNetwork, SelectCs-

Gate, SendLocationInfoToS-CSCF, QueryUserLoca-

tion, Forward, InformHssOfUser, ModifySIPMes-

sage, AnalyzeFilterCriteria, CheckPolicy, Analyze-

SIPRequest, ExecuteMediaRequest, which are de-

rived from the TechnologyFunction concept.

From the IMS we focused on the Core Network

Subsystem, as it contains the essential concepts. For

more details on the IMS we refer the reader to (Ca-

marillo and Garcia-Martin, 2008). We will just ex-

plain the rationale for choosing the IMS for inclusion

into the telecom proﬁle for Service Providers.

In the context of telecom service becoming more

software based, the problem of interfacing traditional

switch networks with computer networks (e.g. Inter-

net) has received an answer in the form of the IMS

architecture. All services are therefore deﬁned for the

IMS, as it provides this interface. From there on, ser-

vices are implemented in one or several types of net-

works. That is why the concerns of Service Providers

stop at the level of detail of the IMS.

Concerning proﬁle tools, we are currently extend-

ICSOFT 2011 - 6th International Conference on Software and Data Technologies

InfrastructureService

InfrastructureInterface

Node

Artifact

TechnologyFunction

accesses

assigned to

realizes

assigned to

StartSession PDF

CompressMessage

AuthenticateUser

Billing SIPReqCheck

P-CSCF

SendLocationInfoToS-CSCF

QueryUserLocation

SelectCsNetwork

SelectCsGate

BGCF

Forward I-CSCF

InformHSSOfUser

ModifySIPMessage

S-CSCF

AnalyzeFilterCriteria

CheckPolicy

AnalyzeSIPRequest

ExecuteMediaRequest

MRFP

MRF

MRFC

Pstn/CsGateway

MGCF

SIPAS

ApplicationServer

OSASCS IMSSF

SLF

HSS

SGW

MGW

Protocol

SIP DiameterCAP

NodeInterface

CommunicationPath

Network

realizes

associated with

assigned to

Figure 1: Proposed telecom extension for ArchiMate technology layer meta-model.

ing existing open source tools (e.g. Archi

graphical

editor) for ArchiMate. Archi is a free, open source,

cross-platform editor to create ArchiMate models.

Archi is developed as a plug-in for Eclipse 3.6.1 and

as such enjoys the possibilities of easy integration

with other tools developed as plug-ins.

Eclipse provides an open source platform for cre-

ating an extensible Integrated Development Environ-

ment (IDE). With the exception of a small runtime

kernel, everything in Eclipse is considered as a plug-

in. This platform allows building tools that integrate

seamlessly with the environment and other tools. We

leverage Eclipse as the framework in which we inte-

grate all tools for the telecom proﬁle.

Together with the proﬁle editor, we use in Eclipse

plug-ins to implement the proﬁle semantics. For this,

we are currently generating code to Java using Xpand

(Efftinge and Kadura, 2006). The plug-in architecture

enables us to easily add new tools (e.g. for simulating

and testing new services).

6 RELATED WORK

MEGAF (Hilliard et al., 2010) is an infrastructure for

realizing architecture frameworks. It is an extensible

http://archi.cetis.ac.uk/index.html, accessed on

13.05.2011

repository of viewpoints, views, model kinds, archi-

tecture models, system concerns, and stakeholders.

Based on a megamodeling approach, it enables the

architect to express and enforce relations between el-

ements inside an architecture description and across

architecture descriptions. However, it is a generic

infrastructure, in which speciﬁc architecture frame-

works and languages have to be deﬁned before they

can be used, while our approach starts from existing

frameworks, languages and tools, and extends them.

There are several proposals for telecom service

creation. For example, (Blum et al., 2009) describe

a Service Creation Environment based on MDE,

intended for orchestrated real-time communications

services, through a service broker, on top of Next

Generation Networks. However, their approach is fo-

cused on composition of services, while our proposal,

being based on EA frameworks and languages, offers

an overall representation of service creation.

There are several ArchiMate proposed extensions.

For example, one (Quartel et al., 2009) introduces

an extension for modeling and managing motiva-

tion, principles and requirements in TOGAF. Another

(Jonkers et al., 2010) argues for an extension for mod-

eling TOGAFs implementation and migration phases.

However, these extensions propose adding concepts

and relations in a non strictly additive manner, while

our approach is intended for strictly additive exten-

sions (i.e. proﬁles).

TELECOMMUNICATIONS SERVICE CREATION: TOWARDS EXTENSIONS FOR ENTERPRISE ARCHITECTURE

MODELING LANGUAGES

7 CONCLUSION AND FUTURE

CHALLENGES

In this position paper we proposed to answer the main

requirements of Service Providers for telecommuni-

cations service creation with a domain speciﬁc pro-

ﬁle for ArchiMate. We introduced a meta-model ex-

tension for the deﬁnition of this proﬁle. Applying a

meta-modeling approach, we are currently developing

proﬁle-speciﬁc tools (graphical editor and code gen-

eration), extending existing tools for ArchiMate.

There still remain requirements of Service

Providers that we did not yet address in this paper.

Simulating the behavior of a new service is essen-

tial to demonstrate its capabilities to decision makers.

Testing the behavior of a new service before deploy-

ment and especially its interaction with existing ser-

vices is important as well. This means that new tools

have to be integrated with those being developed now

for the proﬁle. We enable this future integration by

using a plug-in architecture, which allows new tools

to be developed and more easily integrated.

By presenting in detail the case of a telecommu-

nications proﬁle, this position paper also advocates

the need of Enterprise Architecture modeling lan-

guages for more speciﬁcity and higher degree of de-

tail at lower levels of abstraction. In the future, deﬁn-

ing Enterprise Architecture modeling language exten-

sions (proﬁles) speciﬁc for other domains may be en-

visaged. To enable it, we hope to raise awareness

among Enterprise Architecture modeling languages

tool providers about this need, so that they support

extension mechanisms.

REFERENCES

3GPP (2010). 3GPP TS 23.228 V10.3.1 IP Multimedia

Subsystem (IMS) Stage 2 (Release 10).

Alhir, S. S. (2002). A Guide to Successfully Applying the

UML. Springer-Verlag New York, Inc.

Berrisford, G. and Lankhorst, M. (2009). Using Archi-

Mate with TOGAF–Part 1: Answers to nine gen-

eral questions about methods. Via Nova Architectura,

https://doc.novay.nl/dsweb/Get/Document-101474.

Bertin, E., B´ecot, S., and Nedelec, R. (2010). Applying

enterprise architecture principles to telco services. In

14th Intl Conf. on Intelligence in Next Generation Net-

works (ICIN), pages 1–6, Berlin, Germany.

Blum, N., Magedanz, T., and Margaria, T. (2009). Rapid

service creation using eXtreme Model Driven Design

for real-time communications services on top of Next

Generation Networks. In 13th Intl Conf. on Intelli-

gence in Next Generation Networks (ICIN), pages 1

–6, Bordeaux, France.

Booch, G., Rumbaugh, J., and Jacobson, I. (2005). Uniﬁed

Modeling Language User Guide. Addison-Wesley

Professional, Reading, MA, USA.

Camarillo, G. and Garcia-Martin, M. A. (2008). The 3G

IP Multimedia Subsystem (IMS): Merging the Internet

and the Cellular Worlds. John Wiley & Sons Ltd.

Clark, T., Evans, A., Kent, S., and Sammut, P. (2001). The

MMF approach to engineering object-oriented design

languages. In Ws. on Language Descriptions, Tools

and Applications (LDTA), Genova, Italy.

Deursen, A. V., Klint, P., and Visser, J. (2000). Domain-

speciﬁc languages: an annotated bibliography. SIG-

PLAN Not., 35(6):26–36.

Efftinge, S. and Kadura, C. (2006). OpenArchitectureWare

4.1 Xpand Language Reference. Technical report.

Green, T. and Petre, M. (1996). Usability Analysis of Vi-

sual Programming Environments: A ’Cognitive Di-

mensions’ Framework. Journal of Visual Languages

and Computing, 7(2):131–174.

H˚allstrand, J. and Martin, D. (1994). Industrial require-

ments on a service creation environment. In Proc.

of the 2nd Intl Conf. on Intelligence in Broadband

Services and Networks: Towards a Pan-European

Telecommunication Service Infrastructure, pages 17–

25, London, UK.

Hilliard, R., Malavolta, I., Muccini, H., and Pelliccione,

P. (2010). Realizing architecture frameworks through

megamodelling techniques. In Proc.of the IEEE/ACM

intl conf. on Automated software engineering (ASE),

pages 305–308, Antwerp, Belgium.

Jonkers, H., van den Berg, H., Iacob, M. E., and Quartel, D.

(2010). ArchiMate Extension for Modeling the TO-

GAF Implementation and Migration Phases. Techni-

cal report, The Open Group, Catalog number W111.

Khoury, G. R. (2007). A uniﬁed approach to enterprise ar-

chitecture modelling. PhD thesis, University of Tech-

nology, Sydney.

Quartel, D., Engelsman, W., Jonkers, H., and van Sin-

deren, M. (2009). A Goal-Oriented Requirements

Modelling Language for Enterprise Architecture. In

IEEE Intl Enterprise Distributed Object Computing

Conf. (EDOC), pages 3 –13, Auckland, New Zealand.

Sessions, R. (2007). Comparison of the top four enterprise

architecture methodologies. Technical report, Object-

Watch, Inc.

The Open Group (2007). TOGAF Version 8.1.1.

The Open Group (2009a). ArchiMate 1.0 Speciﬁcation.

The Open Group (2009b). TOGAF Version 9.

TMF Forum (2008). Enhanced Telecom Operations Map

(eTOM), GB921, Release 8.0.

Urbaczewski, L. and Mrdalj, S. (2006). A comparison of

enterprise architecture frameworks. Issues in Infor-

mation Systems, 7(2):18–23.

ICSOFT 2011 - 6th International Conference on Software and Data Technologies