Ilia Bider

Gene Bellinger

Erik Perjons
email: perjons@dsv.su.se

Modeling an Agile Enterprise: Reconciling Systems and Process Thinking

Keywords: Business Process Management, Systems Thinking, Enterprise Agility

Selection of an enterprise modeling paradigm depends on the practical task the modeling project is trying to achieve. For example, modeling in the frame of Enterprise Architecture paradigm is, usually, aimed at alignment of the enterprise components, such as mission, vision, business processes, services and IT systems. Modeling in the frame of Business Process Management is aimed at process improvement/optimization, and modeling in the Systems Thinking paradigm is aimed at getting a holistic view on the dynamic behavior of the enterprise. This paper suggests a new approach to enterprise modeling that combine these approaches in order to reveal and improve enterprise agility. It is based on the systemic view of business processes, and it presents an enterprise as a three-layered model consisting of assets, sensors and business process instances. Elements of this model can be recursively decomposed, which allows for different levels of details when modeling an enterprise.

Introduction

We start with two sayings that concern modeling. The first one runs as "All models are wrong, but some are useful" and is attributed to George E.P. Box [START_REF] George | Wikiquote[END_REF]. The second one runs as "A method that is good for everything is good for nothing". The meaning of these two sayings in the context of the PoEM conference can be expressed as each enterprise modeling technique can be useful to solve some practical problems in certain context, but might be useless, or even counterproductive for solving other problems, or problems in another context.

Consider the three paradigms most frequently used for modeling enterprises: Business Process Management [START_REF] Weske | Business Process Management. Concepts, Languages, Architecture[END_REF], [START_REF] Harmon | Business Process Change. A Guide for Business Managers and BPM and Six Sigma Professionals[END_REF], Enterprise Architecture [START_REF] Steltzer | Enterprise Architecture Principles: Literature Review and Resarch Directions[END_REF], [START_REF]Trends in Enterprise Architecture Research, 5th International Workshop, TEAR 2010[END_REF], and Systems Thinking [START_REF] Checkland | Systems Thinking, Systems Practice[END_REF], [START_REF] Jackson | Systems Thinking: Creative Holism for Managers[END_REF], each of them having countless techniques and methods. Each of these paradigms is connected to a special problem area. Business Process Management is associated with optimization of the usage of resources inside an enterprise through specialization, standardization, and automation [START_REF] Malone | Towards a Handbook of Organisational Processes[END_REF]. Enterprise Architecture is associated with alignment of different parts of the enterprise, like mission, vision, structure, processes and IT systems [START_REF]Trends in Enterprise Architecture Research, 5th International Workshop, TEAR 2010[END_REF]. Systems Thinking is associated with a holistic view on the dynamic behavior of the enterprise and its interaction with its environment [START_REF] Checkland | Systems Thinking, Systems Practice[END_REF]. It is directed to avoiding situations in which the dynamic behaviors existing in different parts of the enterprise, e.g., sales and production, are disconnected. For example, sales is increasing its efforts, while production is pursuing cost savings by diminishing current production levels, which after some time, results in increasing time from order to delivery.

The scope in which the above paradigms are applicable may also differ. For example, a Business Process Management project can have an enterprise-wide scope and be aimed at identifying and modeling all processes in the organization. On the other hand, the project can concern a particular process, e.g., sales, in order to optimize it. The same is true for Systems Thinking. The project can be started to overhaul the whole enterprise, or just to understand and improve a particular situation. Enterprise Architecture paradigm differs from the previous two in this aspect, it is aimed to align all components of the organization and thus, usually require a large scale project that concerns the whole enterprise To complete an Enterprise Architecture project requires time and considerable resources which leads to this paradigm normally being used by large enterprises in sectors considered to be stable, energy, large industrial enterprises, financial sector, large governmental organizations.

None of the above paradigms focuses specifically on the issue of enterprise/business agility -property of an enterprise to function in the highly dynamic world [START_REF] Sherehiy | A review of enterprise agility: Concepts, frameworks, and attributes[END_REF]. The agility concerns both being able to adjust the enterprise to changes in the surrounding environment, and discovering new opportunities constantly appearing in the dynamic world for launching completely new products/services. Becoming agile requires a structure that allows discovering changes and opportunities as soon as possible and react on them appropriately. A model that reveals the current level of agility, and can show ways of improving it would be beneficial for a new generation of highly dynamic team based enterprises.

This paper is aimed at presenting an idea of how a enterprise model explicitly related to issues of enterprise agility could look like. The model can be the base for a new modeling technique managing agility. While creating this model, we do not reject the concepts and features existing in the other three paradigms. Actually, we borrow all we can and adjust and integrate the borrowed concepts in a manner that is appropriate for the goal our model is aimed to serve. For example, a reaction on a discovered change is defined as starting a business process instance/case. However, we do not insist that this process should be optimal, or need to be optimized in the future. It is enough if the process is very loosely defined so that an instance of such a process can be completed in a relatively short time. Optimization may not be appropriate in the dynamic environment as it will hinder the creativity needed for handling a particular process instance.

This work has its roots in the heated discussions in the LinkedIn group Systems Thinking World [START_REF]Systems Thinking World group[END_REF] on whether terms system and process represent the same or different concepts. These discussions resulted in our creation of the model managing enterprise agility. The model is based on applying a systemic view to business processes. Standard for Enterprise Architecture concepts as mission, vision, policies, structures, are taken into consideration, but are not set in the focus. The resulting enterprise model consists of three layers:

 Enterprise assets  Sensors  Business process instances
The rest of the paper is structured according to the following plan. In Section 2, we present a systemic perspective on business processes. Based on this perspective, in Section 3, we introduce the three-layered model for managing enterprise agility as mentioned above. In Section 4, we introduced a simplified classification of business processes based on the nature of their goals. In section 5, we explain how elements of different layers of the model interact with each other. In section 6, we discuss how sensors and business process instances can be recursively decomposed. In section 7, we present some informal examples of application of the ideas introduced in the previous sections. Section 8 is devoted to related work. In section 9, we discuss the implications of the three-layered model, and draw plans for the future that concern the transition from the idea presented in the paper to the practical methodology of enterprise analysis and modeling.

Systemic View on Business Processes

According to Systems Thinking [START_REF] Checkland | Systems Thinking, Systems Practice[END_REF][START_REF] Jackson | Systems Thinking: Creative Holism for Managers[END_REF] an enterprise is regarded as a whole, i.e., a system. Such a system maintains its existence through constant interaction between its parts, i.e., people, departments, teams, etc. The system interacts also with its environment, a bigger whole, manifesting a unique behavior that cannot be derived from the sum of its parts. From a Business Process Management perspective [START_REF] Harmon | Business Process Change. A Guide for Business Managers and BPM and Six Sigma Professionals[END_REF], an enterprise is regarded as a number of repeatable business processes. These two perspective looks on the surface completely different, and to integrate both of them in a new modeling technique we need, first, to reconcile them. The reconciliation is done via considering processes as a special type of systems.

The term business process encompasses two concepts (which often confuse outsiders):

 business process instance (BPI) or case, for example, delivering a service to a particular customer after receiving a call for service  business process type (BPT) or template which refers to all possible instances of a particular kind, e.g., all service delivery instances.

A business process instance (BPI) is a system with a short lifespan. It can be minutes, hours, days, months or years, but its lifespan is always (considerably) shorter than the lifetime of the whole enterprise. Such a system is created to achieve some (operational) goal, e.g., to deliver service, or goods ordered by a given customer and get paid. This system is disbanded after the goal has been reached. A BPI system includes the same components as the whole enterprise system (e.g., people, departments) and some elements of the environment (e.g., customers, investors). At any moment of time, an enterprise has numerous BPIs in progress providing the majority of the interactions between the system's components and the system, and the environment.

A business process type (BPT) can be considered as a set of rules that describes the dynamic behavior of BPIs aimed at reaching a certain class of operational goals. A BPT consists of two parts: In other words, the knowledge on the rules (and the processes themselves) can range from being completely tacit (e.g., resides in the heads of the process participants), to partly or totally explicit (e.g., depicted in detailed process maps). BPTs work as business DNA creating BPIs based on the needs, e.g., impulses or changes in the environment or inside the organizational system itself. BPTs plus tools used in BPIs, e.g., telephone lines, computers, production lines, constitute an organizational system's infrastructure that allows it to effectively function inside the given environment. BPTs constitute some kind of hierarchy. The lower levels are occupied by BPTs that produce BPIs as a reaction to simple impulses, like incoming order from a customer. The higher levels are occupied by more strategic BPTs that react on more substantial changes in the environment by reconfiguring the system itself, which may include changing BPTs (a kind of genetic engineering), introducing new BPTs, or deleting the obsolete ones.

 Start conditions

The Three-Layered Enterprise Model

Based on the elaboration in Section 2, we can view an organization as a three-layered model as depicted in Fig. 1, and explained below:

1. An assets layer consists of:  People -with their knowledge and practical experiences, beliefs, culture, sets of values, etc.

 Physical artifacts -such as computers, telephone lines, production lines, etc.

 Organizational artifacts, formal as well as informal -such as departments, teams, networks, roles, etc.

 Information artifacts -such as policy documents, manuals, process descriptions (BPTs), etc. To the information artifacts belong both written (documented) artifacts, and tacit artifacts -the ones that are imprinted in people's heads (e.g., culture.)

The assets layer is relatively static, which means that this layer by itself cannot change anything. The components of this layer are activated when they are included in the other two layers. This layer itself can be changed through other layers when the assets are set in motion for achieving some useful goals. Note that assets here are not regarded in pure mechanical terms. All "soft" assets, like sense of common goals, degree of collaboration, shared vision etc., belong to the organizational assets. Note also that having organizational artifacts does not imply a traditional function oriented structure. Any kind of informal network, or resource oriented structural unit, is considered as organizational artifact.

Figure 1. Three-layered model of an enterprise as a system 2. Sensor layer consists of a set of (sub)systems, the goal of which is to watch the state of the enterprise itself and its environment in order to catch impulses and slower changes that require firing of business process instances of certain types. We need a sensor (which might be a distributed one) for each business process type. The work of a sensor is governed by the Start Conditions of the BPT description (which is an informational artifact). A sensor can be fully automatic for some processes (an order placed by a customer in a web-based shop), or require human participation to detect changes in the system or its surroundings.

3. BPIs layer -a set of systems initiated by sensors for reaching certain goals and disbanded when these goals are achieved. The behavior of a BPI system is governed by the Execution Rules of the corresponding BPT. Dependent on the type, BPIs can lead to changes being made in the assets layer. New people are hired or fired, departments are reorganized, roles are changed, new policies are adopted, BPT descriptions are changed, new BPTs are introduced, and obsolete ones are removed.

Classification of Business Processes

We can roughly differentiate three categories of business processes dependent on the complexity of the sensor, and the nature of the process itself:

1. The first category encompasses operational processes, like sales, production, HR (e.g., hiring), etc. A sensor discovers the need (e.g., customer needs -sales, or internal needs -HR), and initiates a relatively structured process instance to attain the operational goal (e.g., making a deal, or hiring a new employee).

2. The second category encompasses process improvement (optimization) processes.

A sensor here is based on the performance indicators established to measure efficiency, productivity, or other parameters of the given BPT. If the performance is not according to the expectations, an improvement (re-engineering) BPI starts with the goal to change process definition(s) used by operational processes. The improvement BPI here can follow some known methods (like Six Sigma, or lean). As a rule, the improvement processes are less structured than the operational ones.

3. The third category encompasses strategic processes. A sensor here is based on the macro view on the whole organizations. If the overall performance is below expectation, a strategic BPI is fired with the goal of considerably changing the assets layer. This can include radical changes in process definitions, removing obsolete processes, introducing new ones, rearranging departments, substituting key-managers, introducing new technology, etc. These are the processes where Systems Thinking is (though maybe too seldom) applied as guidelines for finding the best places to make changes (leverage points). A process here may be completely ad hoc, or use some loose structure, e.g., a series of brainstorming sessions.

Interplay between the Layers

Due to the interplay between the three layers, an enterprise behaves as an adaptive system. It constantly interacts with the environment based on the BPTs of operational processes, optimizes itself to the current environment through the improvement processes, and can reconfigure itself when the environment changes based on the strategic processes (after which it can start optimization to the new environment). Basic interconnections between the elements of different layers are depicted in Fig. 1. These, and the additional ones that are not explicitly shown in Fig. 1, are explained below.

A BPI (layer 3) is started by the corresponding sensor (layer 2), and it uses organizational assets (layer 1), such as people, machines, etc. to produce the result, i.e., reach some operational goal. In particular, the execution rules of the BPT (layer 1) controls the behavior of each BPI that belongs to this process type.

As was already mentioned, a BPI can be started to intentionally change the organizational assets (layer 1), fire or hire people, change policies, change BPTs, reorganize departments, etc. But even when a BPI does none of the above, it does make a change just because it was running for some period of time. During its run, a BPI creates a trace either on paper, or inside the organizational database, or just in the heads of people participating in this process instance. Depending on the type of organizational memory, the trace may stay in memory a very short period of time, or last "forever". All remembered traces of BPIs constitute the experience based knowledge of the organization, which, as an information artifact, adds to the assets layer (layer 1).

A sensor (layer 2) starts a BPI (layer 3) each time it detects that its start conditions are satisfied, and it uses assets (layer 1), such as people, machines, etc., to detect this situation. In particular, the start conditions of the BPT (layer 1) controls the behavior of the sensor (see Fig. 1).

For a sensor to identify when a BPI is to be started, it needs access to the relevant information in order to test the start conditions. This information is usually delivered by some already finished BPIs (layer 3) and can be found in their traces (layer 1). The information that sensors need can be provided by normal BPIs aimed at practical goals (as their side effects). However, in many cases, just having standard operational business process is not enough to provide all information needed for the sensors. Special "information gathering" business processes need to be designed with the only goal of obtaining relevant information for the sensors. The start condition for such a business process could be very simple, a BPI should run each year, month, week, year, our hour. Information gathering processes are especially needed for the sensors belonging to the categories 2 and 3 of the process classification from Section 4. A periodical survey of the customers to determine their level of satisfaction is a typical example of an information gathering business processes.

Another way of obtaining information needed for sensors is to enhance the standard operational processes in order to gather this information during the BPIs runs. This can be done by adding to them steps (operations) that are not important for these processes as such, but can provide information for sensors belonging to other business processes. An example of such enhancement could be a set of questions to the potential customer who has chosen not to buy a product or service, just to find out the reason for his/her decision (wrong price range, wrong service, etc.).

Decomposition

Both a sensor and a BPI are systems, and thus they can be, if necessary, decomposed. Consider an example of a compound sensor. Let us have a fast growing enterprise that wants to keep the pace of its expansion for a number of years ahead. Let this enterprise be a consulting business, the growth of which depends on the number of employees. The management decides to run a strategic overview (BPI) according to some template (BPT) as soon as there is a danger for growth or decline (start condition of the BPT). One of the parameters that reflect the pace of growth is the rate of consultants hiring minus rate of losing them to competitors. A sensor needs to evaluate this data against some threshold value and start a strategic overview when the value is below the threshold. There could be two possibilities to create such a sensor:

 ensure that all needed information is available in real-time, then the sensor just needs to do some math and issue a start signal if necessary  make a periodic, say once a month, information gathering, and only then do some math, and issue a start signal if necessary

The second case represents a compound sensor as in Fig. 2, which consists of a simple Sensor1 that "watches" the clock and starts an information gathering BPI on the 1st of each month. The BPI gathers information and produces a report (information artifact). Another sensor, Sensor2 in Fig. 2, reacts to a new report, makes comparisons and starts a new strategic overview if necessary. A similar decomposition can be done for a BPI, for example, when the BPI represents a complex BPI, e.g., a project. Complex sensors/BPIs are more typical for the category 2 and 3 of the process classification in Section 4 than for the category 1 (operational processes).

Applying the model 7.1 "Analysis" of the Internet bubble

Consider a simplified, and a bit exaggerated, example of an IT consulting company with sales department, consulting department, and HR department. The company uses a "usual" business model of charging per hour based on the expert level of its consultants.

Sales department conducts sales process instances according to the sales BPT (definition), part of which is hourly pricing of consulting services according to the level of the consultants expertise. HR department is hiring consultants according to the hiring BPT (definition), part of which is salary ranges according to the experience and education of the consultants. Hiring is done to ensure growth or just compensate natural lost.

Suppose management discovers that HR hires fewer consultants than expected. An investigation shows that the reason is the company offering less competitive salaries than their competitors. The hiring BPT is revised and salary offers become higher. The rate of hiring returns to normal (expected).

Suppose that at the same time new sales started to decline. An investigation shows that the company chargers more per hour than their competitors. The sales BPT is revised and the company starts charging less per hour. The rate of getting new consulting assignment returns to normal (expected).

The above adjustment can go through several cycles until the "strategic sensor" catches a new trend: the revenues from new assignments do not cover costs for their completion. A strategic business process instance is fired to find the best leverage point(s) to solve the problem using some System Thinking technique. What would it be?

What happens if the strategic sensor discovers the above situation too late, or there is no strategic BPT at all, or the fired BPI is unsuccessful. Well, bad luck, the company goes out of business.

Does everything above sounds too simplified? It might be so, but in the late 1990s a lot of start-up Swedish IT consultancies operated in this manner until most of them went out of business when the IT-bubble burst. We are not stating here that the management of these companies did not know what they were doing, some of them knew. Their actions might have had a more rational behavior, like dumping prices in hope to get rid of the competitors while having enough of risk capital. This, however, did not matter much in the end.

The artificial example above shows that failing to have a proper sensor may result in a complete demise of an enterprise working in a highly dynamic environment. This example reveals the weakness of the traditional enterprise structure, in which each process type engages a separate set of people. Sales BPIs are manned with sales staff, hiring BPIs are manned with HR staff, process improvement BPIs are manned with the Process Office staff, strategic BPIs are manned with high-level management. An example of such structure is schematically shown in Fig. 3. This picture is less detailed than the one in Fig. 1. Here, a process circle encompasses both BPI and sensors.

There are two weaknesses in the traditional organization that are revealed by the example above:  Parts of the systems are separated from each other and thus may easily drift apart destroying the system as was shown in the example in the previous section  The traditionally built enterprise is vulnerable if it operates in a highly dynamic competitive environment. The whole structure will work fine provided that sensors discover emerging situations fast enough so that the organization have time to adjust. In the highly dynamic environment, the costs of creating such sensitive sensors might be too high to make the whole idea sustainable.

Selling IT-consultants and Hire a Friend Principles

As a reaction to what happened during the IT bubble (see section 9), the Swedish IT consulting industry adopted two new principles: "selling IT-consultants", and "hire a friend". On the conceptual level both principles mean removing the rule that different operational processes, e.g., sales, service delivery, hiring, are manned by different categories of people. It is not clear whether every IT consultant can be a good sales person, or a good HR person, but in the most cases, due to his/her positioning in the outer world, a consultant can greatly contribute to the sales and HR processes. To make use of his/her position, for example, in sales, the consultant's role in this process can include him/her serving as a part of the process "sensor" by creating leads:  as a provider of information during the process, and  as a promoter of the company's line of products and services.

The above does not mean that the sales-staff should disappear and all sales should be conducted by consultants. It means active engagement of other categories of professionals in the sales process on a regular (and not on an ad hoc) basis. Expected results are more sensitive, and less expensive sensors which will make the processes more efficient on the whole.

Selling consultants and hiring a friend represent examples of so-called crossmanning of business processes. A schematic representation of this concept is given in Fig. 4, which is modification of Fig. 3.

Discussion

An analysis of the examples above shows that the three-layer enterprise model can be applied on the conceptual level to discover and explain weaknesses and strong sides of different ways of organizing business. For example, it helps to understand and explain the essence of cross-manning. Cross-manning can be applied not only to the category 1 operational processes but also to category 2 -improvement processes. Instead of letting specially assigned process re-engineers make detailed process designs, why not let people engaged in these processes do, at least, part of the job themselves? Let process specialists and management devise basic guidelines, and let professionals on the floor fill in the details. The advantages are:  people on the floor will know sooner when the old process definition stops to satisfy the internal or external environment (more sensitive sensor for the improvement process)  as they know better not only the business, but also each other's capabilities, they are in a better position to adjust the definitions not only to the abstract goals but also to particular people that man the operational processes

Related research

As was stated in the introduction, we derive our model from reconciliation of Systems and Process Thinking. Therefore, there are many features in our model that can be found elsewhere. We do not claim that all elements of our model are new; only a combination of them is to the best of our knowledge original. Not having enough space to review all related works, we will focus our attention only on two models that we consider most related to ours. One is the Viable Systems Model [START_REF] Beer | Brain of the Firm[END_REF], [START_REF]Viable Systems Model[END_REF] and the other is System-Coupling Diagrams [START_REF] Lawson | A Journey Through the Systems Landscape[END_REF].

The Viable Systems Model (VSM) is presented in Fig. 5. It was developed by Stafford Beer in the 1970s [START_REF] Beer | Brain of the Firm[END_REF] and is modeled after the manner in which a human being functions while interacting with its environment. A viable system has five interacting subsystems that may be mapped onto aspects of organizational structure. Systems 1-3 are concerned with the daily operations of an organization. System 4 is concerned with the strategical responses to the effects of external, environmental and future demands on the organization. System 5 is responsible for policy decisions within the organization as a whole to balance demands from different parts of the organization and steer the organization as a whole. System 5 is responsible to maintain the identity of the organization in order to promote a balance between stability and change. Any system of these 5 is also a viable system, which allows recursive decomposition of the model. Besides systems 1-5, VSM includes Algedonic Alerts (from the Greek αλγος, pain and ηδος, pleasure) -e.g., alarms and rewards that escalate through the levels of recursion when actual performance fails or exceeds capability, typically after a timeout. It is the inclusion of the Algedonic Alerts within VSM which provides a strong relation to the three-layered enterprise model presented in this paper. There would exist different sets of BPTs and sensors for each system within the viable systems model resulting in BPI initiation when the sensors fire. It should also be realized that the BPTs within each system will actually relate to the operational, process improvement and strategic, dimensions as described in Section 4. While this is the case, based on the functions assigned to the different systems within VSM, some systems will have more of one class of BPTs than another. For example, system 5, probably, will have more strategic BPTs than other systems.

The idea of System-Coupling Diagrams comes from [START_REF] Lawson | A Journey Through the Systems Landscape[END_REF] and is represented in Fig. 6. It describes a general case when a particular situation in the system's environment causes a larger system, e.g., an enterprise, to create a respondent system, e.g., a project, to handle the situation. The respondent system is built from the assets the larger system already has. We used this idea in our work by interpreting business process instances as respondent systems. In addition to that, we have introduced sensors to discover situation that require building respondent systems. Execution rules, and start conditions of business process diagrams can be considered as control elements of respondent systems and sensors. The notation of Fig. 1234was inspired by System-Coupling Diagrams. Figure 6. System Coupling Diagrams from [START_REF] Lawson | A Journey Through the Systems Landscape[END_REF] Business Process Management itself has a movement towards more flexible (agile) processes, which includes, but is not limited to the Adaptive Case Management, and flexible workflows. We do not overview the works related to these issues here, as they concern flexibility/agility in the frame of a particular process, not in the frame of the whole enterprise.

Conclusion

As follows from the title, our three-layered enterprise model is being built based on the reconciliation of Systems and Process Thinking. From Systems Thinking comes the view of the business process as a system, and the idea of cross-manning of business processes which creates a tighter cooperation between the parts of the enterprise system. From Process Thinking comes the need of having standardized ways of handling typical situations. Not having them for an organization means that any simple impulse from the outside needs to be processed in an ad hoc manner. An organization without standardized processes can be compared to a person that needs to think how to make each next step when walking along the street. Lack of standard processes is one of the weaknesses of small enterprises that make it difficult for them to compete with the big ones. This paper begins with the saying "All models are wrong, ...", which is true for our three-layered model as for any other. However, we hope that this simplified model might actually reveal the level of agility of an enterprise and help in finding ways for its improvement. In other words, we believe the model might be useful for both analysis of the current situation in an enterprise, and for re-designing the enterprise. When considering business processes, more attention needs to be paid to having good sensors than having optimal processes. There is no need to have an optimal process for handling a customer order if we do not have a sensitive sensor that identifies who might need our products. In the same way, it does not make much sense to have a perfect product development process if we do not have a good sensor that can discover the needs for a new product before our competitors. The concept of crossmanning discussed in Section 7, seems to be one of the principles that could be useful in creating sensitive centers.

The model we suggested may seem to be totally event-driven, the system only reacts on external events. This may be so only if sensors are constructed in the way that they react to what becomes visible for every-one, e.g., economic crises of 2008. Having sensitive sensors makes the system proactive. The sensors can early on catch the trends that have not yet produced visible results. Applying Systems Thinking [START_REF] Checkland | Systems Thinking, Systems Practice[END_REF][START_REF] Jackson | Systems Thinking: Creative Holism for Managers[END_REF] can help in creating such sensors. Returning to the example of financial crises of 2008, having a sensor based on the H. Minsky financial instability hypothesis [START_REF] Minsky | The Financial Instability Hypothesis[END_REF], could have helped to avoid the severity of the crises.

As far as process optimization is concerned, in the highly dynamic environment, this concept should be taken with caution. The more optimized a process is, the more difficult it will be to change it. The less optimal process that is easier to change can be much more "optimal" in the long run. In the practical plan, we need to move from the totally prescriptive definitions of the process execution rules to the constraint-based definitions -a combination of guidelines and restrictions, which allow and require creativity from the process participants handling the instance/case. In the scientific plan, we need to abandon the idea of a process as a flow of operation or events, and start considering it as a trajectory in a multidimensional state-space [START_REF] Khomyakov | Achieving Workflow Flexibility through Taming the Chaos[END_REF].

As far as computerized systems to support execution of business processes are concerned, the cross-manning concept requires moving the focus to facilitating collaboration/communication between the members of heterogeneous teams. Translating this requirement into the architecture of business processes support systems, there is a need to reconsider current fixation on the conveyor belt principle (workflow engines) in favor of the construction site metaphor of the shared spaces (such as different social software uses) as suggested in [START_REF] Bider | A strategy for merging social software with business process support[END_REF][START_REF] Bider | Experiences of Using Different Communication Styles in Business Process Support Systems with the Shared Spaces Architecture[END_REF]. In addition, there is a need to have tools that allow the process participants themselves to design and/or change process definitions and adjust the support system to those changes. An example of such a tool is presented in [START_REF]iPB Reference Manual[END_REF].

For now, our three-layered model is just an idea of creating a new modeling technique, and we cannot present its empirical validation at this moment. Quite a lot of research and practical work is needed to convert it into practical modeling notation, and methodology. The promising thing here is that this can be done stepwise. As was shown in section 7, the underlying thinking can readily be applied for understanding some situations. The first step in creating a methodology can be quite simple -design a technique that helps list all enterprise processes, classify them according to the scheme in Section 4, and describe what kind of a sensor each of them has. Based on this list one can start debating the presence, efficiency and sensitivity of existing sensors before raising the issue of optimization of the processes themselves.

Figure 2 .

 2 Figure 2. A compound censor

Figure 3 .

 3 Figure 3. Traditional enterprise structure from the process perspective

Figure 4 .

 4 Figure 4. Cross-manning of business processes

Figure 5 .

 5 Figure5. Viable Systems Model from Wikipedia[START_REF]Viable Systems Model[END_REF]

  that defines when a new BPI system of the given type should be created  Execution rules that define what should be the goal of the process, whom should be included in the process, how the job should be done in the process, how components interact, etc.

	The execution rules can be prescriptive (e.g., what should be done), constraint-
	based restrictive (e.g., what should never be done), recommended (e.g., how normally
	things are done but it is allowed to do it differently), or a combination of the above.
	BPT rules are "imprinted" in manuals, process maps, employees' handbooks,
	computer systems, heads of employees (oral tradition), or a combination of the above.

Acknowledgment. The first draft of the material presented in this paper was discussed in the LinkedIn group Systems Thinking World [10]. The authors are grateful to all members of the group who participated in the discussions, as their comments helped us to considerably improve the draft.


Iyad Zikra

Janis Stirna

Jelena Zdravkovic
email: jelenaz@dsv.su.se

Bringing Enterprise Modeling Closer to Model-Driven Development

Keywords: Enterprise Modeling, Enterprise Models, Requirements, MDD, Model-Driven Development, MDE, Model-Driven Engineering

Enterprise Modeling (EM) provides the means for using models to represent organizational knowledge from different perspectives. When information systems (IS) are involved, Model-Driven Development (MDD) is an approach that focuses on the use of models as primary development artifacts. By observing that EM provides the context for high level requirements, which in turn are the input to MDD, we propose a meta-model that integrates enterprise models and requirements with design models in MDD. The metamodel defines six models that cover both organizational and IS development knowledge. Inter-model relationships ensure an integrated view of the enterprise and the supporting IS by allowing model components to be used across different models. The integrated meta-model is demonstrated through an example case study.

Introduction

Enterprise Modeling (EM) aims to capture and represent organizational design in terms of business goals, processes, concepts, actors, as well as high level information system (IS) requirements by using conceptual models. Many EM techniques have emerged throughout the years, presenting different views of the enterprise and offering a wide variety of possibilities for designing, improving, re-structuring, and automating all or parts of the business in question.

Model-Driven Development (MDD) is a software development approach where models replace programming code as the primary development artifact. Models in MDD are used for describing the IS design to a level of detail that allows automatic generation of a running system. When used in the context of developing enterpriselevel software, MDD has the potential of streamlining the development process. However, the input to the MDD process has to come from a higher level of abstraction, such as organizational designs and requirements, which are often represented by Enterprise Models. Most current MDD approaches implicitly assume that creating the initial MDD model is the responsibility of the modeler and provide little or no guidance for initiating development [START_REF] Zikra | Analyzing the Integration between Requirements and Models in Model Driven Development[END_REF]. The approaches that try to stablish a connection between preceding modeling efforts and MDD rely on mappings between, e.g. requirements and design models in MDD. They still fall short on achieving full integration and supporting the developers in all development phases.

In this paper, we present an integrated meta-model of MDD and EM, taking Enterprise Knowledge Development (EKD) [START_REF] Bubenko | D3: User guide of the Knowledge Management Approach Using Enterprise Knowledge Patterns[END_REF] as an example of a specific EM approach. The aim of this research is to provide a formal connection between the two development activities, thus bridging the gap between designing the organizations and model driven development of information systems. EKD is selected as the candidate EM technique because it includes an overall model composed of inter-related submodels for integrating different views of the organization. Many concepts in our meta-model are based on the EKD approach. The proposed meta-model is a first step towards a complete and tool-supported MDD process. Combining the high-level business-oriented EKD capabilities with the more concrete and IS-oriented MDD principles can lead to better integration between the business and information systems that support it.

The remainder of the paper is organized as follows: Sections 2 and 3 give a short background to EM and MDD. The proposed meta-model is presented in Section 4 and then demonstrated by an example in Section 5. Section 6 is a discussion of related work, while Section 7 presents concluding remarks and issues for future work.

Enterprise Knowledge Development

EM is a process where an integrated and negotiated model describing different aspects of an enterprise is created. An Enterprise Model consists of a number of related "sub-models", each describing the enterprise from a particular perspective, e.g. the purpose of the organization, business processes, entities, and structure. For example [START_REF] Marshall | Enterprise Modeling with UML: Designing Successful Software Through Business Analysis[END_REF] proposes using the UML notation [START_REF]Object Management Group (OMG)[END_REF] to model enterprises.

In this research we have chosen EKD as the EM approach to be integrated with MDD. The following six integrated sub-models constitute EKD, each focusing on a different aspect of the enterprise:

Goals Model (GM)-the organization's vision and strategy; it addresses questions related to what the organization wants to achieve or to avoid and why.

Business Rules Model (BRM)-the business policies and rules; it addresses questions related to business rules and how they support the organization's goals.

Concepts Model (CM)-the business ontology and vocabulary; it addresses the things and "phenomena" covered in other sub-models.

Business Process Model (BPM)-the procedural aspects of business operations; questions related to business processes and how they handle information and material.

Actors and Resources Model (ARM)-organizational structure; addressing the responsibilities for goals and processes and how the actors are interrelated.

Technical Component & Requirements Model (TCRM)-IS needs; addressing questions about the business requirements for the IS and how they are related to other sub-models of the enterprise model.

The modeling components of the sub-models are related within a sub-model (intramodel relationships) as well as with components of other sub-models (inter-model relationships). Inter-model links are particularly useful for developing a holistic view of the enterprise because they allow tracing decisions and components throughout the model. E.g. goals in the GM provide the reasons for including certain processes in the BPM and IS requirements in the TCRM. EKD strongly advocates the use of a participative approach for model development [START_REF] Bubenko | D3: User guide of the Knowledge Management Approach Using Enterprise Knowledge Patterns[END_REF][START_REF] Stirna | Participative Enterprise Modeling: Experiences and Recommendations[END_REF], a technique also applicable in agile development projects [START_REF] Stirna | Integrating Agile Modeling with Participative Enterprise Modeling[END_REF].

Bubenko et al. [START_REF] Bubenko | D3: User guide of the Knowledge Management Approach Using Enterprise Knowledge Patterns[END_REF] identify two purposes for EM: 1) developing the business: shaping the business vision and identifying the strategy and means necessary to attain it, including IS development; and 2) ensuring the quality of the business: creating a unified and shared knowledge culture, and gaining the commitment of different stakeholders. In conjunction with business development, EM often provides input to IS development.

Model-Driven Development

The focus of software development shifted from code to models as a response to the increasing complexity of software and the pressure to shorten development cycles [START_REF] Selic | The Pragmatics of Model-Driven Development[END_REF]. Technology advancements enabled the transformation of models into complete and functional software, making models an essential part of the final product [START_REF] Gašević | Model Driven Engineering[END_REF]. The emergent model-centric approaches are commonly called MDD. No unified definition exists for this new domain, which is sometimes referred to as Model-Driven Engineering (MDE) in the literature. There are however common characteristics that distinguish approaches that are labeled as model-driven [START_REF] France | Model-Driven Development Of Complex Software: A Research Roadmap[END_REF][START_REF] Kent | Model Driven Engineering[END_REF][START_REF] Schmidt | Model-Driven Engineering[END_REF][START_REF] Selic | The Pragmatics of Model-Driven Development[END_REF]. Models are the central concept in MDD; they present different views of a system and guide the development process. The structure and semantics of models are formalized in MDD as meta-models, enabling automatic creation of models. The knowledge used to create models is also formalized as transformation rules, which are based on the language of the models when the transformed models are in the same language or on the metamodels when the models are in different languages. The process for creating and managing the models, meta-models, and transformations is identified by [START_REF] Kent | Model Driven Engineering[END_REF] as part of MDD. Supporting tools are consistently highlighted in the MDD literature as an essential part, even though many MDD approaches have partial or no tool support. [START_REF] Loniewski | A Systematic Review of the Use of Requirements Engineering Techniques in Model-Driven Development[END_REF][START_REF] Zikra | Analyzing the Integration between Requirements and Models in Model Driven Development[END_REF] The interest in MDD is growing despite the existence of many unresolved issues and the limited tool support. Creating the initial MDD model has been identified as a problem in [START_REF] Loniewski | A Systematic Review of the Use of Requirements Engineering Techniques in Model-Driven Development[END_REF] and [START_REF] Zikra | Analyzing the Integration between Requirements and Models in Model Driven Development[END_REF]. The problem manifests itself in a gap between IS design models and higher levels of abstraction. Integration properties were proposed in [START_REF] Zikra | Analyzing the Integration between Requirements and Models in Model Driven Development[END_REF] to establish a connection between requirements and MDD. By observing that EM is a practicable instrument for capturing high level requirements needed as the input to MDD, we propose an overarching meta-model that integrates EM and MDD. The next section describes this meta-model.

A Unifying Meta-Model

The main objective for developing the meta-model is to provide a unified platform for designing enterprise models, which are then used to derive IS models that can subsequently be used to generate a functioning and complete system using an MDD approach. The meta-model defines multiple complimentary models, offering a holistic view of the organization and enabling automatic generation of an IS that is described by the relevant models. The meta-model defines (1) models representing enterprise knowledge (enterprise-level models) based on the EKD approach, namely EKD's GM, CM, BPM, and BRM, as well as ( 2) system-level models, namely Requirements Model (RM) representing IS requirements and IT Architecture Model (ITAM) describing the technical components and user interfaces that are involved in the implementation of the IS.

Relationships between the enterprise-level and system-level models are formalized to support evaluation of the system models and improve traceability to their origins in the organizational design. Coarse-grained relationships give a general overview of the interactions between the models (Fig. 1). Fine-grained relationships, called intermodel relationships, relate model components across different models. They depict the use of concepts of one model in other models and present a more complete view of both the enterprise and the IS. Complete traceability is supported by the metamodel without the need to introduce additional explicit traceability links. The finegrained inter-model relationships are further discussed in the following subsections.

Fig. 1. Relationships between the sub-models in the meta-model

The meta-model in this paper follows a simple UML-like notation. Package symbols are used to denote models in Fig. 1, implying that concepts defined in the meta-model are spread over the six models. Furthermore, generalization links between concepts denote a general-specific relationship, while cardinalities on the relationships express the number of model component instances that can participate in a model relationship instance.

Common Components Model

All models described by the meta-model are derived from common components that provide the basis for other components. The Common Components Model (CCM) is shown in Fig. 2. It is not included in Fig. 1. because it is a conceptual abstraction that spans all other models. The model component is the topmost concept in the metamodel. Each model component has a unique identifier and a text field that allows the component to be labeled with a single name, a sentence, or a long text depending on the modeling needs. A modeling component has a description, which is a text that provides additional clarification for the component.

Fig. 2. The Common Components Model

The relationship concept is a model component that connects other model components with each other. Two distinct types of relationships are defined in the meta-model: intra-model relationships that link components within the same model; and inter-model relationships that enable components from different models to be related with each other. The inter-model relationships facilitate traceability among the models and provide mechanisms to design intersecting models.

Concepts Model

Concepts that are necessary to describe the static aspects of enterprises and information systems are modeled in the CM (Fig 3). They include resources and information objects that are used, processed, exchanged, produced, and stored in the organization, together with their relationships and attributes.

Fig. 3. The Concepts Model

A concept represents entities about which the enterprise stores or processes information. Concepts represent resources, information objects, or other things that are of interest to the enterprise. They are described by attributes that declare properties for the concepts. Concepts can be related to each other using a concept relationship, which can be one of three kinds: the binary relationship, which is a general kind of relationship; the generalization relationship, which relates a general concept to a more specific one; and the aggregation relationship, used to indicate that a concept is composed of other concepts.

Goal Model

Organizational business goals are recorded and represented in the GM (Fig. 4). A business goal is a future state-of-affairs that the enterprise aims to attain, and through which it can grow and generate profit. An enterprise can identify potential desirable situations as opportunities, which highlight new possibilities or capabilities that can be transformed into actual business goals. Both opportunities and business goals are defined as types of intentional components because they share many properties. Moreover, modeling opportunities as intentional components allows the identification of concepts, roles, processes, and requirements; otherwise associated only with business goals. Intentional components can support each other, indicating that achieving one contributes to achieving the other. Intentional components can also conflict with each other when the realization of one challenges the realization of the other. The role which defines an intentional component is captured in the meta-model to provide traceability to the source of the component.

Fig. 4. The Goal Model

The operationalization relationship provides additional structure to the GM by allowing business goals to be decomposed into smaller, more concrete sub-goals. Decomposition can occur in one of three types, or modes: AND operationalization, indicating that the fulfillment of all sub-goals is necessary to fulfill the goal; OR operationalization, when the fulfillment of at least one sub-goal is enough to fulfill the goal; and XOR operationalization, when sub-goals are exclusive alternatives for the goal. Operationalization enables organizing the intentional components as a hierarchy.

Goals have roles that are responsible for them; tracking the progress of their fulfillment and making sure necessary resources are allocated for that purpose.

Achieving the business goals is usually hindered by various obstacles, and it pays to include those obstacles in the model to provide a clearer view of the organizational landscape. Problems that hinder business goals can be either internal to the enterprise, in which case they are considered weaknesses, or external, in which case they are modeled as threats. The cause that explains a problem is a useful insight when identified explicitly, and can contribute to finding suitable measures and solutions. In addition, a business goal is bound by constraints, which represent rules and regulations that affect how the organization operates. Constraints are always external to the organization; internal rules and regulations are described using the BRM.

Business Process Model

Business goals identified in the GM give rise to, or motivate, the design of business processes that describe activities in the enterprise needed to realize the goals. The BPM (Fig. 5) provides a view over the processes and their composition and structure. A process model component stands for different sizes of processes at both the business-and IS-levels, thus providing a unified dynamic view of the enterprise and its IS. The relationship between a process and its sub-processes is captured as a composition relationship, indicating that the sub-processes work together to accomplish the top process. The meta-model includes no limit to the number of decomposition levels, which is left to the specific needs of projects.

Fig. 5. The Process Model

The flow between processes is described using the process flow relationship, which connects processes in one execution flow. The type of the relationship indicates whether the processes are performed in parallel (AND connection), optional (OR connection), or conditional (XOR connection). Processes are affected by events, which are external occurrences that influence the execution of the process and cause it to deviate into certain paths, e.g. at the decision points. Concepts that are consumed and produced are included in the BPM using inter-model relationships, denoting the inputs that guide the process execution and outputs that result from the execution.

Actors that perform processes in the enterprise are modeled as roles, which can also provide and be responsible for goals, and can be related to requirements. A role stands for a general position that is independent of the actual persons filling it, and it can represent physical persons, virtual persons, or automated systems.

Requirements Model

High-level requirements, also called business requirements, express the stakeholders' desires for a future IS. Business requirements are refined into more concrete IS requirements that are better understood by system designers. The line separating business requirements and system requirements is vague and hard to identify, but the decomposition is always necessary. Therefore, the meta-model for the RM (Fig. 6) includes a single requirement component that serves as a high-level as well as a concrete system requirement. Decomposition of a requirement occurs on any level, and continues depending on the judgment of the modeler and the specific needs of the project. The decomposition relationship is used to connect a parent requirement with its child requirements, which can be all necessary (AND decomposition), alternatives (OR decomposition), or exclusive alternatives (XOR decomposition). Requirements that negatively affect the realization of each other are connected using the conflict relationship. Also, requirements that positively affect the realization of each other are connected using the dependency relationship.

Fig. 6. The Requirements Model

Requirements at different levels of decomposition are motivated by business goals. However, some requirements address system related issues that are not relevant to the high-level organizational goals. When those requirements are elicited, information systems constraints that motivate or hinder them must be identified and assessed.

Requirements in our meta-model provide a central connection point between the models. In the modeling process, actors, things, and activities that are involved in a requirement are identified and the corresponding roles, concepts, and processes are linked with the requirement, respectively. Requirements have qualifiers that express additional information about certain qualities a requirement can have, e.g. performing the functionality at certain times or periodically, or the location for storing data.

Business Rules Model

Internal rules and regulations that govern the enterprise provide boundaries for the concepts and business processes. Business rules are often formulated together with the business goals to specify how the goals will be achieved. Concepts and business processes that are motivated by the business goals are governed by the defined business rule, and this is captured in the BRM (Fig. 7).

Business rules are represented in the meta-model as model components that are motivated by business goals. In other words, the business rules affect the fulfillment of business goals. A business rule refers to one or more concepts that are constrained by it. When a rule defines a necessity that needs to be guaranteed at all times by the involved concepts, it is called a structural business rule. When a rule addresses derived or dynamic properties that must be checked at certain points in time or when certain events occur, it is called a behavioral business rule. This type of business rules constraints the enterprise in terms of the change of its state, and can lead to different results depending on the triggering events.

Breaking a structural business rule produces an invalid state for the enterprise, and hence must be prevented. However, it is possible to break behavioral rules, and such breaches entail corrective action that returns the enterprise to a valid state. While structural rules constrain concepts, behavioral rules constrain processes, and can motivate the design of additional processes that are needed to enforce the rules.

IT Architecture Model

Creating a complete IS model involves describing the design architecture that the final system will be based on, and how its different parts will operate conjointly. It also involves describing how eventual users will interact with the system, and other technical details related to the MDD platform used for implementation. This information is captured by the ITAM, which is technology dependent and can exist in various forms for the same GM, CM, BPM, and RM. The ITAM must support intermodel relationships between components of the mentioned models and specific architectural components, depending on the selected implementation architecture. Those relationships highlight the motivation behind architectural design decisions, and provide additional information that can be exploited when transforming the models into an executable system.

An Example Case Study

To demonstrate the use of the proposed meta-model in an MDD setting, we use an example case inspired by the project Energy Efficiency and Risk Management in Public Buildings (EnRiMa) 1The aim of this example is to demonstrate the use of the proposed meta-model starting from high-level enterprise models. First, some business goals are elicited in the context of the EnRiMa project. Other models are then developed from the business goals according to the meta-model. Parts of the models are identified as candidates for IS support and hence realized as a Web services implementation.

. The overall goal of the project is to develop a decision support system assisting building managers in making smart strategic and operational decisions considering a multitude of factors, e.g. occupant needs, market prices, installed technology, environmental factors, and weather.

The business goals used in this example are: 1) satisfy comfort requirements of occupants, 2) reduce CO 2 emissions, 3) increase energy efficiency of the building, 4) enable daily energy adjustments, and 5) balance long-and short-term plans. Fig. 8 shows the GM that describes the goals and their relationships. Goal 4 motivates a process whereby hourly readings of wind speed, temperature, and humidity are collected and compared with historical data to predict a short-term weather forecast. The forecast is then projected on current and prospective energy prices in the market, a step motivated by Goal 3. This process is described using a BPM (Fig. 9) that includes top-level processes and shows the different inputs and outputs involved. Modeling of processes can continue in a real situation by breaking down each process into its constituent parts, until a suitable level of granularity is reached. Each part is itself a process with its own inputs and outputs. Inter-model relationships allow the inclusion of business goals in the process model, providing traceability support between processes and their originating goals.

By identifying processes which merit automation, the requirements describing the information systems that support those processes can be elicited. For example, Process 4 can be implemented as Web services that gather the necessary information and calculate the adjustments to the heating system parameters. The requirements that describe the system for executing Process 4 can be formulated as: 1) the system shall retrieve current energy prices; 2) the system shall retrieve prospective energy prices; and 3) the system shall deploy a predefined set of formulae to calculate the adjustments. These requirements can be decomposed into more fine-grained ones, and, as with processes in the BPM, the decomposition can continue until a desirable level of granularity has been reached. The resulting RM is shown in Fig. 10. The business goal motivating the requirements and the process which is related to the requirements are present in the RM using inter-model relationships. Concepts defined in the BPM and RM are part of a larger CM that describes all relevant concepts needed for building management together with their relationships.

The information encoded in the models discussed so far is sufficient to enable an automatic generation of a service-based system that supports the identified processes and business goals. Each functional requirement in the RM in Fig. 10 is a candidate for becoming a Web service. In this example, manual intervention is needed to select suitable requirements for becoming Web services. However, mapping requirements and other modeling components will be facilitated using an ITAM which defines the relationships between eventual components of the final system. Inter-model relationships between components in the ITAM and components of other models will help formalize the transformation of different modeling components into databases, Web services, user interfaces, or any other type of IS component.

Functional Requirement 3 (see Fig. 10) is a function suitable for transformation into a Web service. Depending on the chosen granularity for modeling the processes and the requirements, the models can be used to generate simple Web services that include only one operation or more complex services that combine multiple operations. The approach provides flexibility for making such decisions, and eventual supporting tools must enable modelers to choose a suitable mapping to simple operations or complex services (using the ITAM). Moreover, the inputs and outputs of the Web service can be derived from the inter-model relationships between requirements and concepts. While these relationships show only the concepts that are related to requirement, referring to the processes that are related to the same concepts can help in identifying whether a concept is an input or an output for the Web service. An excerpt of the generated WSDL code for the Web service definition is shown in the code snippet below. The XML schema definition referred to in "concepts.xsd" corresponds to the concepts defined in the CM. <wsdl:message name="GetAdjustmentsOutput"> <wsdl:part name="HeatingSystemAdjustments" element="xsd1:HeatingSystemAdjustments"/> </wsdl:message> <wsdl:portType name="AdjustmentsPortType"> <wsdl:operation name="GetAdjustments"> <wsdl:input message="GetAdjustmentsInput"/> <wsdl:output message="GetAdjustmentsInput"/> </wsdl:operation> </wsdl:portType> ... <wsdl:service name="HeatingSystemAdjustmentsService"> <wsdl:port name="AdjustmentsPort" binding="someBinding"> <soap:address location="http://example.com/stockquote"/> </wsdl:port> </wsdl:service> </wsdl:definitions>

Related Work

Lin and Sølvberg [START_REF] Lin | Goal Annotation of Process Models for Semantic Enrichment of Process Knowledge[END_REF] present a framework for motivating process models using goal annotations. Ontologies were used to annotate process and goal models on the metalevel, establishing connections between processes and business goals that motivate them. Shahzad et al. [START_REF] Shahzad | Towards Cross Language Process Model Reuse -A Language Independent Representation of Process Models[END_REF] propose a generic meta-model for business processes that combines functional, behavioral, organizational, and informational perspectives. The meta-model is used, together with a generic formal process description, to create a process model repository that enables process model reuse.

Attempts to provide an integrated view of IS requirements using meta-models can be traced back to Jordan and Davis [START_REF] Jordan | Requirements Engineering Metamodel: An Integrated View of Requirements[END_REF]. Recent meta-models for requirements management in software product families are found in Arpinen et al. [START_REF] Arpinen | Meta-Model and UML Profile for RequirementsManagement of Software and Embedded Systems[END_REF] and Cerón et al. [START_REF] Cerón | A Meta-model for Requirements Engineering in System Family Context for Software Process Improvement Using CMMI[END_REF]. The meta-models include relationships between requirements and other organizational entities, such as actors and contracts. Coarse-grained relationships to other parts of the IS development lifecycle, such as system (design) models and test cases, are also present. The meta-model proposed by Goknil et al. [START_REF] Goknil | A Metamodeling Approach for Reasoning about Requirements[END_REF] unifies common concepts in existing requirements modeling approaches. Requirements are described using their properties, types, and relationships with other requirement-related concepts, such as test cases and stakeholders. López et al. [START_REF] López | Metamodeling for Requirements Reuse[END_REF] treat design models as instances of semi-formal requirements models. Use case diagrams, activity diagrams, and workflow diagrams are unified on the meta-level using common modeling units.

While the approaches above include unifying meta-models for IS development, they focus on a single aspect of the final system (processes in [START_REF] Lin | Goal Annotation of Process Models for Semantic Enrichment of Process Knowledge[END_REF] and [START_REF] Shahzad | Towards Cross Language Process Model Reuse -A Language Independent Representation of Process Models[END_REF], and requirements in the others). In contrast, our approach covers a wider range of organizational and IS concerns.

Pastor and Giachetti [START_REF] Pastor | Linking Goal-Oriented Requirements and Model-Driven Development[END_REF] present a generic process for linking i* [START_REF] Yu | Modelling Strategic Relationships for Process Reengineering[END_REF] and the OO-Method-as representatives of Goal-Oriented Requirements Engineering (GORE) and MDD, respectively. By basing the linked meta-models on EMOF [START_REF](OMG), Meta Object Facility (MOF) Core Specification Version 2[END_REF], the authors are able to define an integration meta-model and generate model transformation rules that automatically produce MDD-compliant conceptual models from i* models. However, additional transformations are necessary to produce the final system. Our approach advocates a single-step transformation that eliminates the need for intermediate steps and helps in generating the final system directly from the models.

Conclusion

EM aims at creating a structured and unified view of an enterprise, enabling more informed and accurate decisions to be made. MDD is an approach to IS development that focuses on models as drivers of the development process and part of the final product. In this paper, we have proposed a meta-model that spans EM and MDD to give an integrated view of organizational and IS concerns. EKD was chosen as the EM approach to be integrated with MDD because it includes inter-related sub-models that cover different aspects of the enterprise. The meta-model was designed to support the integration properties suggested in [START_REF] Zikra | Analyzing the Integration between Requirements and Models in Model Driven Development[END_REF] for bridging the gap between requirements and MDD design models. Namely, the following properties are supported:

• Static and dynamic aspects of enterprises and information systems are captured using the CM and the BPM; • Intentional aspects are addressed in the GM, which offers a high-level view of the enterprise aims and lays the context for other models; • Architectural aspects are captured using the ITAM, which relates components of the different models to specific implementation platform components; • Change propagation and traceability are supported by inter-model relationships, which enable the components of one model to be included in other models, offering an integrated view of all models. By integrating enterprise models and IS design models in a single meta-model, the need to transform models between multiple levels of abstraction-a common practice in MDD approaches-is eliminated, leaving only a single transformation step towards the implementation platform. This single-step transformation is further facilitated by the ITAM, which defines the targets that model components will be transformed into.

The meta-model was demonstrated by an example case. However, a larger and more detailed case study is necessary to show the full potential of the meta-model and to uncover the weaknesses in need for improvements. As future work, we will develop an ITAM for a specific implementation architecture, as well as a supporting tool for realizing the case study and for demonstrating the automation that stems from following the MDD principles.

Fig. 7 .

 7 Fig. 7. The Business Rules Model

Fig. 8 .

 8 Fig. 8. Example Goal Model.

Fig. 9 .

 9 Fig. 9. Example Business Process Model.

Fig. 10 .

 10 Fig. 10. Example Requirements Model.

http://www.enrima-project.eu/

Code snippet of the generated WSDL code defining the Web service that corresponds to Functional Requirement 3 (see Fig. 10).

<definitions name="CalculateHeatingSystemAdjustments" targetNamespace="http://example.com/calcadjust.wsdl" xmlns:xsd1="http://example.com/concepts.xsd" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"> ... <wsdl:message name="GetAdjustmentsInput"> <wsdl:part name="WeatherForecast" element="xsd1:WeatherForecast"/> <wsdl:part name="CurrentEnergyPrice" element="xsd1:CurrentEnergyPrice"/> <wsdl:part name="ProspectiveEnergyPrice" element="xsd1:ProspectiveEnergyPrice"/> </wsdl:message>