and First Workshop On the Globalization of Modeling Languages (GEMOC 2013) Benoit Combemale and Julien De Antoni and Robert B. France and Frederic Boulanger and Sebastien Mosser and Marc Pantel and Bernhard Rumpe and Rick Salay and Martin Schindler : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 3 AMINO 2013 Towards the Model Driven Organization Introduction to the 1st AMINO Workshop Balbir Barn, Tony Clark, Robert France, Ulrich Frank, Vinay Kulkarni, and Dan Turk : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 14 Goals, Domains, and Enterprise Architecture in the Model-Driven Organization Desmond DSouza : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 18 Multimodel-Driven Software Engineering for Evolving Enterprise Systems Richard F. Paige, Radu Calinescu, Dimitrios S. Kolovos, Nicholas Matragkas and Dave Cli : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 23 UML/OCL based Design and Analysis of Role-Based Access Control Policies Oliver Hofrichter, Martin Gogolla, and Karsten Sohr : : : : : : : : : : : : : : : : : : : 33 Meta-model Patterns for Expressing Relationships Between Organization Model Concepts and Software Implementation Concepts Jens Gulden : : : : : : 43 MDE Support for Enterprise Architecture in an Industrial Context: the TEAP Framework Experience Hugo Bruneliere, Jordi Cabot, Stphane Drapeau, Flavien Somda, William Piers, Juan David Villa Calle, Jean-Christophe Lafaurie : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 53 Introducing Argumentative and Discursive Enterprise Leading and Management Sebastian Bittmann, Balbir Barn, Tony Clark, Oliver Thomas : : : : : : : 59 (Multi-) Modeling Enterprises for Better Decisions Sagar Sunkle, Vinay Kulkarni, and Hemant Rathod : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 69 Enterprise Models as Drivers for IT Security Management at Runtime Anat Goldstein, Sietse Overbeek : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 79 First Workshop On the Globalization of Modeling
Languages (GEMOC 2013) ?
Benoit Combemale1 and Julien De Antoni2 and Robert B. France3 and Frédéric Boulanger4 and Sébastien Mosser5 and Marc Pantel6 and Bernhard Rumpe7 and Rick Salay8 and Martin Schindler9 1 University of Rennes 1, France 2 University of Nice Sophia Antipolis, France 3 Colorado State University, USA
4 Supélec, France 5 Polytech’Nice Sophia Antipolis, France
6 INPT ENSEEIHT, France 7 RWTH Aachen University, Germany 8 University of Toronto, Canada
9 MaibornWolff, Germany Abstract. The first edition of GEMOC workshop was co-located with the MODELS 2013 conference in Miami, FL, USA. The workshop provided an open forum for sharing experiences, problems and solutions related to the challenges of using of multiple modeling languages in the development of complex softwarebased systems. During the workshop, concrete language composition artifacts, approaches, and mechanisms were presented and discussed, ideas and opinions exchanged, and constructive feedback provided to authors of accepted papers. A major objective was to encourage collaborations and to start building a community that focused on providing solutions that support what we refer to as the globalization of domain-specific modeling languages, that is, support coordinated use of multiple languages throughout the development of complex systems. This report summarizes the presentations and discussions that took place in the first GEMOC 2013 workshop.
Modern software-intensive systems serve diverse stakeholder groups and thus must address a variety of stakeholder concerns. These concern spaces are often associated with specialized description languages and technologies that are based on concern-specific problem and solution concepts. Software and system engineers are thus faced with the challenging task of integrating the different languages and associated technologies used to produce various artifacts in the different concern spaces.
GEMOC 2013 was a full-day workshop that brought together researchers and practitioners in the modeling languages community to discuss the challenges associated with integrating multiple, heterogeneous modeling languages. Supporting coordinated use ? This workshop is supported by the GEMOC initiative (http://gemoc.org) and the ReMoDD initiative (http://www.cs.colostate.edu/remodd) of modeling languages leads to what we call the globalization of modeling languages. The languages of interest for the participants ranged from requirements to runtime languages, and included both general-purpose and domain-specific languages. Challenges related to engineering composable languages, semantic composition of languages and to reasoning about systems described using heterogeneous languages were discussed
The workshop GEMOC 2013 was co-located with MODELS 2013 in Miami, FL, USA, on September 29th, 2013. In this report we document the various presentations, as well as the enthusiastic and intense discussions that took place during the workshop. The workshop report is organized as follows. Section 2 gives a broad overview of the workshop, including the topics of interest and relevant application domains. Section 3 describes the paper review and selection process, and the structure of the workshop. Section 4 summarizes the presentations made in the first half of the workshop day. Section 5 then presents the main points raised in the discussions that followed the presentations. The intent of the discussions was to position each presented approach in a language and model composition landscape. An initial global landscape was introduced and discussed in the second half of the workshop day. The results of that discussion are summarized in Section 6. Conclusions are drawn in Section 7. 2
Software intensive systems are becoming more and more complex and interconnected. Consequently, the development of such systems requires the integration of many different concerns and skills. These concerns are usually covered by different languages, with specific concepts, technologies and abstraction levels. While the use of multiple languages eases the development of target concerns, it also raises language and technology integration problems at the different stages of the software life cycle. In order to reason about the global system, it becomes necessary to explicitly describe the different kinds of the relationships that can exist between the different languages used in the development of a complex system. To support effective language integration, there is a pressing need to reify and classify these relationships, as well as the language interactions that the relationships enable.
In this context, the workshop attracted submissions that include outlines of language integration approaches and case studies, or that identify and discuss well-defined problems about the management of relationships between heterogeneous modeling languages. The goal was to facilitate discussions among the participants that lead to an initial classification of useful kinds of language relationships and their management.
The Call for Papers explicitly solicited contributions that describe case studies on coordinated use of multiple modeling languages, and/or practical experience, opinions and related approaches. Authors were invited to submit short papers describing (i) their language integration experience, or (ii) novel approaches for integrating modeling languages. Authors were also invited to store full versions of models used to illustrate their novel approach or experience in the Repository for Model Driven Development (ReMoDD). This allowed us to share the actual models with participants and the wider modeling community before, during and after the workshop.
The topics of interest for GEMOC 2013 was: – Composability and interoperability of heterogeneous modeling languages – Language integration challenges, from requirement to design, to analysis and simulation, to runtime. – Model and metamodel composition – Multi-paradigm modeling and simulation
Submissions describing practical and industrial experience related to the use of heterogeneous modeling languages were also encouraged, particularly in the following application domains: – Cyber-Physical Systems, System of Systems – Smart City, Smart Building, Home automation – Complex Adaptive Systems – Internet of Services, Internet of Things 3
Benoit Combemale, Julien Deantoni and Robert B. France organized and chaired the program committee (PC) for this GEMOC edition. The workshop website10 and the call for papers (CfP) was online, quite 6 months before the workshop date. Apart from the workshop website, the CfP was announced on different professional mailing lists (e.g., SEWORLD, pUML, planetmde).
We received 11 submissions and finally accepted 8 papers, resulting in an acceptance rate of 72%. Each submission was reviewed by at least three members of the PC. Papers were selected based on their relevance to the topics for the workshop and the reviews provided by PC members. The organizers are very grateful to PC members for performing this important service to the community and for the quality of their work. The PC consisted of: Walter Cazzola, (DICo, University of Milano, Italy), Benoit Combemale (University of Rennes 1, France), Julien DeAntoni (University of Nice Sophia Antipolis, France), Robert B. France (Colorado State University, USA), Jeff Gray (University of Alabama, USA), Jean-Marc Jézéquel (University of Rennes 1, France), Jörg Kienzle (McGill University, Canada), Marjan Mernik (University of Maribor, Slovenia), Pieter J. Mosterman (MathWorks, USA), Gunter Mussbacher (University of Ottawa, Canada), Bernhard Rumpe (RWTH Aachen University, Germany) and Eugene Syriani (University of Alabama, USA).
The format of the workshop reflected the goals of the workshop: To provide constructive feedback on submitted papers and models on the coordinated use of different modeling languages, and to foster collaborations and community building. The format of the workshop was that of a working meeting. Hence, it was less focused on presentations and more on producing and documenting a research roadmap that identifies challenges, different forms of language integration, and relates existing solutions.
The workshop day was split into two parts. In the first part, an introduction and short presentations of the accepted papers were given. The second part of the day was dedicated to open discussions of the presented contributions and other related topics. We lead the discussion towards a classification of existing and proposed forms of language integration. This workshop report is the result of the beneficial discussions we had. 10 Cf. http://gemoc.org/gemoc2013
The papers and the associated talks are available on the workshop web pages (http:
//www.gemoc.org/gemoc2013). The associated models are available in the ReMoDD
repository (http://www.remodd.org).
[
An important part of the workshop was dedicated to discussions on how to realize the vision of globalized modeling languages. The aim was to map out a landscape of language and model composition issues that reflected ideas raised in the previous presentations and the experiences of workshop participants. To structure the discussions, the organizers proposed to follow the Why? What? Where? How? pattern as reported in the rest of this section. 5.1
Why?
Composition of models is highly desired, because the history of computer science has
shown that development can only be managed by dividing a complex task or
product into smaller easier sub-structures. This in particular holds for models which we
like to decompose along sub-structures of the product, e.g. into components [
When different viewpoints are modeled in different languages, model composition
also becomes language composition, where models of different languages need to
become interoperable. This is necessary for example for the UML, where structural and
behavioral models describe the same system, but also in the recently emerging and
potentially more interesting domain of distributed systems, where several different, but
similar languages are used to describe the behavior of system components [
We can identify four main reasons for using models written using different formalisms: – The decomposition of a complex system into different parts that belong to different technical domains which have their own modeling formalisms and tools; – The change in the level of abstraction during the design of a system, for instance from a non-deterministic automata for specification, to VHDL for the concrete realization; – The need for different models of a system that model different aspects, or offer differents views on the system and therefore use different modeling formalisms: the timing or power consumption model of a system may use a different formalism than the functional model; – The need for different models of a system for different activities during the design process: a model used for code generation and a model used for verification may use different formalisms.
– How does one compose the structure and behavior of heterogeneous models? – How does one check that a model is a refinement of a more abstract model? – How does one synchronize different views on different aspects of a system? – How does one check the consistency of different models of a given system?
Only if these forms of composition are well understood will we be able to carry out integrated code generations, simulations, validations and verifications on integrated models. These composition issues are rooted in the semantics of the models, with the added complexity of the definition of a mapping between concepts that belong to different semantic domains and are represented according to different syntaxes.
Even though the composition of models and languages is somehow related to the forms of composition for products, we need to be explicitly aware that these are different forms of compositions. That is why it is necessary to explicitly clarify what the composition is about. In particular, it would be very nice if a specification formalism provides a composition operator for its specifications in such a way that this composition conforms to the composition of the specified components.
Identifying the relationships that exists between different languages is useful to
support the understanding of language composition, from a systemic point of view [
Additionally, besides the technical forms of composition, the ability to compose has also an organizational consequence. If we can compose individually developed models, we can decompose the team into smaller sub-teams developing individual parts. This is why composition of models is an important requisite for successful projects developing complex products. 5.2
Formally, composition is an operator taking at least two arguments and producing one
result. Model composition thus involves manipulation of models. Each model has a
syntax and a semantics. Composition can operate on the syntax, for example deriving an
integrated new model describing the information originally contained in both models
[
Furthermore, since models are developed incrementally across the development
lifecycle and at different rates in different sub-teams, requiring models to be complete
before composition can cause project delays. To address this we must also allow for
the meaningful composition of partially complete models [
Relying on an existing classification of existing composition supports the identification of the elements to compose during the process of designing a given composition. One can rely on the existing relations to guide its own development and support incremental approaches. The fact that a language L “implements” concepts modeled by a language L’ implies that both elements (the concept to be implemented in L’ and its associated artefacts in L) exists at the time of the composition, even if developed asynchronously. On the contrary, if L “uses” elements from L’, one cannot use L to work while the model in L’ is not complete.
These considerations hold for any kind of modeling languages, structural or behavioral. However, from a practical point of view, in a top-down approach we develop structure first and thus need decomposition on structure on the higher level. Typically behavioral aspects are only modeled and thus composed on a more fine-grained details level in the later phases of the development. On the other hand, a bottom-up approach involves composing already developed parts of a system to produce a complete system. However, in bottom-up approaches, the composition is usually made at the model level by making interoperable homogeneous interfaces and usually do not address composition of syntactic elements. 5.3
We outlined in the previous section how the composition can operate on different parts
of languages and models. It is also interesting to note that the composition can be
specified and applied at different level: From the language level to some compiled code.
Additionally, the specification of the composition and its application can also be done
at different levels. For instance, a composition operator can be specified between two
languages in order to create a new language [
This also includes their resulting infrastructure, for example, lexer, parser, symbol tables, or editors. For an efficient and agile composition of existing languages, these aspects should be reused as much as possible and only a minimal amount of additional glue-code should be necessary. The level at which the specification and the application of the composition is realized depends on the main objective of the composition (i.e. the why). For instance, because the semantics of a language combination has to be considered, the composition is preferably defined on the language level. However, in a reuse perspective the linkage should take place as late as possible to be able to provide the same language component for different compositions. The idea behind this is the same as for framework or libraries in programming languages which can be used as precompiled components without providing the sources. This speeds up the development process significantly as the libraries do not have to be compiled again and again for every usage while it restrains the possibility of analysis of the composed system. 5.4
How? In order to be able to compose different languages and models without developing the languages for each combination from scratch again or specifying the matching parts for each model combination we need a concise and consistent definition of the interfaces of languages and models. An approach similar to that used in existing programming languages, where methods or classes have an interface for its usage encapsulating the complexity of the actual implementation, may be applicable. If languages provide interfaces that hide their internal complexity, a library of language components could be created allowing the composition of languages by writing a minimal amount of gluecode for each combination.
The need for an interface holds for models as well. Each model should provide an
interface which can be used from other models without knowing the internal details
[
By using such approaches, a composition of languages can be reduced to a mapping between the language concepts needed to combine models along their interfaces. Only if the existing language concepts are not sufficient to define such a mapping, an extension of one or both languages is needed for the composition.
And finally the composition of the language tooling have to be considered. However, if all of these aspects are implemented using clear interfaces, the composition could be derived from the already defined mapping of the language concepts even automatically.
When only partial information is known about a model, techniques such as model
synthesis can be used to construct an approximate, but well-formed, model based on
the known information. Such approximate models can be used as stand-ins for partially
complete models in composition operations [
The various criteria about compositions lead to various implementations. Such
implementations can be hard coded [
The first edition of the workshop met its goals and thus can be considered a success. The discussions that took place during the workshop were of very high quality and provided insights into some of the pressing problems associated with the use multiple modeling languages in development projects. A key result is a deep appreciation by the participants of the need to develop support for globalizing modeling languages. The ongoing research that was reported in the workshop and the discussions that took place are a good indication that community around these problems is emerging. For more information about the GEMOC initiative please visit the following website: http: //gemoc.org. 7
GEMOC 2013 was supported by the GEMOC initiative (cf. http://gemoc.org) that promotes research seeking to develop the necessary breakthroughs in software languages to support global software engineering, i.e., breakthroughs that lead to effective technologies supporting different forms of language integration, including language collaboration, interoperability and composability. Part of this initiative, the workshop was partially supported by the ANR INS project GEMOC (grant #ANR-12-INSE0011).
GEMOC 2013 was also supported by the ReMoDD project, an NSF funded project (award number CNS-1305381).
Towards the Model Driven Organization Introduction to the 1st AMINO Workshop Held at the ACM/IEEE 16th International Conference on
Model Driven Engineering Languages and Systems
MODELS 2013 Miami Florida USA Balbir Barn1, Tony Clark1, Robert France2, Ulrich Frank3, Vinay Kulkarni4, and Dan Turk2 1 Middlesex University, London, UK 2 Colorado State University, Colorado, USA 3 Universty of Dusibirg-Essen, Essen, Germany
4 Tata Consultancy Services, India
Organizations such as banks and public sector institutions can be thought of as being structured in three key layers. The strategic layer defines what an organization must achieve in terms of its high-level goals, the tactical layer defines how an organization plans to behave and thereby achieve its goals, and the operational layer defines the day-to-day running of the organization in a manner that is consistent with the organization’s plans. The operational layer of a modern organization is implemented in terms of a collection of inter-connected IT systems that form an organizational platform. An organization seeks to align its high-level goals with its platform so that its strategy is properly supported by its IT infrastructure. Expressing and achieving alignment remains a key challenge for modern organizations.
Essentially organizations exist to accomplish specific goals. In the case of a not-for-profit organization, the goals are often expressed as a mission statement. In the case of a for-profit organization, the mission should also include achieving profit for investors. Frequently these goals are not consciously or explicitly written down or even clearly recognized. But, even so, they still exist. Whether goals are explicitly identified and documented or not, organizations wish to know whether the goals are achieved and, where possible, concrete metrics may be used to help answer these questions.
Whilst top-level organizational goals can often be captured as relatively simple mission statements, the internal processes, resources, IT systems and structures that are put in place to realise the goals are usually highly complex. Measuring aspects of a typical large multi-national corporation in order to determine its internal consistency, to measure quality metrics, to perform any number of change-based activities, and ultimately to establish consistency between the organizational goals and the human- and IT-centric processes by which it operates, is a difficult task.
In the field of software system development, it is accepted that various forms of modelling need to be brought to bear on the problem of measuring complex system properties, controlling its behaviour and to establish that an implementation satisfies its specification. The key feature at play is abstraction where unnecessary detail is elided leaving important aspects of a system to be represented in a language that is suitable for the stakeholders and exhibits appropriate properties for reasoning, transformation, simulation etc. Our claim is that the same use of abstraction through modelling can be applied to the problems of managing an organization, leading to the idea of a Model-Driven Organization: Def: A Model-Driven Organization (MDO) is an institution that uses models, both formally and informally, in conscious and intentional ways, throughout the organization to define who it is and what it does, to help better and more quickly train employees, to carry out, assess, and improve its functioning, and to more effectively develop and modify systems that support the organization.
The use of models in system development has established the fields of Model Driven Architecture (MDA) and Model Driven Engineering (MDE). Although these fields use models as abstractions of systems in order to establish properties, they predominantly use models to help with system construction during the design phase. In some cases part or all of the program code for a system is generated from models.
Although MDA/MDE may be viewed as providing a contribution, the MDO vision is much broader than system development. An MDO uses models at multiple levels: Organizational level models, not just system / software level models; conceptual, as well as technical models; strategic, tactical, and operational models. MDO models relate to much more than just the IT systems of an organization and need not be expressed in a formal language. The models must address people-centric aspects of an organization in addition to the systems-level aspects. We can see this by comparing the definition of the MDO as given above, with the following two common definitions for MDE and MDA:
Def: Model-Driven Engineering (MDE) is a software development methodology which focuses on creating and exploiting domain models (that is, abstract representations of the knowledge and activities that govern a particular application domain), rather than on the computing (or algorithmic) concepts.
Def: Model-Driven Architecture (MDA) is a software design approach for the development of software systems. It provides a set of guidelines for the structuring of specifications, which are expressed as models. Modeldriven architecture is a kind of domain engineering, and supports modeldriven engineering of software systems. It was launched by the Object Management Group (OMG) in 2001.
Our claim is that a model-based approach can be used in many ways within an organization. Models can be used to describe the organization itself, its structure, its processes, its business rules, its regulatory constraints, etc. This can help in a wide variety of organization-centric use-cases including training new employees and helping outsiders better understand and effectively interact with the organization. These models may be able to help potential investors compare organizations, or even make it easier to merge organizations. They may make it easier to compare the functioning of organizations, or systems within organizations, to allow decision-makers to better determine which parts of merged organizations to keep and which to eliminate after a merger takes place, for instance. Models may be used to help in the analysis of an organization, to determine and clearly identify its mission, and assess how well it is meeting its goals.
If the models are formalized and automated, it may be possible to ease and/or automate some types of changes within an organization. And, of course, models have had a long history of helping to automate parts of organizations.
Achieving the MDO vision will involve expertise from many different disciplines. Experts in modelling will be required to design suitable languages both domain-specific and general purpose using appropriate meta-technologies. Expertise in model processing including transformation, synchronization and model-checking will be required. Experts in the field of Organization Theory will be required to understand the structures and processes to be modelled. Information Systems experts will be required to analyse and represent the ontologies and complex data used within an organization. Management theorists will be required to understand the human-centric aspects of the problem and where models can be used to facilitate all stakeholders. Experts in tools will be required to determine how to offer the features of the MDO in an effective way.
The goals of the AMINO workshop are to work towards a better understanding of where models can be used to address all aspects of organizational development, operation and management use-cases. The workshop took the form of an invited speaker and presentations of 7 peer reviewed papers. The rest of this introduction provides an overview of the presentations.
In Goals, Domains, and Enterprise Architecture in the Model-Driven Organization Desmond D’Souza argues that goal models are fundamental to achieving the MDO. He presents a notation and method for incremental model construction in terms of goals and their constraints over domains. The paper concludes by indicating how goals can be exploited in other MDO areas including architectures and migration plans.
In Multimodel-Driven Software Engineering for Evolving Enterprise Systems Richard Paige, Radu Calinescu, Dimitrios S. Kolovos, Nicholas Matragkas and Dave Cliff address the issue of organizational evolution and how to analyse the Quality of Service (QoS) issues that arise. The paper proposes a multimodeldriven approach (MMSE) and concludes with some thoughts about a research agenda that will lead to solutions in this area.
Organisations consist of many different roles that link to business processes and provide access to information at various security levels. In UML/OCL based Design and Analysis of Role-Based Access Control Policies Oliver Hofrichter, Martin Gogolla, and Karsten Sohr discuss an approach to modelling the access control and use OCL to address a case study based on EasyChair.
As discussed above, a key feature of the MDO is goal-IT alignment. In Metamodel Patterns for Expressing Relationships Between Organization Model Concepts and Software Implementation Concepts Jens Gulden discusses this issue and provides patterns for mapping between the two levels.
The state-of-the-art in Enterprise Modelling and Enterprise Architecture uses enterprise frameworks to represent and reason about aspects of an organisation or even its entirety. Few of these frameworks use modelling technologies and techniques. In MDE Support for Enterprise Architecture in an Industrial Context: the TEAP Framework Experience Hugo Bruneliere, Jordi Cabot, Stphane Drapeau, Flavien Somda, William Piers, Juan David Villa Calle and Jean-Christophe Lafaurie describe a new framework called TEAP that applies Model Driven Engineering techniques to the construction of an enterprise framework.
In many ways organisations are more complex that standard software systems and the structures, information, resources and processes involved are less precise. Therefore it is important to understand the reasoning behind design decisions and the reasons for organisational change. In Introducing Argumentative and Discursive Enterprise Leading and Management Sebastian Bittmann, Balbir Barn, Tony Clark and Oliver Thomas develop this theme in terms of argumentation theory as a basis for recording the intentions behind organisation-related actions.
There are many different organizational use-cases involved in achieving an MDO. One is mergers and acquisitions whereby two organisations become one. In (Multi-) Modeling Enterprises for Better Decisions Sagar Sunkle, Vinay Kulkarni, and Hemant Rathod argue that in order to represent and reason about such complex use-cases it is necessary to use multi-models.
The MDO is likely to involve the use of models in many different ways. Some of these may simply be to help understand the organisation, but others may help to operationalise it. In Enterprise Models as Drivers for IT Security Management at Runtime Anat Goldstein and Sietse Overbeek discuss the technique of models@Runtime and its use to achieve IT security.
Goals, Domains, and Enterprise Architecture in the Model-Driven Organization Desmond D’Souza Kinetium, Inc.
www.kinetium.com In a Model-Driven Organization (MDO), all aspects of planning, designing, implementing, deploying, operating, and evolving the organization and its supporting infrastructure are based on models. Goals form an anchor for other models in an MDO. This paper is a summary of my keynote talk at AMINO 2013 in Miami, Florida, in which I covered a variety of ways to use Goal Models as a recurrent focal point to improve model coherence in an MDO.
Goals, Domains, and Refinement A goal is a property desired over a domain. In Figure 1(a), a goal of the Golden Gate Bridge is shown with a green circle G1: Get vehicles from A to B i.e. given some domain property about the inflow of vehicles at A, establish a corresponding outflow at B. A goal is anchored to domain elements that are its subject matter, and evaluates to true or false over any domain instance. G1 is anchored at endpoints A and B, controlling outflow based on inflow. A dashboard wired to the anchor points can, in principle, monitor the goal.
Inflow A
Goal G1: Get vehicles from A to B
B Outflow
Why? What? Vehicle Inflow
A
B How? “Bridge”
Refinement Roadway
Suspensions (b) Goal and domain refinement.
A goal refinement consists of sub-goals and domain properties that, combined, satisfy a parent goal across its end-points. The bridge refinement (small white circle in Figure 1(b)) moves inflow from A to B via a roadway, supported by cables suspended from columns built on bedrock, and establishes sub-goals for each of these based on their mutual load and support properties, bedrock properties, and inflow. Domain properties (yellow rectangles) are facts or assumptions about the domain, also anchored on domain elements. A goal can have alternative refinements: G1 can be met by a bridge-refinement or a ferryrefinement. Choosing one or the other uncovers different domain properties: bedrock strength is vital for bridge columns, and bay currents is for a ferry, while inflow and outflow is part of the problem context of G1 itself and common to both. When analyzing any part of a goal model, only certain refinements apply, and the corresponding domain model is composed from the domain properties of all applicable refinements. Goal refinement, domains, and architecture choices are intrinsically intertwined.
The domain model can range from a simple average vehicles-per-hour, to a detailed “film-strip” with individual vehicles moving along the bridge. Goals are predicates over that model, and evaluate to true or false on a domain instance. An objective associated with a goal can quantify how well the goal is met, based on measurable domain attributes and often in an aggregate sense.
By making intention explicit, goals answer some key questions (Figure 1(b)): 1. What are we trying to accomplish? The goal specification, G, with end-point domain elements, gives a precise success criteria over any domain instance. 2. Why do we want to accomplish G? Refinement answers this in the form: because if we meet G, given additional domain property X and assuming we meet other sibling goals, then in concert we meet the higher level goal. 3. How will we accomplish G? Examine the refinement of G and follow the “line of reasoning” through its domain properties and sub-goals. 4. How well does refinement R1 meet G? Provided all children of R1 can be expressed in a sufficiently detailed form, evaluate G’s objective function against domain instances assuming that all the sub-goals are met.
Monitoring a goal is clearly useful, but assumed domain properties are also candidates for monitoring. As a secondary goal, the bridge should accommodate shipping traffic, which introduces assumptions about ocean level and ship height, and goals about minimum roadway height (Figure 2(a)). The assumptions can be monitored, as changes could jeopardize a goal. In the larger feedback loop of an extended enterprise with its environment, assumption tracking must happen in some form, whether proactive or reactive. From A to B Traffic
Ship Height fact or assumption
Domain
Element
Goal models can be federated. Figure 2(b) shows federated goal models for the bridge, suspension, and columns. Note that each goal “frames” a problem; goals and end-points must align from child to parent goal model; one model’s assumption can be (or otherwise depend on) another model’s goal; and goal models have different projections of shared domains. Since dependencies are between properties of domain elements and not directly between elements, value, risk, and impact can be assessed in terms of affected properties.
If the underlying domain fits within a governance structure, goals can be extended with strategic dependency relations between the person desiring the goal, the one responsible for meeting the goal, and the one with authority over any domain element needed in refining the goal.
Goals, Architecture, and Architecture Style
An architecture of a system is a model describing system properties to be understood and analyzed together. Architectural components are part of the domain model. Goals and domain properties demarcated by refinement define “together”-ness and are part of architecture. The "ends" in “end-to-end architecture” are precisely framed by goals.
Functionality 1: Problem Domain – factories, supplies, warehouses, partners, existing systems 6: Goals and Domain Model have paralel refinement, to granular goals and components 2: Goal - Factories supplied just in time from supplier warehouses 7: Multiple concerns: functionality, security, performance, technology… Security
Performance
Technology
… 3c: deliveries made deliveries
Factory Supply Optimizer scheduler
predictor production load predictions supply scheduling 5:Applications, Components, Connectors – specifications for each one – end-to-end satisfaction of goals 3a: track inventories 4: Scope of sub-goals get narrower.
Some assigned to components.
supplier inventory 3: Refinement to sub-goals + domain properties on subdomains 3b: predict production load, optimize supply schedule
Goals are desired properties Desired Properties and Given or Assumed Properties can be in terms of: active structure, behavior, passive structure/ information
Properties of Concern can be about functionality, security, performance, manageability, etc.
Span of interest: boundary of a box, or its outsides, or its insides: model Component-Port-Connector
Figure 3(a) Example of fractal refinement. 3(b) Scheme for fractal goals with architecture. relation were adapted. Therewith a self service business process was added with reference to those services that won’t necessarily benefit from human interactions.
Fig. 4. Aligned Enterprise Architecture based on Strategic Arguments on a Conceptual Layer 5
Conclusion With the presented approach, a manner of enterprise architecture management was introduced that uses a form of argument for purposefully managing the evolution of the enterprise architecture in order to enable the purposeful alignment with the overall enterprise strategy. With the use of arguments a misalignment between the strategy and the enterprise architecture becomes identifiable with a concretisation of the actual artefacts by means of their design directives. Thereby, design decisions of artefacts can be supported by their underlying rationale derived from the strategic directives. As on first sight, strategic steps seem in harmony, later on, a misalignment can be revealed based on a more complete specification. With having the design decision’s rationale the adaptation as well as the alignment of the respective artefacts can become more directed and contributing. Additionally, the approach supports bottom-up and middle-out, next to rather strategic top-down, implementations and thereby, is able to return developed insights to the overall strategy of the enterprise. (Multi-) Modeling Enterprises for Better Decisions
Sagar Sunkle, Vinay Kulkarni, and Hemant Rathod
Tata Research Development and Design Center
Tata Consultancy Services 54B, Industrial Estate, Hadapsar
Pune, 411013 INDIA {sagar.sunkle,vinay.vkulkarni,hemant.rathod}@tcs.com Abstract. Enterprises typically depend on past experience and human expertise for responding to changes. This is no longer cost effective in the increasingly dynamic world of enterprises. Enterprise models are required that describe the enterprise as well as prescribe courses of action in the face of change. Owing to complexity of enterprises, multiple models need to be employed when addressing specific problems. Toward this end, we present an approach that uses number of specialized models focused on decision making. Our contributions are- first, we show how these models can be used in concert and second, we present how these models can be used in a real world case study of merger of two enterprises. Our ongoing research suggests that in spite of several challenges, this approach provides promising first steps toward enabling enterprises in responding to changes with more certainty. 1
For the past 17 years, we have helped 70+ enterprises in their IT automation efforts. In recent times, we have witnessed that the need for automation and its actual realization in an enterprise is driven by multiple change drivers in various dimensions. Modern enterprises display a characteristic connectedness between these dimensions; change in any one dimension affects the others. Our experience suggests that lack of enterprisewide context that encompasses all dimensions, is the key cause of enterprises’ inability to change cost effectively.
This led us to posit that a model of enterprise is needed that is capable of
catering to all relevant dimensions of enterprise while being machine processable and
analyzable [
The paper is arranged as follows. Section 2 motivates the need for multiple kinds of models of an enterprise and based on our experience and investigation puts forth the kinds of models needed for better decision making. Section 3 describes how we are applying the proposed approach to a real world M&A case study. Section 4 concludes the paper. 2
Enterprises are complex systems of systems and responding to change is extremely
cost-, time-, and effort- intensive [
As far as IT systems are considered, enterprises use them in particular to derive
mechanical advantage through automation of operational processes catering to their
strategic, tactical and operational goals [
In general, management relies solely on expert judgment about how to tackle changes
across dimensions of enterprise and in particular resolving issues pertaining to IT
systems. Our take on this is it is better to make machine-processable and analyzable models
of enterprise as a whole as well as of its key parts that are respectively descriptive and
prescriptive in nature [
In using models for better decision making in enterprises, we need models that act as inventories of all relevant information, i.e., models that are descriptive. An ArchiMatebased enterprise model that captures information about business, IT, infrastructure entities and relations while conforming to ArchiMate metamodels would be such a model. We also need models that can use such information and prescribe course(s) of actions based on some criteria. This core distinction is at the basis of several kinds of models we are proposing for better decision making in enterprises as shown in Figure 1. 1 2 3 4 5
EA-based EA-related Non EA-related Enterprise Model Enterprise Goal Decision Making
Model Model
Non EA-related IT IT Plant
Plant-specific Implementation Decision Making Model
Model Interconnected Dimensions of Enterprise [what and how]
Goals and sub-goals of
Enterprise [Whys]
Fig. 1: Different Kinds of Models Required for Better Decision Making in Enterprises
EA-based Enterprise Model(s) In Figure 1, 1 shows an enterprise model that
should be based on an enterprise architecture (EA) framework. This is a descriptive
model that inventories the information about key dimensions of an enterprise. This
model can be queried for stakeholder-specific information and can also be used for
some informative analyses pertaining to given EA framework. Our initial results in
creating such a model were presented in [
Business IT Infrastructure n iIftrao m o n rehO t
Concepts + Relations itrrseepnSuNfeficceiessnatrDyeatnadils lzyaanA liaaunpM lEaeRAnalysis Results leb l+eb Reasoning l
Consistency Concept Queries Rules Checking Satisfiability isu tEn gn rep EA nO irs -b ltgyo eedoM saed o
Fig. 2: EA-based Enterprise Model using Ontological Representation [
Figure 2 shows how an EA-based ontology representation, in this case based on ArchiMate, can essentially make enterprise models machine-processable and analyzable. Note that 1 kind of models capture what and how of an enterprise but not whys.
EA-related Enterprise Goal Model 2 in Figure 1 shows a prescriptive model
focused on capturing whys or intentions behind decisions taken in enterprise. For this,
we suggested first steps using intentional modeling language i* for capturing goals in
enterprise models based on ArchiMate. In contrast to goal descriptions provided by the
EA framework, such as ArchiMate motivation extensions, our approach enables solving
problems faced by enterprise, and select the optimum strategy from the available ones
[
Enterprise (Architecture)
Model
Strategic Dependencies [SD] and Rationale [SR] models in i* Via
EAIntentional Metamodel
Mapping Revise Enterprise (Architecture)
Model via
Mapping
Non-EA-related Decision Making Model The prescriptive models of Figure 3 are
relatable with enterprise models, i.e., based on similarity in concepts of actor, behavior,
resources one could relate these models [
Generally, spreadsheets are used to encode workforces planning parameters to monitor and to take actions based on parameter values. Essentially, operational decisions are represented using formulaic language supported by spreadsheets suitable for quantification which is cryptic and spread over number of spreadsheets. The information about why certain formulae are used remains largely unclear. What-if and if-what analyses, i.e., evaluation of alternate strategies from as-is state of enterprise to its to-be state and search of strategy that might have led the enterprise to its current as-is state respectively, are difficult to explicate with such representation. These analyses need to be conducted frequently as for a service company such as ours, workforce situation remains in flux. We are therefore investigating the use of system dynamics (SD) models to address the problem of workforce planning. The detailed description of how we propose to use SD models to capture issues of attrition, on roll skills, and on the job headcount, and how recruitment from campus, lateral hiring, on-boarding process etc. affect these is out of the scope of this paper.
(a) (b) Fig. 4: (a) Using Non-relatable Prescriptive Models with Enterprise Models (b) IT Plant-specific Prescriptive Models with Enterprise Models
The core concepts of stocks, flows, and influencing variables in SD represent drastically different abstractions than those found in enterprise metamodels. Instead of metamodel mapping therefore, we propose to use these models in-concert by explicating the analysis results in the form of strategies to achieve goals which are represented with bidirectional mapping to enterprise models. This is shown in Figure 4 (a). One obvious example where the problems of workforce planning are directly related to enterprisewide context is finding the steps required for an organization to increase revenue by 10% quarter on quarter. Cost benefit analysis of workforce planning would need to see how revenue earned changes as a function of on roll manpower, project mix to bid, and bid success ratio etc. The results of this analysis need to be put in the overall enterprise context, in the ArchiMate sense, at the business layer, perhaps in terms of actions that resource management department may take to satisfy the strategic goal of increased revenue.
ferred to the problems of IT systems of an enterprise that must be addressed in both business-as-usual and transformational situations. The set of interacting IT systems of an enterprise, and technology and hardware infrastructures underneath them is what we refer to as an IT plant. We believe that to address the problems of local optimality with respect to a given property, functionality overlapping, and non-interoperability between IT systems, we need to model IT systems and their interactions with specialized models. These kinds of models are shown as 4 in Figure 1. Their usage with enterprise models is shown in Figure 4 (b).
We expect these models to be graph-like where IT systems are nodes and the edges are interactions such as depending on one another, accessing same set of data, simply relaying data, and so on between them. The analysis essentially focuses on interaction patterns of the systems of an IT plant. Such models may be constructed by observing in automated manner how IT systems use one another and how changes in underlying technology platforms and hardware infrastructure of an IT system affects other IT systems of given IT plant. By constructing models based on interaction patterns of IT systems and refining them over a period of time, we think that problems of optimality with respect to given criteria, non-interoperability, and overlapping functionalities could be addressed effectively. This constitutes part of our ongoing work. Like models illustrated earlier in Figure 4, results of IT plant-specific model analysis will have to be put in the context of enterprise as shown in Figure 4 (b). Fig. 5: (a) Relating IT Plant Implementation Model with Enterprise Model (b) Using (Multi-) Models of Enterprise in Concert
IT Plant Implementation Model While strategic and tactical goals focus on the long-term orientation of the organization and short-range planning respectively, operational goals focus on implementing tactical goals at the ground level. This is also more relevant in the case of IT as business rather than IT as support function of business. We are proposing that there should be a bidirectional traceability between enterprise model and IT plant implementation models via operational models that translate strategic level requirements of data, services, processes, user experience, and non-functional properties to implementation level specifications from which IT plant may be generated. 5 in Figure 1 shows such models which are illustrated in overall context in Figure 5 (a).
We are aware of stark differences in levels of abstraction and granularity of concepts between enterprise models and IT plant implementation models and the operational models with data, service, process, non-functional properties, and user experience requirements in between are expected to bridge this gap. Earlier in Figure 1, we did not show the operational model, because we are not certain of what will be the nature of these models or if these models are required at all. We believe that it should be possible to automate to the extent possible translation of results of various analyses obtained with the rest of the models illustrated in Figure 1 into an actionable form.
As-is
To-be
Fig. 6: Using (Multi-) Models of Enterprise in Concert for Enterprise Transformation Figure 5 (b) shows various models illustrated so far together. While the enterprise model remains the single version of truth, results of analyses using non-EA-related decision making models of IT- and non-IT-specific models are to be explicated in conjunction with enterprise goal models for better decision making. Since ultimately our focus is on IT systems, we have proposed to connect enterprise models to IT plant implementation models via operational models (of kinds of requirements). In the next section we review further issues pertaining to multi-modeling of enterprises.
While Figure 5 (b) can be used straight away for decision making in business-asusual situations, Figure 6 shows how transformational situations can be addressed using proposed models. Note that Figure 6 does not show as-is IT plant implementation models for the want of space. The as-is and to-be EA-based enterprise models are connected via EA-related goals models. Other decision making models may be used for specific problems in transformation and eventually IT plant implementation of to-be enterprise model may be obtained.
In the next section, we show how the proposed models may be applied to a case study of M&A of two wealth management companies taking into account various issues outlined above. 3
Background The case study concerns two large independent Wealth Management (WM) (retail brokerage) companies (WM1 and WM2) which came together to form WM3. The combined retail brokerage house has 10000+ Financial Advisors, managing multibillion dollars in client assets across 700+ locations in country X. WM1 and WM2 both provide WM products such as credit, lending, annuity, insurance, banking, etc. and services like brokerage, advisory, financial planning, wealth planning, retirement planning, and trust etc., to wealthy individuals and small-to-medium size businesses across X.
WM3 was formed the expressed strategic goal of tripling WM1’s revenue and gross margin in 5 years. WM3 also has strategic growth viewpoint where it needs to provide new and innovative products and services to its clients. This requires a renovated stateof-the-art IT platform to compete with its more aggressive peers and ever increasing tech-savvy clients. In the following, we discuss how various decision making models may be used to address specific problems in conjunction with the enterprise model.
tactical goals were devised that would contribute positively to key strategic goal. Three of these tactical goals were optimize/rationalize branch and back-office operations, rationalize wealth management products and services, and of course, integrate workforces of WM1 and WM2. Each of these three goals can be achieved using SD or similar models, which are essentially examples non EA-related decision making models.
For the tactical goals mentioned above, particularly for workforce integration of WM1 and WM2, SD models could be used in a manner similar to the way they are used in workforce planning as discussed earlier in Section 2.2. For optimization/rationalization of branch and back-office operations, an important fact to consider is that WM1 and WM2 were competitors prior to the merger with several branches in the same locality. Consolidating the branches and their operations would result in recurring cost savings every year. The decision to which ones to keep as-is, which ones to merge, and which ones to let go of depends on branch operations related parameters such as whether it is owned/leased, cost and duration of the existing lease, importance of the location from WM3 perspective, floor capacity, terms and conditions, future growth potential at that location, etc. Decisions on optimal branch structure, e.g., how many/which branches should form a complex, how many/which complexes should be part of a region (western/eastern/northern/southern), etc., need to be taken to better manage WM3. The WM1/WM2 back-office operations also need to be optimized along similar lines.
WM1 and WM2 operate in similar business domain and hence have similar and even overlapping product and service portfolios. For rationalization of wealth management products and services, it is necessary to look at these products and services portfolios from WM3 business model perspective and take decision on keeping as-is, enhancing (modifying/merging/re-branding), decommissioning (retiring) the mix of products and services. The parameters that would be of relevance in taking decisions include product capabilities, channels, WM3 requirements, integration with other products/services, 3rd party (product/bank/vendor) involvement, etc. Also, it makes sense to look at cross-selling opportunities within WM1 and WM2 in terms of existing clients for products/services that were otherwise not available before the merger.
IT platforms of WM1 and WM2, key goals were to integrate IT platforms of WM1 and WM2 so as to obtain optimum IT platform functionality in WM3, optimizing WM3 IT platform capacity, and come up with optimum data conversion/migration from WM2 to WM1 in WM3.
In case of optimum WM3 IT platform functionality, the alternatives are to build a new IT platform or enhance one of the existing WM1 or WM2 IT platforms to support the WM3 target operating model arrived at separately. In order for the target IT platform to support WM3 operating model, decisions need to be made on which applications to keep as-is from WM1 or WM2, which ones to enhance (modify/merge-functionality), which ones to build from scratch (nothing can be reused from WM1/WM2), which ones to decommission and when. Note that problems of IT systems of enterprise described in Section 2 get accentuated in this case because of the size and legacy of WM1 and WM2 combined together and therefore need further efforts in capturing interaction patterns of IT systems of WM1 and WM2 themselves and possible interactions between IT systems of WM1 and WM2.
To resolve the problem of optimizing WM3 IT platform capacity, current size of WM1 + WM2 needs to be considered along with the future growth plans for WM3 which is that the capacity of the WM3 platform needs to be doubled. It means the existing applications (selected for WM3) should be able to handle 3 times their current volume (# of transactions, clients, branches, financial-advisors, employees, etc.) without (negatively) impacting performance. This would require changes such as optimizing/ re-writing database queries, re-architecting / re-designing, adding more hardware, etc. The changes would cut across multiple layers and applications. There could be problems similar to Y2K that need to be addressed. For example, 3 digits were sufficient to accommodate WM1 Branches, but WM3 is going to have more # of branches and 3 digits may no longer be sufficient to accommodate WM3 branches.
For data migration problem, existing and historical data needs to be converted from the source to the target platform and applications. This includes both business critical and non-critical data. Since there is terabytes of data involved and limited conversion (live cut-over) time-window available because of the nature of the business, there is very limited scope for making an error (in speed and quality of the conversion) during the entire process. The converted data should also comply with the regulatory requirements applicable for WM3. We are currently investigating how above mentioned problem descriptions can be represented using decision making models of IT plant as described in Section 2.2.
transformational situation captured in Figure 6, and shows the merger of WM1 and
WM2. This merger was initiated by WM1, therefore the as-is and to-be states are
depicted as that of WM1. EA-based enterprise models of WM1 and WM2 are descriptive
models which capture all relevant information about WM1 and WM2 in a manner
explained in [
WM3 IT Plant
Implementation
Branches Triple revenue and gross margin in 5 years
Products and
Services
WM3 IT Plant CITapPalacnitty Integration Enhancement WM1 WM2
Fig. 7: Using (Multi-) Models of Enterprise in Concert for M&A We proposed combination of EA-based enterprise model and set of models specialized for decision making pertaining to specific aspects of enterprise as descriptive and prescriptive models respectively. Initial treatment of real world merger of two large enterprises using our multi-model approach indicates that problems faced by enterprise that demand specific ways of solving can be modeled and solved in separation yet maintaining the overall enterprise context. Furthermore, modeling enterprise concerns down to IT plant itself means that both business-as-usual and transformational situations can be tackled. Initial results suggest that multi-models of enterprise help in separating and localizing decision making in enterprise. Enterprise Models as Drivers for IT Security
Management at Runtime
Anat Goldstein, Sietse Overbeek Institute for Computer Science and Business Information Systems,
University of Duisburg-Essen, Germany
{Anat.Goldstein, Sietse.Overbeek}@uni-due.de
Abstract. This paper describes how enterprise models can be made suitable for
monitoring and controlling IT security at runtime. A holistic modeling method
is proposed that extends enterprise models with runtime information, turning
them into dashboards for managing security incidents and risks, and supporting
decision making at runtime. The requirements of such a modeling method are
defined and an existing enterprise modeling language is extended with relevant
security concepts that also capture runtime information to satisfy these
requirements. Subsequently, the resulting modeling method is evaluated against the
previously defined requirements. It is also shown that common metamodeling
frameworks are not suitable for implementing a modeling environment that
results in suitable IT security dashboards. This leads to suggesting
implementation of the modeling environment using the eXecutable Modeling Facility.
1
In recent years, Information Technology (IT) security has become a major topic as
well as a substantial challenge. On the one hand, there is an ever increasing need to
protect IT resources as enterprise assets and business processes increasingly depend
on IT. On the other hand, enterprises become more exposed to IT security threats due
to an increase in Internet connectivity and availability of sophisticated malware.
Designing and managing secure IT systems involves technical complexities that are
caused, for example, by prevalent use of distributed computing and by frequent
technological changes. It requires a deep understanding of the organizational structure and
its operations, which are also subject to frequent changes with the continuous effort of
the enterprise to stay competitive. Designing secure IT systems also requires the
participation of various stakeholders, such as: IT professionals, security experts and
business managers. These stakeholders do not share a common language and possess
different views of the problem. Also, as IT security solutions are required to be
economically justified, a cost-benefit analysis of possible solutions is called for. These
challenges stress the need for methods and tools for supporting IT management with
designing, realizing and managing IT security systems. Such methods and tools
should account for technical, economical, business and managerial aspects [
Conceptual models are often used for reducing complexities and bridging
communication gaps. In recent years, an extensive amount of research is oriented towards
development of methods for modelling IT security. In particular, there are several
methods that bridge the gap between business and technical perspectives, for
example, by extending business process (BP) models (e.g., [
As part of our ongoing research, a modeling method is developed that provides holistic support for the analysis and design of secure IT systems and for managing IT security. It is holistic in two ways. Firstly, it covers and integrates three different enterprise perspectives: Organizational, strategic and technological. Secondly, it covers several tasks – the analysis, design, implementation and management of IT security. In this paper, however, the focus is on the management of IT security only. In particular, the developed modeling method extends an enterprise modeling environment so that created enterprise models (EM) can be used as dashboards, allowing managers to monitor and control the security of enterprise systems, that is, systems that support the managing of BP executions, employees, concrete IT resources and so forth. Security dashboards can be used to analyze monthly costs of various security controls, summarize attack information on different IT resources and identify business process instances that might be affected by an occurrence of a security incident. In other words, in this paper we propose using EMs as drivers for IT security management at runtime.
Our approach is based on and extends a multi-perspective enterprise modelling
(MEMO) framework [
The rest of this paper is organized as follows: In section 2, use scenarios for managing IT at runtime are provided. In section 3, IT security models at runtime are defined and in section 4 we define the requirements for supporting such models at runtime. In section 5, we describe the development of a modeling method for creating IT security models at runtime and in section 6 we evaluate the method. The paper ends with conclusions and a discussion of future work. 2
Use Scenarios for Managing IT Security at Runtime
Our modeling method is based on the Multi-perspective Enterprise Modelling
(MEMO) approach [
Fig. 1 illustrates two scenarios in which EMs are used for managing security at runtime. It shows three landscapes: A risk management landscape, a BP landscape and an IT landscape. The BP landscape shows three BP types: Order processing A, Order processing B and Customer management. The detailed structure of the BP type Order processing A is shown as well. The figure shows two scenarios in which security threats are realized by actual security incidents.
Fig. 1. Use scenarios for managing IT security.
In the first scenario, false information was entered on 10 March 2013 by a new sales agent ( ) in the Check availability sub process (), as a result of a too short training period for the new agent. Short training period of new employees has been identified as a vulnerability in the risk management landscape (), that can be exploited by the False input threat (). Thus, the first security incident in fact realizes a threat that has been modeled in the risk management landscape. It is then possible to determine which instances of this process were affected () and, therefore, contain incorrect information. Subsequently, these instances can be analyzed and incorrect information can be repaired.
The second scenario shows that a security incident occurred on 19 January 2013 that is related to a Credit card service (). As a result, payment information has been revealed. The credit card service is an IT resource and part of the IT landscape. This service relates to the three BP types shown in the BP landscape (), which implies that it is possible to know which instances of these BP types are affected by this incident. For example, it can be seen that at least four instances of the Order processing A type were affected on 19 January 2013 (). A possible way to mitigate the risk that a service is hacked is to install a firewall (), such as is the case with the Customer rating service. The firewall can be supplemented with statistics on its attacks and related costs in order to support management of risk mitigation.
Having explained the two scenarios, IT security models at runtime can be defined. 3
IT Security at Runtime
Usually, enterprise models refer to what is known as the type level [
These are all examples of types as they abstract from instance details such as the exact start time and end time of a business process step. However, sometimes it is useful to represent actual instances of the running system, for example, for monitoring and controlling the running system. The lower part of Fig. 2 presents a runtime execution of the order processing BP that occurred at a certain time. It also presents an instance of the credit card service that is used by the BP instance and a security incident which affects it. The security incident realizes the instance of the threat from the upper part of Fig. 2. Models that represent the type level are designated as type models and models that represent instances are designated as instance models.
When it comes to modeling frameworks, e.g., UML [
Our intention to support real-time monitoring and analysis of security incidents
demands for integrating enterprise models with runtime information of the enterprise
software systems that are used to manage business process control flows, IT resources
and employees. Such kind of integration is known as ‘modelling at runtime’. A
‘model@runtime’ is a conceptual model that is a “causally connected self-representation of
a system” [
Requirements of the Modeling Method The scenarios presented in section 2 illustrate that in order to use EMs for managing IT security at runtime, the following requirements should be satisfied:
Req1: In order to comprehensively model IT security, various perspectives of the
enterprise should be considered. The EM should integrate IT security concepts that
are relevant for various enterprise perspectives (e.g., BPs, IT resource and
organizational units). This point is stressed in [
Req2: The EM should integrate concepts that not only represent abstractions of the type level such as types of BPs. It should also represent abstractions of the runtime (instance) level, such as executed BP instances. This is dubbed as vertical integration. More specifically, the DSMLs that are used for creating enterprise models should include both type-level abstractions such as event name or sub process type and instance-level abstractions such as an event time stamp.
Based on the definitions in section 3, a further requirement can be specified: Req3: Type models should be aware of their instances and able to interact with them. This also implies a need for synchronization of the different models, so that in case M0 instances change it is automatically reflected in the runtime models.
The vertical integration of types and instances could be taken one step forward, by using type level entities for the actual creation of their M0 instance, which are represented in the enterprise software systems. This would foster reuse and facilitate conformance of M0 instances to their type models. Thus, the next requirement is defined:
Req4: Type level entities should be used for defining their corresponding M0
instances. Nevertheless, using type models for the creation of M0 objects has been
identified as a challenging task [
Developing a Method for IT Security Models@Runtime In this section, the development of a modeling method that addresses the aforementioned requirements is described.
Extending MEMO to Support IT Security Models@Runtime
The first step is to extend MEMO-OrgML and MEMO-ITML with meta concepts that
support the scenarios as illustrated in section 2. It should be noted that a holistic
modeling approach for IT security should include more concepts than those that are
relevant for the use scenarios (c.f. [
An IT security incident is an event that might have a negative effect on the organization. The incident exploits one or more vulnerabilities of the organization, e.g., a weakness of an IT resource or of a BP, and it has a set of impacts. An IT security incident can realize a threat - a potential event, situation or action that might cause harm to the organization by exploiting its vulnerabilities. Threats and vulnerabilities are usually identified during security risk analysis. A threat is created by a threatsource – an external force to the security system that has potential or intention to cause harm. When the threat-source comes from within the organization, it can be associated with an organizational unit, e.g., employee, position or role. The above concepts represent both type and instance level properties. For example, a threat type is modeled in advance (usually during security risk analysis) and belongs to the type level. Then, at runtime, a threat can be realized by actual security incidents at a certain times.
In order to use the meta concepts not only for modeling types but also for
representing runtime instances, we enhance the meta concepts with abstractions of runtime
properties such as the realization date of a threat or the name of a threat source.
Adding runtime concepts to the metamodel makes sense because otherwise it would be the
responsibility of the modeler to account for them in every enterprise model that is
created [
In order to support online decision making, type concepts should also include attributes that are calculated based on instance values. For example, we can calculate a threat average realization cost based on the concrete costs of its instances or we can calculate the number of threat realizations per year. Such attributes are called derivable attributes. Fig. 3 describes a simplified OrgML meta model which is extended with the above security concepts. Intrinsic features are marked with a boxed letter ‘i’ and derivable features are marked with a boxed letter ‘d’). Due to space limitations, Fig. 3 does not depict ITML concepts, except for a general concept ‘IT Resource’ which is a surrogate for any IT resource type.
Developing a Corresponding Modeling Tool
So far, extensions to MEMO-DSMLs have been described in order to capture IT
security concepts in general and runtime properties in particular. By doing so, Req1 and
Req2 are addressed. In order to address requirements Req3 and Req4, a corresponding
modeling environment should be developed. The IT-security related concepts that we
specified have in part been implemented within the existing meta modeling
environment MEMO Center, which is based on the Eclipse Modeling Framework (EMF)
[
Type models that are created within the newly generated modeling editors are represented by Java objects that can be dynamically changed by the user. For example, a BP event type is represented by an object that is created and modified by the modeler to define the event name and its other properties. Being Java objects, they could not be further instantiated for creating M0 instances. Instead, these objects can be used for generating new classes that represent M0 instances and corresponding editors (using the same technique that was used for generating classes of the type-level modeling editors). This results in two independent sets of classes / editors, one for representing types and one for representing instances. This is problematic with respect to our intention to integrate between the type level and the instance level. Firstly, it is difficult to synchronize the evolution of the type level with the instance level: Whenever a type model changes (e.g., a BP model is updated, which is likely to happen a lot) all the classes representing corresponding instances should be regenerated. Secondly, when M0 elements are created or changed, e.g., when a new security incident occurs or when a BP step is completed, corresponding changes should be immediately reflected in the relevant type model editors. For example, when a certain threat is realized, the value of totalRealizationsPerYear of that particular threat type should be increased. This requires a support for a synchronization mechanism between the two editors.
Because of these reasons, we started to re-implement the meta modeling
environment using eXecutable Modeling Facility (XMF). XMF is a programming language
that is accompanied by a modeling tool, the Xmodeler [
Evaluation An approach has been proposed to extend an EM environment in order to utilize EMs as dashboards for managing IT security. In section 4, we have defined four requirements that the targeted modeling method should satisfy. The presented modeling method is measured against these requirements. The first requirement, which concerns the integration of IT security concepts that are relevant for various enterprise perspectives, has been partially addressed. As the focus of this paper is on a modeling approach that allows EMs to serve as IT security dashboards, only a limited set of concepts that are mainly related to risk analysis have been presented. However, horizontal integration is facilitated as MEMO is at the basis of our method. It provides an infrastructure for adding IT security concepts that are relevant for the various enterprise perspectives. The second requirement, which concerns including abstractions of the type and instance levels, is supported by our method by using intrinsic features to describe runtime properties and derivable features that aggregate runtime information of instances on M0. Although not discussed in detail, using XMF for the implementation of MEMO allows for satisfying the third and fourth requirements. First of all, by inheriting from the core concepts of XMF, the MEMO-DSMLs can be used to specify type-model concepts that can be instantiated into M0 concepts without requiring generation of code. This satisfies the fourth requirement. Secondly, M1 concepts created with the MEMO-DSMLs have the ability to access their instances, which serves as a foundation for integrating and synchronizing between different levels of abstraction at runtime, as defined by the third requirement. 7
Conclusions and Future Research In this paper, we present a modeling method that extends EMs to serve as dashboards for IT security management. Such dashboards can support real-time management of IT security incidents and risks, which allows for analyzing their effect at runtime and enable managers to respond quickly and efficiently. While we have focused on the IT security domain, the presented approach could be applied to other domains as well.
It has been explained why common metamodeling facilities such as the EMF are not sufficient for extending EMs to serve as dashboards, resulting in a reimplementation of MEMO in XMF. In the future, we intend to continue with the development of the modeling environment in XMF and to extend it with additional IT security concepts. We also intend to supplement the modeling method with corresponding process models that would guide the use of such IT security models@runtime in various scenarios. So far it is not discussed how M0 instances are created. It is assumed that somehow they are created by instantiating type-entities on M1. In future research, the integration of EMs with the actual enterprise system should
References