Gorica Tapandjieva

Requirements modeling in SEAM: The example of a car crash management system

This paper presents how business and IT requirements are captured with the Systemic Enterprise Architecture Methodology (SEAM). The method is applied to the Car Crash Management System (CMS) - Software Product Line (SPL) case study. The existing business situation is analyzed. We identify the problems and list relevant solutions. We select one of these solutions for which we define the business and the IT requirements. We then present the two components of SEAM used in this paper, goal-belief and behavior modeling. We end the paper by presenting the systemic foundations of SEAM.

Towards the Definition, Implementation and Communication of an IT Strategy: The Case of IT Strategy at EPFL

Large enterprises need to coordinate the IT initiatives that exist in different organisational units of the enterprise. If these initiatives are not coordinated, the resulting IT system is likely to become difficult to use and expensive to develop/maintain. Enterprise architecture methods are designed for that purpose. We report on the use of a service-oriented enterprise architecture method, called SEAM, in the context of a mid-size university. The originality of SEAM is its service orientation and the recursive modeling from business down to systems. Using SEAM, we develop a service model of the overall organisation. The model is stored in a web-based tool. We also propose a concrete implementation of architectural principles described in the literature. This principles help build an integrated IT system. The paper explains the background of this project and the current progresses. This approach illustrates how enterprises can build a common view for their IT resources.

Patterns for Value-Added Services Illustrated with SEAM

The basic idea behind the provision of a service is to hide the service implementation details from the client in such a way that more value is provided to the client. Very often support services allow too much of their implementation details to be visible to customers resulting in poor value proposition. In this paper we describe a project that aimed towards the requisite abstraction of the support service implementation for the research funding at the Swiss Federal Institute of Technology (EPFL). We show the current service, the problem it creates for its customers, and propose four patterns for improving the value that customers receive from a requisite service abstraction. The four patterns are: provide a simple service interface, incorporate needed external actors into the service view of the organization, recognize new customers and use data and process linking technology. These patterns are applied in a to-be model.

Business and IT Design with SEAM: An Illustration with the PhD Hiring Process at École Polytechnique Fédérale de Lausanne

Companies seek to align their business with their IT. This alignment is important to maximize the return on their IT investment in their business. One major challenge is to develop models that can be understood by both business and IT stakeholders. Without such models, it is difficult for stakeholders to reach a shared understanding and to agree on what the issues and solutions are. We present a method called SEAM: it uses a systemic approach for representing business and IT organizations. With SEAM, stakeholders can quickly develop an understanding of the problem and gain knowledge on how to address it. This improves the success rate of business and IT projects.

Ontology for SEAM Service Models

A service system is a popular concept in academia and industry. At the same time, it is a challenging concept to represent, due to its recursive nature and difficulty to relate it to entities in reality. In this paper we present an ontology for modeling service systems using the SEAM systemic method. Our ontology represents an updated and minimalistic version of the existing SEAM service modeling language that puts an emphasis on the behavior. The research approach we used is the design science for information systems research and it resulted with the ontology artifact. As part of the ontology, we provide a meta-model, well-formedness rules and formalization in the Alloy language. We conclude with presenting the limitations and a brief discussion on the contribution of shifting the focus towards the behavior in service systems.

A Return on Our Experience of Modeling a Service-Oriented Organization in a Service Cartography

We present a longitudinal project using action design research, which is a four-year collaboration between two EPFL entities: The research Laboratory for Systemic Modeling (LAMS) and EPFL’s IT department, called the VPSI. During that time the VPSI was going through a transformation into a service-oriented organization. The research project began as an open-ended modeling of some of the VPSI processes. It slowly matured into the design and development of a visualization tool we call service cartography. During this research, we learned that, to successfully apply service-orientation, focusing purely on IT architecture and end-customer value is not enough. Attention must be given to the exchange of internal services between the service organization members and their alignment with the services expected by the external stakeholders. In this paper we present the evolution of (1) our understanding of what services are, and (2) our conceptualization of how the service cartography facilitates the service-oriented thinking.

IT Service Alignment Verification of Quantitative Properties in Service Design

Despite many years of research, alignment of business and IT services remains a challenge. In this paper we show how to verify the quantitative properties of a service against stakeholder requirements during service design. We model the service with the Systemic Enterprise Architecture Method (SEAM). This allows us to specify the service alignment constraints with what we call a feasibility constraint. We translate the SEAM model into Scala code, where the feasibility constraint is mapped to a constraint of a Scala function. We then check the Scala functions verification condition with the Leon verification tool. An alignment is achieved if no counterexample is found. If a counterexample exists, it allows to detect which service component is at the source of the misalignment.