The Role of Enterprise Governance and Cartography in Enterprise Engineering

Enterprise Modelling and Information Systems ArchitecturesVol. 0, No. 0, month 0000The Role of Enterprise Governance and Cartography in Enterprise Engineering 1

José Tribolet, Pedro Sousa, Artur Caetano

The Role of Enterprise Governance andCartography in Enterprise Engineering

Enterprise artography is fundamental to govern the transformation processes of an organization. Theartefacts of enterprise cartography represent the structure and dynamics of an organization from threetemporal views: as-was (past), as-is (present), and to-be (future). These views are dynamically generatedfrom a continuous process that collects operational data from an organization. This paper defines a setof enterprise cartography principles and provides an account of its role in understanding the dynamicsof an organization. The principles are grounded on control theory and are defined as a realization of theobserver and modeller components of the feedback control loop found on dynamic systems. As a result,an organization can be abstracted as a dynamic system where a network of actors collaborate and produceresults that can be depicted using cartographic maps.

1 Introduction

This paper explores the role played by en-terprise cartography and enterprise gover-nance within the enterprise engineering dis-cipline. Enterprise governance relates to en-terprise transformation since the change ofoperational processes, resources and businessrules define new management boundaries(Hoogervorst 2009). Enterprise architecturecontributes to enterprise transformation as itenables modelling the organization’s struc-ture and dynamics along with the underlyingrestrictions and design principles (Lankhorst2013; Op’t Land 2009). Transformation is of-ten seen as the set of initiatives that changethe organization’s domain from the currentas-is state to an intended to-be state. Thesetwo states describe organizational variablesat different moments in time. The as-is stateis defined by the variables that changed dueto past events, while the to-be state specifiesan expected state configuration of the organi-zational variables. Between these two events,the organization reacts to other events thatare triggered by the operation of the transfor-mation processes.

The issues we address in this position paperfocus in the ability to observe and govern theorganization during such transition. This isimportant because during each transforma-tion initiative an organization has to react toevents. Some of these events may be unre-lated to the transformation initiative but mayimpact the transformation process and there-fore deviate the organization from achievingthe planned future state.

This paper presents two contributions. Thefirst is defining enterprise cartography as afunction of the observer and modeller roles asdefined by the enterprise’s dynamic feedbackcontrol loop. Enterprise cartography is notassociated with the enterprise design, butwith the abstraction and representation of theenterprise reality. Although this differenti-ates enterprise cartography from enterprisearchitecture, it may be correctly pointed outthat cartography is part of enterprise architec-ture. But given the relevance of cartographyto understand the dynamics of the feedbackcontrol loop of an organization, we optedto discuss the concerns of cartography sepa-rately from those of enterprise architecture.

Enterprise Modelling and Information Systems ArchitecturesVol. 0, No. 0, month 0000

2 José Tribolet, Pedro Sousa, Artur Caetano

The second contribution of the paper is stat-ing the empirical principles that ground thedesign of the cartography process to playthe role of the observer and modeller in theenterprise dynamic feedback control loop.Dynamic systems and enterprise governanceare described in sections 2 and 3. Section 4presents enterprise cartography.

2 Dynamic Systems

The application of systems theory to systemsengineering has been discussed since the1970s (Eriksson 1997; Moigne 1977). Sys-tems theory relates to organizational systemsmainly through the principles of dynamic sys-tems, especially control feedback loops (Abra-ham et al. 2013; Santos et al. 2008). These con-cepts can be further combined with classicmanagement theories as a means to clarifyhow feedback loops interact with differentorganizational views, such as governance,management, and operations (v. figure 1).

In control theory, the modeller presents a sys-tem view that specifies its current as-is state(Levine 1996). The current state makes possi-ble to estimate a future state of the system inthe absence of unexpected events. To handlethe potential deviations that occur from suchevents, control theory introduces the conceptof controller. The controller analyses the con-tinuous stream of events and modifies thesystem’s controllable variables as a means ofkeeping the system behaving as planned (v.figure 2). This is similar to the control of aphysical body moving toward a target: themodeller determines the current position andspeed of the object and feeds it to the con-troller; if an unexpected event occurs, thenthe controller corrects the movement of theobject by applying the necessary forces andthereby ensuring that the target is reached.

We argue that the relationships between enter-prise governance and enterprise cartographycan be established using the principles of

dynamic systems feedback control, wherecartography plays the aforementioned rolesof observer and modeller. These relationshipsare explained in the next two sections.

3 Enterprise Governance

An enterprise is a network of independentactors. Actors collaborate with other actorsalong time and thus create a dynamic col-laborative network. Actors also produce au-tonomous behaviour that may change theoverall state of the system. Actors can beclassified ascarbon-based actors, i.e. humans,and silicon-based actors, i.e. computers. Thisnetwork runs within a domain where theindependent actors behave towards a futurestate of affairs, and thus produce events, someof which may be unexpected. Therefore, allenterprise domain state changes are a con-sequence of the individual behaviour of anactor or of the composite behaviour that de-rives from the actor collaborations. Thesecollaborations may occur between actors thatare enclosed by the organization’s boundary,or between an actor that is external to theorganization and one internal actor. So, thebehaviour of an enterprise “is” a result ofwhat “it does”. An enterprise can thereforebe regarded as a large “bionic” distributednetwork of carbon-based and silicon-basedactors that are continuously interacting andproducing behaviour.

The current technological advances make pos-sible near real-time, transparent and ubiqui-tous interaction between people and systems.As such, the boundary between manual, semi-automated and even some automated opera-tions becomes blurred. This means that theactions performed by people cannot be easilyseparated from those of people supported bya network of computers, and from those ofnetworks of computers. These collaborationscan be abstracted as the result of a single net-work that operates in (near) real-time. The


Figure 1: Organizational views and feedback loop, adapted from (Abraham et al. 2013).

Figure 2: A single-input, single-output feedback loop.

actors that interact within this network actautonomously.

Autonomous behaviour is evident from howa person acts within an organization since thestate change produced by a human actor canonly be observed after the action is concluded.But the same phenomenon is also observed oninformation systems because one can only as-sert what a computer actor has produced afterthe actual action is performed. The degree ofpredictability of automated computer actionsis potentially higher than that of humans. Butachieving certainty is not feasible due to anumber of factors. On the one hand, a systemmay not behave as expected due to faults orfailures. And even in the absence of faults offailures, the system may be misaligned withthe business. On the other hand, the interac-

tion between multiple systems can produceemergent behaviour, meaning that the overallbehaviour of the system may not be the linearsum of each individual behaviour unit. Asa result, there is a potential gap between theresults that derive from planned actions andthe actual results. This makes it impossible tofully estimate the outcome of the interactionsin such a network.

This reasoning supports the conclusion thatenterprises are dynamic systems. Enterprisesare actually a system of systems, composed ofand part of other dynamic systems. As such,there is an opportunity to try to understandan enterprise as a complex system throughthe lenses of systems theory, in particularthrough the body of knowledge of systemstheory and dynamic systems control. How-ever, this application must always considerthe intrinsic bionic nature of an enterprise, aspeople cannot be dissociated from its essence.We defend that all this body of knowledgeis directly applicable to enterprises throughenterprise engineering. The fundamentalpurpose of engineering is to provide humans



with artefacts that augment their individualand collective capability to deal with spe-cific situations. Engineering helps humansto understand reality and to pro-actively andpurposefully transform it as idealized by in-dividual and collective goals. This is theprimary purpose of enterprise engineering(Dietz et al. 2013).

How do systems theory and dynamic systemscontrol relate to enterprise engineering? Well,let us start with the “bionic state machine”metaphor presented earlier. According tosystems theory, this model can be abstractedas two separate subsystems: a feed-forward ac-tion system, which is combinatorial in natureand transforms inputs into outputs, and a feed-back cybernetic system, which uses as input thestate observations and results provided by thefeed-forward action system. The feed-backsystem uses this information to continuousestimate the current state of the system. Thisis accomplished by contextualizing the ob-servations, i.e. by situating the observationsinto the semantic model of the system. Basedon these observations, the feed-back cyber-netic system then decides on the actions thatall the actors of the system must perform inorder to keep the system on a trajectory thatachieves its goals. This process is continu-ously performed. These concepts have beenextensively applied to most engineering areasfor at least half a century (Andrei 2005).

In this paper we hypothesize that the ap-plication of control theory is useful to helpunderstanding enterprise engineering. Thenext hypothetical principles characterize en-terprise governance as a dynamic systemstheory problem.

Principle 1 Actions performed by peopleare enacted by the feed-forward action sys-tem. People play multiple actor roles withinan enterprise such as operational, middlemanagement, knowledge work, auditing, ad-visory, governance or executive roles. If an

enterprise is abstracted as a layered system,all these actions occur at the operational layer,where actual operations are performed by ac-tors. People are abstracted as actors playingroles within well specified semantic domainsthat uniquely define their contexts of individ-ual action and interaction (Caetano et al. 2009;Zacarias et al. 2005). An actor is capable ofplaying several roles simultaneously.

Principle 2 A person can be abstracted as asystem of systems whenever its actions andinteractions occur within the enterprise net-work. This means that the roles played bypeople are subject to the rules of the dynamicsystems control model. The actions of a per-son are the result of a combinatorial proce-dure: a person observes the world, attemptsto contextualize and understand its meaning,and then performs an action. This procedurecorresponds to the role of controller. By act-ing as a controller, the person can correct thedeviations between the current state and theintended state. As such, to achieve goals anhuman actor operates his own local feed-backsubsystem. These actions do not occur at theoperational layer but at an higher layer thatplans and controls the operations (Abrahamet al. 2013).

Principle 3 An enterprise is more than thesum of its actors and resources. Organiza-tional factors such as culture, values, power,and hierarchical structures are elements indefining an enterprise. We abstract these“soft” factors as quality requirements thatconstrain and parametrize the operating sys-tem of an human actor. They are key deter-minants to the way a human interprets theobservations of reality, as well as he readsthese observations through his own modelsof the world, based on which his own sensemaking operates. These factors have impacton the actions of a human actor since theychange how it plays the controller role.


Principle 4 Enterprise self-awareness requiresthe specification of the domain of action.This is the realms of enterprise governance.Governance actions are distinct from exec-utive, managerial, and operational actions,because they are geared towards the preserva-tion of the enterprise self-awareness. Hence,governance focuses on the design rules andprinciples that constrain the enterprise actors,along with their actions and interactions.

Principle 5 Maintaining the enterprise as asingle entity requires actors to dynamicallymaintain a view of the actual state of theenterprise.

The previous principles state the relationshipsbetween an individual actor and its own dy-namic control system. But how do the mul-tiple actors, either carbon or silicon, interactand produce composite behaviour? Usinga metaphor: what makes a group of hetero-geneous and autonomous musicians becomea musical ensemble? Why is this collectiveentity more than the linear sum of its indi-vidual parts? So, what defines the boundaryof an enterprise? What forces bind togetherits autonomous actors as a single entity? Webelieve that the answer to this question liesin the enterprise’s “semantic model of itself”.We call this enterprise self-awareness (Abrahamet al. 2013; Potgieter and Bishop 2003; Santoset al. 2008). This means that if an enterprisehas a common semantic model of its actorsthen in becomes a single collective entity. Ifthere is no common semantic model then theactors are unable to be self-aware of theircontext and as a result no single collectiveentity can be defined. This semantic modelis a shared dynamic model that is constantlyupdated by all its active components. It isprecisely this shared semantic model that de-fines a musical ensemble: each musician hasits own role, but both individually and asa whole they are self-aware that they share

the goal of playing the same piece of musicaccording to a set of rules.

The systemic nature of an enterprise and its cy-bernetic attributes stress the need for havingengineering artefacts to support the collectiveunderstanding of its changing reality. Enter-prise cartography is fundamental to supportthis task. Furthermore, this enterprise en-gineered augmented capability is essentialto support the increasing challenges of en-terprise governance, which are essential topreserve the integrity of an enterprise as a col-lective entity. The next section describes thegoals of principles of enterprise cartography.

4 Enterprise Cartography

Cartography is the practice of designing andcreating maps. It is based on the premise thatreality can be modelled in ways that com-municate information effectively. Enterprisecartography deals with providing up-to-datemodel-based views of an enterprise architec-ture and its goal is facilitating its communi-cation and analysis. We have been success-fully applying enterprise cartography con-cepts to enterprise architecture projects (Cae-tano and Tribolet 2006; Caetano et al. 2009,2012b; Sousa et al. 2007, 2009) and developingcomputer-based tools to support enterprisecartography (Caetano et al. 2012b; Filipe et al.2011; Sousa et al. 2011). Currently, the prin-ciples described here are implemented in acommercial tool that is being used in severalmedium and large scale enterprise architec-ture projects 1. This section describes someempirical findings that we have observed inthese cases.

The concept of abstracting reality throughrepresentations is not limited to engineeringdisciplines. Cartography itself is an estab-lished discipline that has played a major rolein the development of mankind. Cartographyis an abstraction process that systematically

1http://www.link.pt/eams/



Figure 3: Relationships between meta-model, views, viewpoints, diagrams, and stakeholders, adapted from (The OpenGroup 2009).

and consistently transforms an observationof reality into a map or a graphical represen-tation. The production of a map embracesmany different concerns, including scientific,technical, and purely aesthetic. Enterprisecartography denotes the discipline that dealswith the conception, production, dissemina-tion and study of the maps of an enterpriseto support its analysis and collective under-standing.

Classic cartography is usually associated withthe representation of static objects, as in thecase of geographic maps. Modern cartog-raphy deals with the representation of bothstatic and dynamic objects and is commonlygrounded in information science, geographicinformation science and geographic informa-tion systems. Cartography must also providemultiple consistent views of the same system.For example, geographical maps often com-bine different views, such as political bound-aries, topographic features and several otherfeatures. This entails defining abstractionrules and classification mechanisms so that

all of views are consistent. The cartographyof dynamic objects also requires to abstractthe rules that constrain how objects changeand relate to each other over time.

Enterprise cartography deals with the dy-namic design and production of architecturalviews that depict the components of an orga-nization and their dependencies. It shares itsconstructs with enterprise architecture, suchas meta-models, models, views, repositories,frameworks, and design rules. However,its goal is descriptive. A view expresses thearchitecture of a system from the perspec-tive of concerns defined by its stakeholders.Views are defined by viewpoints, which es-tablish the conventions for the construction,interpretation and use of architecture views(ISO/IEC/IEEE 2011; The Open Group 2009).Figure 3), taken from the TOGAF 9 specifi-cation, illustrates the basic relationships be-tween these concepts. The following princi-ples distinguish cartography from enterprisearchitecture.


Principle 1 Enterprise cartography uses ob-servations to produce the representationsof an organization. The process of organi-zational data collection is a core concern ofenterprise cartography. Data collection is nota concern of the mainstream approaches toenterprise architecture.

Principle 2 Enterprise cartography focus onthe dynamic description of an organization.It does not deal with the processes or gover-nance of organizational transformation. Thepurposeful transformation of organizationsis addressed by enterprise architecture.

Principle 3 Enterprise cartography keeps up-to-date architectural views. This implies au-tomated or supervised data collection andview creation. Ideally, these tasks should beperformed at the same frequency as that of or-ganizational change. Enterprise architecturetechniques do not aim to provide systematicsupport for data collection nor the automateddesign and creation of views, meaning thesetasks are usually manual and creative.

4.1 Approaches to EnterpriseCartography

There are several approaches to generate or-ganizational models from the data extractedfrom enterprise systems. Configuration Man-agement Databases (CMDB), as defined byITIL (Adams 2009), manage the configura-tions and relationships of information sys-tems and technological infrastructure. Topopulate a CMDB, some solutions provideauto-discovery techniques that detect nodes,virtual machines and network devices to cre-ate infrastructural views. Auto-discovery isactually a cartographic process and requiresthat the type of the concepts to be discoveredis specified in advance (Filipe et al. 2011).The resulting CMDB instance will containa partial model of the organization’s infra-structure. This model can be communicated

through different but consistent visualiza-tion mechanisms, such as textual reports orgraphical models that are designed accord-ing to a symbolic notation and design rules(Lankhorst 2013).

At the business and organizational layer thereare several cartographic techniques definedby business process management (Dumas etal. 2013) and process mining (Aalst et al. 2012).These techniques make use of event logs todiscover process activities, control and dataflows, as well as organizational structures(Aalst 2011; Aalst et al. 2012; Agrawal et al.1998). In this case, discovered processes cor-respond to actual instances of processes, notto the designed processes. Model analysiscan also be used to assess the conformance ofprocesses against constraints (Caetano et al.2012a; Molka et al. 2014). Another exampleof enterprise cartography is the inference ofinter-organizational processes based on EDIevent logs (Engel et al. 2012). Semantic tech-nologies, such as ontologies, can also be usedto analyse enterprise models (Antunes et al.2013, 2014). Business intelligence techniquesthat collect data from organization systemsto produce reports and dashboards are an-other example of cartography (Negash 2004).Business intelligence actually supports thefeed-back control loop by providing man-agers with a model of the organization thatallows them to ground their actions and deci-sions.

Enterprise cartography is already a realityin several domains. However, handling dy-namic objects, time and change is not explic-itly addressed by most approaches. We aim ata generic and systemic approach, very muchin line with the concept of ”Enterprise Archi-tecture Dashboard” (Op’t Land 2009), thatdisplays the enterprise current and futurestates, its performance and the directions ofthe organization transformation process.



4.2 Principles of EnterpriseCartography

This section describes a set of principles thatdefine Enterprise Cartography. These princi-ples use the following definitions.

Project is an transformation process designedto achieve a goal specified by a to-be state.

Organization variable references specific in-formation or a value associated to an orga-nizational artefact.

Organization state contains the values of asubset of organization variables at a givenpoint in time.

As-was state is the set of all organization statesobserved in a specific point in the past.

As-is state is the set of organization states asobserved in the current point in time.

To-be state is the set of organization states thatare predicted to occur in a specific point inthe future.

Principle 4 The as-is state is defined by theas-was and to-be states.

Memory of the past state (as-was) and thefuture state (to-be) define the behaviour ofan organization. The to-be state specifies thegoals of transformation projects. Withoutthe to-be state the transformation processescannot be executed or measured since noproject goals are defined.

Principle 5 The definition of the to-be statealways precedes the definition of the as-isstate.

Organizational artefacts must be always de-fined as goals in the to-be state before beingcaptured in the as-is state. This means thatthe organizational artefacts are not createdincidentally but always as the result of a trans-formation project.

Principle 6 All organizational artefacts canbe classified as being in one of four invari-ant states.

Gestating is the state that describes an orga-nization artefact after it is conceived, i.e. afterit starts being planned, designed or produced.At this state, the artefact does not yet exist asan active element of the organization in thesense it is not yet able to produce behaviourbut can be passively used by organizationaltransactions and processes.

Alive is the state that an artefact enters af-ter birth. Birth is the event that signals themoment when a gestating artefact enters thealive state. This means that the artefact isnow able to produce behaviour as part of theorganizational transactions and processes.

Dead is when a gestating or alive artefact isinactive in the sense it is no longer able toplay a role in the organizational transactionsand processes. This state is the opposite ofgestation that brought the artefact into exis-tence. However, a dead artefact may still haveimpact on the organization. For example,an application or server enter the dead statewhen they stop operating and will remain inthat state until they are fully retired from theorganizational infrastructure.

Retired represents the post-death state wherethe artefact is unable to further interact withother artefacts.

Organizational artefacts exist first in the to-bestate and only then in the as-is state. Thisapplies to each state transition of the arte-fact’s life-cycle. Artefacts are conceived asthe future result of a project, thereby enteringthe gestating state. They remain in this stateuntil the project successfully completes. Af-ter that the artefact becomes alive. An aliveartefact dies when a decommissioning projectcompletes. A gestating artefact can also dieif the project is cancelled or not completed.A dead artefact is retired when a retirementproject explicitly removes the artefact from


the organizational structure. Therefore, allstate changes applying to an artefact are theresult of a transformation project. As such,the to-be state always precedes the as-is state(Sousa et al. 2009).

Principle 7 Organization models and projectsplans are fundamental artefacts.

Organization models and project plans mustbe observed as variables whose values are cap-tured during the as-is state assessment. Thisalso means that architectural views, view-points, models and other architectural arte-facts should be regarded as organization vari-ables. For example, the repository of a UMLmodelling tool holding the specification ofa system under development must be an or-ganization artefact because it contributes tothe specification of the to-be state. In contrast,a project is often regarded as an organiza-tion artefact. For instance, both TOGAF andArchiMate explicitly consider the concept ofproject Work Package. However, organiza-tional models, viewpoints and views are notexplicitly regarded as artefacts by enterprisearchitecture modelling languages. Nonethe-less, system architecture guidelines such asISO 42010 point out the importance of con-sidering these elements as system artefacts(ISO/IEC/IEEE 2011).

Principle 8 The to-be state is sufficient toplan a transformation project.

For the purpose of planning a transformationproject the current as-is state is not requiredbecause the to-be state must fully specify theorganizational goals.

4.3 Discussion

Figure 4 depicts a time line and a series ofevents in time (T0-T5). T0 represents the cur-rent moment, therefore indicating the instantthe as-is state was captured. At T0 the projectP is conceived and enters the gestating state:this project is planned to start at T3 and to

be completed at T5. Events T1, T2, T4 sig-nal the completion of projects X, Y and Z,respectively. Therefore, T1, T2, T4 also in-dicate that the artefacts that were producedby these three projects became alive. Sinceproject P is planned to start at T3 the organiza-tion requires knowing about its state at stateto-be(T3) and not at state as-is(T0) althoughplanning is actually taking place at T0. Thishappens because the completion of projectsX and Y at T1 and T2 may interfere with theexecution of P at T3. Furthermore, the orga-nization also requires knowledge about itsstate at T4 because the changes resulting fromproject Z may also interfere with project P.

To plan a transformation initiative an orga-nization needs to be aware of the set of to-bestates while the project is being executed.A description of the as-is state for planningpurposes is actually of limited use becausethere is often a temporal gap between projectplanning and project execution. On the otherhand, other projects conclude and change theorganization state while the project standsbetween planning and executing. These ob-servations minimize the relevance of the as-isstate as a means to design the transformationprocesses of the organization.

As an example, consider an organizationthat plans the replacement of a system in6 months time and starts today the corre-sponding project plan. The project planningphase must have an understanding of thedependencies between that system and othersystems, as well as to the business processes itsupports. If no state changes occur in the next6 months, then the organization can indeedrely on the as-is state to plan the replacementproject. But if the organization is performinga set of additional transformation projectsthat will change the organization’s state dur-ing that period, then planning the system re-placement project will require knowing aboutthe sequence of to-be states during the next6 months and during the actual execution of



Figure 4: Project planning and execution.

the replacement project. Otherwise, it willnot be possible to plan according to the actualnetwork of dependencies between the systemto replaced and other organizational artefacts.Therefore, for the purpose of project planningand execution, the current as-is state will of-ten not mirror the organization’s reality. Infact, the relevance of the as-is state is inverselyproportional to the number of projects beingcompleted per unit of time. At the limit, alldependencies of the system to be replacedmay change between the planning and ex-ecution phases, meaning that all as-is statevariables will become irrelevant for planningpurposes.Nevertheless, the knowledge about an orga-nization’s current state is a fundamental assetfor its operational management. At opera-tional level, actions and reactions are basedon near real-time observations and events,meaning that planning and execution occurin close sequence. However, the requirementsof the near real-time operational level of anorganization should not be intertwined withthe medium to long-range requirements re-quired for organizational transformation andgovernance.

5 ConclusionsOrganizations do plan and execute projects,regardless of not having a full or accurate rep-resentation of the as-is or to-be states. Such an

accomplishment implies that projects includeto some degree an assessment of the impactof change between and during planning andexecution.

An organization that does not have a repre-sentation of its to-be state will be unable tocreate a detailed plan of project P as depictedin figure 4. This means that parts of the planmust be postponed until T3 to minimize thegap between the planning and execution of P.This reality is commonly observed in manyorganizations despite having impact on theproject costs and risk, and staff assignment.It also interferes with the planning of otherprojects, thereby having negative impact onthe organization’s agility. To remedy thisissue, enterprise architecture projects oftenattempt to obtain a complete and accuraterepresentation of the as-is state. As a result,the primary goal of these projects is an at-tempt to keep an organizational repositoryupdated with an observation of the as-is state.This approach is often justified by statementssuch as “knowing in detail where we standtoday is a pre-requirement to any transfor-mation project.” Although this sounds wise,this is a demanding task in terms of effortand time. Moreover, and as discussed be-fore, the rate of organizational change willmake the as-is state obsolete for the purpose oftransformation planning. Therefore, we posit


that organizations should reassess the actualvalue of enterprise architecture projects thataim capturing the as-is state as an enabler oftransformation planning.

This dilemma is found in many organizations:the contrast between the notion that an as-isassessment is a valuable asset for organiza-tional transformation, and knowing at thesame time that achieving such continuoustask is demanding. This paper defends thatan organization does not need to have a fulland accurate depiction of the as-is state butof its to-be state. The to-be state is specifiedaccording to the specific goals of projects, thatare required for planning purposes. This con-trasts with the as-is state that requires observ-ing the variables of all organizational artefactsthat are not retired. Consider a project thataims creating a new system that will interactwith an existing legacy system. Planning thisproject requires collecting information aboutthe legacy system as well about the design ofthe new system. However, the task of collect-ing information about a legacy system for thepurpose of project planning is actually con-tributing to extending the knowledge aboutthe current state of the organization. This isa potential avenue to sort out the dilemmastated earlier because a representation of theas-is state can be built incrementally by spec-ifying the to-be state(s) that are required toplan the multiple projects of an organization.

This position paper has presented a generalframework that provides representations ofdynamic organizations in the context of en-terprise engineering. It specifically describesa set of principles grounded on dynamic sys-tems theory that provide guidelines on how torepresent a cartographic representation of anorganization. Such representations facilitatethe planning of organizational transforma-tion.

References

van der Aalst W. (2011) Process mining: dis-covery, conformance and enhancement ofbusiness processes. Springer

van der Aalst W., Adriansyah A., deMedeiros A. K. A., Arcieri F., Baier T.,Blickle T., Bose J. C., van den Brand P.,Brandtjen R., Buijs J., et al. (2012) Pro-cess mining manifesto. In: Business pro-cess management workshops. Springer,pp. 169–194

Abraham R., Tribolet J., Winter R. (2013)Transformation of multi-level systems–theoretical grounding and consequencesfor enterprise architecture management.In: Advances in Enterprise EngineeringVII. Springer, pp. 73–87

Adams S. (2009) ITIL V3 foundation hand-book vol. 1. itSMF International, Officeof Government Commerce, ISBN: 978-0113311972

Agrawal R., Gunopulos D., Leymann F.(1998) Mining process models from work-flow logs. In: Lecture Notes in ComputerScience Volume 1377. Springer, pp. 467–483

Andrei N. (2005) Modern Control Theory:A historical perspective.. Center for Ad-vanced Modeling and Optimization, Ro-mania

Antunes G., Caetano A., Bakhshandeh M.,Mayer R., Borbinha J. (2013) Using On-tologies to Integrate Multiple EnterpriseArchitecture Domains. In: AbramowiczW. (ed.) Business Information Systems.vol. 160. Lecture Notes in Business Infor-mation Processing Springer, pp. 61–72

Antunes G., Bakhshandeh M., Mayer R.,Borbinha J., Caetano A. (2014) Using On-tologies for Enterprise Architecture Inte-gration and Analysis. In: Complex Sys-tems Informatics and Modeling Quarterly1



Caetano A., Assis A., Tribolet J. (2012a) Us-ing Business Transactions to Analyse theConsistency of Business Process Models.In: 45th Hawaii International Conferenceon System Science., pp. 4277–4285

Caetano A., Tribolet J. (2006) Modeling orga-nizational actors and business processes.In: Proceedings of the 2006 ACM Sym-posium on Applied computing. ACM,pp. 1565–1566

Caetano A., Silva A. R., Tribolet J. (2009) Arole-based enterprise architecture frame-work. In: Proceedings of the 2009 ACMSymposium on Applied Computing.,pp. 253–258

Caetano A., Pereira C., Sousa P. (2012b) Gen-eration of Business Process Model Views.In: Procedia Technology 5, pp. 378–387

Dietz J. L., Hoogervorst J. A., Albani A.,Aveiro D., Babkin E., Barjis J., CaetanoA., Huysmans P., Iijima J., Kervel S. J. V.,et al. (2013) The discipline of enterpriseengineering. In: International Journal ofOrganisational Design and Engineering3(1), pp. 86–114

Dumas M., Rosa M. L., Mendling J., ReijersH. A. (2013) Fundamentals of BusinessProcess Management, 2013 Edition ISBN978-3642331428. Springer, p. 350

Engel R., van der Aalst W. M., Zaple-tal M., Pichler C., Werthner H. (2012)Mining inter-organizational business pro-cess models from EDI messages: A casestudy from the automotive sector. In: Ad-vanced Information Systems Engineering.Springer, pp. 222–237

Eriksson D. M. (1997) A Principal Expositionof Jean-Louis Le Moigne Systemic Theory.In: Cybernetics & Human Knowing 4(2),p. 42

Filipe J. A. C. B., Coelho M. F. P., FerreiraM. A. M., Figueredo I. C. (2011) SocialResponsibility and Environmental Sus-tainability: The Case of Caixa Geral deDepósitos (Portugal) and Vale (Brazil). In:Editorial Board Members 10(5), pp. 352–

375Hoogervorst J. A. (2009) Enterprise gov-

ernance and enterprise engineering.Springer

ISO/IEC/IEEE (2011) 42010. Systems andSoftware Engineering: Architecture De-scription

Lankhorst M. (2013) Enterprise architectureat work: Modelling, communication andanalysis. Springer

Levine W. S. (1996) The Control HandbookLevine W. S. (ed.). CRC Press

le Moigne J.-L. (1977) La theorie du sys-teme general. Theorie de la modelisation.Collection les classiques du reseau intelli-gence de la complexite

Molka T., Redlich D., Drobek M., CaetanoA., Zeng X.-J., Gilani W. (2014) Confor-mance Checking for BPMN-Based ProcessModels. In: Proceeedings of the 29th ACMSymposium On Applied Computing.

Negash S (2004) Business Intelligence. In:Communications of the Association ofInformation Systems 13, 177â195

Op’t Land M. (2009) Enterprise architecture:creating value by informed governanceSpringer (ed.). Springer

Potgieter A., Bishop J. (2003) The ComplexAdaptive Enterprise: Self-Awareness andSustainable Competitive Advantage us-ing Bayesian Agencies, In: The Journal ofConvergence, UCT Graduate School ofBusiness

Santos C., Sousa P., Ferreira C., Tribolet J.(2008) Conceptual model for continuousorganizational auditing with real timeanalysis and modern control theory. In:Journal of Emerging Technologies in Ac-counting 5(1), pp. 37–63

Sousa P., Pereira C., Vendeirinho R., CaetanoA., Tribolet J. (2007) Applying the Zach-man Framework Dimensions to SupportBusiness Process Modeling. In: Digital En-terprise Technology. Springer, pp. 359–366

Sousa P., Lima J., Sampaio A., Pereira C.


(2009) An approach for creating and man-aging enterprise blueprints: A case forit blueprints. In: Advances in EnterpriseEngineering III. Springer, pp. 70–84

Sousa P., Gabriel R., Tadao G., CarvalhoR., Sousa P. M., Sampaio A. (2011) Enter-prise Transformation: The Serasa Expe-rian Case. In: Practice-Driven Researchon Enterprise Transformation. Springer,pp. 134–145

The Open Group (2009) TOGAF, the opengroup architecture framework, version 9.Van Haren Publishing

Zacarias M., Caetano A., Pinto H., Tri-bolet J. (2005) Modeling Contexts forBusiness Process Oriented KnowledgeSupport. In: Althoff K.-D., Dengel A.,Bergmann R., Nick M., Roth-BerghoferT. (eds.) Professional Knowledge Manage-ment vol. 3782. Lecture Notes in Com-puter Science. Springer Berlin Heidelberg,pp. 431–442

José TriboletDepartment of Computer Science andEngineering, Instituto Superior Técnico,University of Lisbon,Av. Rovisco Pais 1049-001, Lisboa, [email protected]

Pedro SousaDepartment of Computer Science andEngineering, Instituto Superior Técnico,University of Lisbon,Av. Rovisco Pais 1049-001, Lisboa, Portugal.Link Consulting,Avenida Duque de Avila 23, 1000 Lisboa,[email protected]

Artur CaetanoDepartment of Computer Science andEngineering, Instituto Superior Técnico,University of Lisbon,Av. Rovisco Pais 1049-001, Lisboa, Portugal.

INESC-ID, Information Systems Group,Rua Alves Redol 9, 1000-029 Lisboa, [email protected]

The Role of Enterprise Governance and Cartography in Enterprise Engineering

Documents

Transcript of The Role of Enterprise Governance and Cartography in Enterprise Engineering