Modelling Languages Restrictions: A Comparative Study of ArchiMate and SOMF

Transcription

1 Modelling Languages Restrictions: A Comparative Study of ArchiMate and SOMF João Gonçalves Henriques 1, Pedro Carmo Oliveira 2 and Miguel Mira da Silva 1 1 Instituto Superior Técnico, Portugal {joaoltghenriques, mms}@ist.utl.pt 2 INOV, Portugal pedro.oliveira@inov.pt Abstract. In today s IT projects, some specialists model architectures using ad hoc modelling languages in a recurrent way. Since those languages usually do not have defined rules or meta-models, and the majority of the people involved may not know such languages, misunderstandings and problems can arise. In this paper we tried to verify if there are any limitations in two well-known modelling languages, as we believe that the restrictions of today s modelling languages may be one of the causes of the use of ad hoc languages. Keywords. IT-based services, information systems architectures, modelling languages, ArchiMate, SOMF. 1 Introduction This paper is about modelling languages and information systems architectures. Motivated by some specialists recurrent practice of modelling architectures using ad hoc modelling languages, which we believe to be a problem, we decided to analyze and check for possible limitations of the currently used ones that could explain the previously referred to problem. For this purpose we have studied and compared two well-known modelling languages, ArchiMate and SOMF, looking for limitations in modelling projects of multiorganizational integrated IT-based services. We have modelled in each of these languages four specific aspects which we think are crucial to this kind of projects. Afterwards, we analyzed the modelling artifacts in order to see if these were covered by both languages or if there were limitations in any of them. We present the lessons learned with this process and, based on the conclusions, what we believe to be good ideas for future improvements in the two analyzed languages as well as for related future work. 2 Problem We consider that the currently used modelling languages have shortcomings. Hence, such limitations might explain why some specialists use ad hoc languages for model-

2 ling their information systems architectures, instead of using the available modelling languages. For example, in SPOCS [1], a large scale European Union project, some of the produced documents do not follow any existing language, but different sets of figures and elements defined by the several project architects, which causes greater confusion and incoherence. As this can be a very broad problem to analyze, we will focus on the restrictions in modelling a specific type of project, mainly focused on multi-organizational integrated IT-based services, i.e. projects that integrate services provided by different organizations (public or otherwise). This type of project has several characteristics that make it singular from a modelling point of view. First of all, the project s main outputs are what we call IT-based services, i.e. service supported by technology, usually provided by the Internet, but not fully automated. These higher level services, however, are supported by other services, some of them fully technological ones that can also be supported by other services and so on. Thus, one of the features of these projects is the existence of multiple layers or levels of services. Another particular aspect of these projects is that they are multi-organizational. Their main goal is to integrate IT-based services from different organizations. These can be e-government organizations, integrating their different services to make them more practical and simpler for the clients, or organizations along a supply chain that join their services so as to improve their efficiency. They can also include the case of multinational or very large organizations that wish to integrate the services provided by their different departments or offices. This multi-organizational aspect is very important for it requires the integration of systems with components owned by different organizations. Any modelling of these systems should represent this incorporation so everyone in the project can have a similar architecture vision as well as the perception of who has control over what. The third important characteristic of these projects is that, since they are integration projects, they all represent a transformation of already existing systems. To integrate something that already exists requires the involved systems to develop. These same systems can already be in evolution by themselves, whether it is for the systems to be compliant with the integration or just an evolution completely disconnected from the integration project. This development should be represented in order for the stakeholders to understand how everything is at the moment and how it will be after the project s conclusion. According to [2], organized networks of organizations, i.e. clusters of organizations that cooperate, with information and communication technology support - in order to achieve efficient product development, production, and marketing tasks - are referred to as collaborative networked organizations. On the other hand, virtual Organizations are defined as sets of independent organizations sharing skills and resources to achieve a common goal [3]. Based on these definitions we can say that projects mainly focused on multiorganizational integrated IT-based services involve either virtual or networked organizations. Similarly, SPOCS can be considered a networked virtual organization, as all the involved entities form a collection of autonomous entities that behave as a single lar-

3 ger entity for the purpose of this project and they employ electronic means to transact business. 3 Related Work In order to understand if there really are limitations on today s modelling languages we analysed two well-known ones that follow different paradigms, and compared them to find out if, as we believe, they have limitations. 3.1 ArchiMate ArchiMate is an open and independent enterprise architecture modelling language. It supports the description, analysis and visualization of architectures across several business domains. It is an open standard adopted by the Open Group [4]. Being an enterprise architecture modelling language, ArchiMate focuses on the inter-domain relationships. Thus, it includes concepts for modelling both the global structure of each domain and the relations between different ones, in an easy to understand way, even for someone who is not an expert [5]. In order to be scalable, lightweight and easy to learn and understand, ArchiMate has a limited set of concepts, which follow a simple Framework that still provides a good structure for the architecture [6]. This Framework divides the architecture in three layers: business, application, and technology. In each layer the concepts are further divided into three aspects: behaviour, passive structure and active structure. Beside this distribution, ArchiMate also distinguishes between the systems external and internal views, clearly differentiating the external visible concepts, like relationships and interfaces, from the concepts and relationships that only matter internally [7]. 3.2 SOMF The Service-Oriented Modelling Framework is a service-oriented life cycle modelling methodology proposed by author Michael Bell [8]. This Framework is based on the service-oriented modelling paradigm. According to it, all software assets can be subject to modelling activities. Furthermore, all these assets are seen as services, i.e. service-oriented modelling elements, which are also evaluated by their contributions to service-oriented environments, according to its integration, collaboration, reuse and consumption capabilities. In this modelling paradigm, services are treated depending on their life cycle state, which is divided into four categories: conceptual, analysis, design and solution services. However, throughout its life cycle a service can change its category. The service-oriented modelling disciplines offer best practices, standards and policies in order to ease development activities throughout a service life cycle. Such disciplines allow us to identify in which processes the proper human resources are to be involved, such as when design and architectural artefacts, like diagrams and documents, are being produced. SOMF services fall into three categories [9]:

4 Atomic services: Fine grained services, usually indivisible software entities. Composite services: Structures that aggregate finer grain services that can be both atomic and composite. Service clusters: Group of related services, categorised by their similarities. They provide solutions to organizational problems. SOMF modelling language allows the construction of three types of models: Analysis, design, and architecture models [10]. 4 Case Study The Simple Procedures Online for Cross-border Services (SPOCS) project is a European large-scale project for interoperability in the e-government area. Its goal is to help carrying out the European Parliament services directive (2006/123/CE) [11]. The project aims at the implementation of a structure to create interoperability between entrepreneur support services from several European Union countries, so as to provide these entrepreneurs with online electronic services from any EU nation. This case study was selected because it has all the characteristics of the type of project referred to in the problem section. Being both an e-government project and a European scale project, SPOCS involves a great number of services, provided by several different organizations, including entities from different countries. It will also bring a great deal of evolutionary changes to the already existing systems of the involved organizations. In order to properly visualize and analyze these changes, the architectural modelling should represent both the As-Is and To-Be perspectives. Several applications will be developed mainly to provide technological support services. All these services will be aggregated to offer a higher level, implying several layers of services that should be properly represented when modelling the project architecture. 5 Experiments We identified four common aspects that should be represented in the architecture of this kind of project and analyzed the four parts in both SOMF and ArchiMate to check if they had limitations. These functionalities are the representation of: different evolutionary stages; services specialization; ownership of assets; and services workflows. 5.1 Simultaneous representation of different evolutionary stages In these projects we have an evolving architecture with a great number of changes occurring (but not all at the same time). Therefore, in order to have a good understanding of what will change and what is changing, it is important to represent all these alterations. We tried to represent a part of SPOCS evolving architecture in SOMF and Archi- Mate; the result was the following diagram:

5 Fig. 1. Diagrams representing evolution diagrams in SOMF and ArchiMate. In this proposition diagram for structural analysis we see that the composite service Provide Information from edirectory was decomposed from the Provide Information Service from Catalog and is now regarded as an autonomous service. Then, there is an aggregation activity involving the two now independent services and a third composite one named Provide Meta Information from MIDB, incorporating all of them into the service cluster Provide Cross-border Service Information. To model the same thing in ArchiMate we had to make two different diagrams. So in the As-is diagram, we only have the Provide Information Service from Catalog. In the To-be diagram we have the same service being aggregated into a newly created one along with other two new services. 5.2 Representation of different levels of services In modelling these projects the ability to represent several layers, or levels, of services with each layer generalizing the one below or specifying the one above is very important, because there are a great number of services that are integrated to create new higher level services. This ranges from technological low level services to business high level ones that are provided to the final costumers. Fig. 2. Diagrams representing services specification diagrams in SOMF and ArchiMate. In order to test this capability, we modelled a hierarchy of SPOCS services using SOMF and starting in the higher level service available to the end client. In the diagram obtained, the analysis service Cluster Request Cross-border License is specialized into two analysis composite services, one of them being dedicated to two other analysis services, one composite and one atomic. In the diagram obtained with ArchiMate, the Request Cross-border License service, which was regarded as a service cluster in SOMF, is now identified like a busi-

6 ness layer one. According to the ArchiMate meta-model, any instance of a given concept can be specialized into others of the same concept. So, there should not be any problem in specialising this service, however, in our understanding of the metamodel, business layer services are not the same concept as application services. Furthermore, from our study of ArchiMate, we have not found any direct relationship between different layers services. The only way we found to model this example was by connecting this service to the business processes it fulfils and join them to the application layer services they use. The application service Request License Service is further specialized in two other application services. 5.3 Representation of software assets ownership The capacity to identify the ownership of software assets is vital to any multiorganizational project like SPOCS in order to understand who owns and is responsible and accountable for the involved systems artifacts. This perspective is also important to identify budgetary challenges that may arise. We modelled three SPOCS project components, with the corresponding ownership in both SOMF and ArchiMate. With SOMF we produced the following conceptual architecture diagram (Fig.3) in which the components are displayed like packaged technological assets and the organizations that own them are shown as business domains. The ownership of the components is explained by the use of the relationship Owner of that identifies the business domains as owners of the packaged technological assets. Fig. 3. Diagrams representing ownership in SOMF and ArchiMate. With ArchiMate we represented the application components with the interfaces that execute them. We also have the actor and the roles corresponding to the business domains that own those components. However, according to the language metamodel, none of the relationships that can exist between these concepts is related to ownership. 5.4 Service workflows In a service-oriented system, the execution is mainly focused on the consumed services. In that context, we believe that the architecture of such systems should represent their workflow. We tried to model the execution flow of some SPOCS services in both SOMF and ArchiMate. In the diagram obtained in SOMF, the consumer, or client, requests the

7 Provide Cross-border Service Information composite design service. The service then routes this request to the first service of the process, the Provide Service Information Service composite design, which handles and, afterwards, directs the same request to the next participating service, and so on, until the message is sent back to the starting service. Fig. 4. Diagrams representing service workflow in SOMF and ArchiMate. In ArchiMate, instances of service can only be related to other instances through the relationships of composition, aggregation or specialization. Therefore, we could not directly model the routing of the requests between the services. Nevertheless, ArchiMate process concepts can have a trigger relationship connecting them. In addition, those processes might be associated to a service by a realization connector. So, in ArchiMate, a service workflow can only be implied through the use of process workflow, in which the processes are performed by services, and not directly represented. 6 Evaluations In this section we present the results evaluation of the four carried out experiments in order to check which aspects are covered by SOMF and ArchiMate. 6.1 Simultaneous representation of different evolutionary stages As it is possible to observe in figure 2, SOMF models relationships represent some type of change. In the diagram, we have two composite analysis services, associated by a decomposed type connector. This means that the separated service used to be a part of the original one, but was parted through a decomposing activity. At the same time, we have those two composite analysis and a third analysis composite service connected to an analysis service cluster by a generalized relationship. Thus, these composite services, that used to be independent, are now aggregated into the analysis service cluster. So, with this diagram we can see how the services used to be and how they are now, i.e. we have both an As-Is and To-Be perspective on the same diagram. From our understanding of the ArchiMate meta-model, there are no relationships similar to those. So, there are not relationships that allow different evolutionary perspectives to be represented in the same diagram. As a result, in order to develop different evolutionary stages in ArchiMate, we had to model two different diagrams, or viewpoints, one for the As-Is perspective and another for the To-Be.

8 6.2 Representation of different levels of services Based on our results we can say that both languages have the capability to represent an arbitrary number of service levels, although there are some nuances. In ArchiMate we can represent the specialization of services in lower levels. However, since business, application and technologic services are different kinds of service, if we keep specifying a business service until we get to application ones, we will have a problem in representing the distinct levels of services because there is no direct relationship between services from different layers. Hence, we have to connect the business service to the application processes it executes and, then, represent the connection between the application services and the application processes. Only through this indirect way can we represent a relationship between application and business services. The same is valid for technological services. In conclusion, we can directly represent the specification (or the opposite, generalization) of a generic layer service, if the specific corresponding services are also from the same layer. If they belong to a different layer, though, this relationship can only be implied by the use of relationships between services and processes. In SOMF we can keep specifying (or generalizing) generic services into more specific ones for an infinite number of times without any restrictions [12]. SOMF different types of services (atomic, composite or clusters) can be related amongst themselves by using specification or generalization. 6.3 Representation of software assets ownership Analyzing the produced diagrams, we can see that it is possible to represent the technological infrastructure domain of architecture both in SOMF and ArchiMate. As we can see in figure 4, there is a connector that represents that a specific business domain owns a particular software asset. However, from our understanding and analysis of the ArchiMate meta-model, the same thing is not possible in ArchiMate which is an important capability that is also absent. 6.4 Service workflows In section 5.4, we presented the results produced when we tried to represent the execution flow of some SPOCS services in SOMF and ArchiMate. Analyzing those diagrams we realized that in both languages we can represent service workflows, but while in SOMF this is done directly, in ArchiMate service workflows can only be implied. This occurs because there is no relationship similar to a trigger between services in ArchiMate, and so we cannot directly represent the workflow. Nevertheless, since ArchiMate processes can be connected by a trigger relationship, and processes can be associated to services, we are able to have an indirect representation of the workflow. In SOMF, by using Circular Beams, we can represent a direct service workflow, although this type of connector may only be used when the service workflow is circular, i.e. the last service executed routes its messages to the first performed service, that then replies to the consumer.

9 7 Lessons Learned Both analyzed languages (SOMF and ArchiMate) suffer from several limitations. We believe that it would be beneficial for architects if these limitations were addressed in future versions of both languages. Furthermore, we learnt that in ArchiMate modelling language it is not possible to represent two different evolutionary perspectives at the same time, which could be added to ArchiMate with the inclusion of relationships that imply that something has changed like the decomposed and aggregated relationships that SOMF language provides. Another drawback in ArchiMate is the lack of possibility to represent the ownership of the assets by the organization or department that actually owns them. A SOMF owner of type relationship could be considered as an addition to the ArchiMate meta-model so as to allow the ownership of assets. There are still two other aspects that we believe could be added to ArchiMate meta-model, even if they are not actual restraints. ArchiMate makes it possible to represent service workflows but in an indirect way. Then, we believe that adding some relationships like triggers between services would be beneficial for the language, since it would make it possible to explicitly represent service workflows. We also believe that it would be interesting to add to the language meta-model aggregation, composition and specification relationships between services from different layers. With this add-on, we could have a viewpoint from which visualization of the complete services hierarchy of a project is a reality. Nevertheless, considering the four analyzed aspects, SOMF only has minor limitations. We observed that it is possible to represent service workflows, but merely if we represent the involved services as connected in a ring. This may be explained because SOMF follows a service-oriented paradigm and the aspects that we focused on are important to projects dedicated to multi-organizational integrated IT-based services. This does not mean that SOMF has no other major limitations but simply means that we have not found any in the specific context of the four considered aspects. Likewise, SOMF might have major limitations representing non service-oriented projects. 8 Conclusion Both ArchiMate and SOMF have some kind of limitation when modelling projects focused on multi-organizational integrated IT-based services. Though we cannot extrapolate these conclusions to every modelling language, it is likely that the majority of current modelling languages have limitations in developing other kinds of project. When a modelling language is created with the intent of modelling a specific kind of project, it is very likely that the selected language will have restrictions in modelling other projects, as we were able to observe in SOMF that did not have any major limitations in the four aspects we analysed for the SPOCS case study. However, it is

10 ,not the ideal language to model projects that are not service-oriented, since most of its diagrams cannot be represented. If a modelling language is created to be as general as possible, like ArchiMate, it is likely that it will have limitations in some aspects that are very specific to a particular type of project. This explains the shortcomings of ArchiMate in representing the four aspects covered in chapter 5. So, considering that it is likely that all languages will have limitations, when representing a specific kind of project, then, every systems architect would have to be an expert in several modelling languages in order to choose which to use to model a particular project. As this is not a tangible possibility, we can conclude that the limitations of the modelling languages lead some specialists to use ad hoc languages in order to model their information systems architectures. A possible solution to this problem may be to keep including in more general modelling languages some concepts and capabilities from more specific modelling languages, thus reducing their limitations. Another solution to this problem could be to define a Framework with a set of criteria to help an architect decide which modelling language is the best to develop a specific project. 9 References 1. SPOCS: Single Procedures Online for Cross-border Services, 2. Lavrac, N., Ljubic, P., Urbancic, T., Papa, G., Jermol, M., Bollhalter, S.: Trusted Model for Networked Organizations Using Reputation and Collaboration Estimates. In: IEEE Transactions on Systems, Man and Cibernetics Part C: Applications and Reviews, vol. 37, no. 3, pp , (2007) 3. Plisson, J., Ljubic, P., Mozetic, I., Lavrac, N.: Ontologies for Collaborative Networked Organizations. In: Putnic, D., Cunha M.: Encyclopedia of Network and Virtual Organizations (eds.) vol. II G PR, pp , Information Science Reference, Hershey New York (2008) 4. ArchiMate, 5. Berrisford, G. & Lankhorst, M.: Using ArchiMate with an Architecture Method. Via Nova Architectura. (2009) 6. ArchiMate 1.0 Specification, 7. Lankhorst. M.: Enterprise Architecture at Work: Modelling, Communication and Analysis. Springer. (2005) 8. Bell, M.: Service-Oriented Modeling: Service Analysis, Design and Architecture. Wiley, John & Sons, Incorporated. (2008) 9. Orchel, M.: Service-Oriented Modeling Framework. 10. Truyen, F.: Enacting the Service Oriented Modeling Framework using Enterprise Architect. Cephas Consulting Group. (2010) 11. Directive 2006/123/EC of the European parliament and of the council of 12 December 2006 on services in the internal market. Official Journal of the European Union. (2006) 12. Bell, M.: SOA Modeling Patterns for Service-Oriented Discovery and Analysis. Wiley, John & Sons, Incorporated. (2010)