Atlas: the Enterprise Cartography Tool Pedro Sousa12 , Ricardo Leal2 , and André Sampaio2 1 Instituto Superior Técnico, Av. Rovisco Pais, 1, 1049-001 Lisboa, Portugal, pedro.manuel.sousa@tecnico.ulisboa.pt, 2 Link Consulting SA, Av. Duque de Ávila 23, 1000 Lisboa, Portugal ricardo.leal@linkconsulting.com andresampaio@linkconsulting.com Abstract. The need to maintain architectural representations of enter- prises is an indescribable fact nowadays given their constant need evolve. However, despite the large number of Enterprise Architecture tools avail- able, enterprises are unable to maintain architectural models updated, given the effort it entails. Atlas is an Enterprise Architecture tool con- ceived to reduce the effort needed to keep architectural models updated, in enterprises where changes are constant and design occurs in a de- centralized, distributed and asynchronous process using multiple design tools. Atlas uses Enterprise Cartography as the approach paradigm to be able to generate architectural views automatically from the models and information gathered from multiple sources, with a time bar allowing a seamless navigation in time, from past to future models. Key words: Enterprise Cartography, EA, Enterprise Architecture, Ar- chitecture Visualization, Architecture tools 1 Introduction The need to maintain explicit knowledge of the architecture of enterprises is an indisputable fact nowadays given their constant need to evolve. Either for the purpose of enterprise governance, engineering, compliance or maintenance, ar- chitectural representations are an enterprise asset that must be governed[1]. By explicit knowledge we consider both the existence of models of the Enterprise Architecture, hereafter EA, kept in some repository as well as the capability to present graphical representations of the enterprise artifacts and their dependen- cies, also referred as architectural views[2, 3], here after referred as EA views for space reasons. We refer to enterprises and not to organizations since the first term has a wider scope according to the the Open Group definition were ”enterprise is any set of organizations that have a common set of goals”[2], and the approach presented here applies to both. An example of an enterprise is the Portuguese National Health System 1 , that includes more than one hundred health organiza- tions. 1 Servio Nacional de Sade: https://www.sns.gov.pt 2 Pedro Sousa et al. We also consider a distinction between enterprise transformation and evo- lution, the difference being that the former is mostly related with top level restructure and the later is related with the optimization of current state of affairs[4]. Despite the differences, they both require EA as input data and they both causes changes in enterprise, thus likely induces changes in the EA. Here after we use the term change initiatives to refer to both transformation and evolution initiatives. Since change initiatives are temporary, unique and a pur- poseful activity, they correspond to the concept of projects as defined in the project community[5]. Stefan[6] presents a list of 28 EA application scenarios and the corresponding literature sources, making clear importance of knowing the EA for enterprise maintenance, planning and evolution. In its simpler and basic from, information about EA boils down to the list of enterprise artifacts and their dependencies. Given the variability and quality of existing EA tools and their representation capabilities[7], one could argue that enterprises could easily create and maintain an EA repository where all models are kept updated so that core enterprise activities could benefit from such information[6]. However, based on our experience of nearly two decades in organizations from various countries and industry sectors, we found that this is not the case. On the contrary, enterprises are far from being able to create and maintain an EA repository updated, given the effort that such endeavor would entail. We believe that a significant part of such extra effort results from the following organizational aspects: – Enterprise evolution uses multiple ”Enterprise Architecture” tools. Enterprise evolution uses multiple tools for EA, being office tools commonly used ones. Most of the times such tools are not integrated and do not provide coherent information. For example, when the board of director of a company, acting as an architect designing the company, decides to create a new department they will not go to an EA tool to model the new department. Most likely, the decision will appear the board meeting minutes (probably an office document) a few weeks or months before the intended date. If the organization structure is modeled in some EA tool, effort is required to update it in conformity with this new design. The person that performs such update in the EA tool is not designing but merely updating the model and its architectural representations. – Enterprise evolution is mostly a distributed and asynchronous process. Enter- prise evolution is planned and designed by different units in an asynchronous and distributed process, involving many actors and many dimensions of con- cerns without formal mechanisms of communication between the different de- signers. For example, when a director decides to make changes in their de- partment, it probably will conduct meetings with other departments to check for possible dependencies and impacts. Directors of other departments can do the same for their departments. Despite the number of face-to-face meet- ings, there is no design process established so that the knowledge gathered in such meetings is consolidated and shared across the enterprise, so that design actually uses coherent and updated information. Atlas: the Enterprise Cartography Tool 3 In such context, one can envisage the huge effort required to update the models in the EA tools used. The fastest the enterprise changes, the more effort is required to keep such models updated. When enterprises are already faced with lack of resources for the day to day projects, they are not willing to allocate effort to keep enterprise models updated. But the problem is actually more complex because enterprises models are also a moving target. In fact enterprises need models that refer to different points in time, namely: AS-WAS models. These models represent the enterprises past state of affairs, in- cluding not only the past architecture but also the plans of change initiatives of the past. They are most useful for auditing and accountability purposes since they can hold justifications for the decisions taken in the past. For example, the decision took in the past to acquire development capacities on some technology could be sustained on the plans of a change initiative to build new products using that technology, regardless the fact of that change was actually put forward or dismissed. AS-IS models. These models represent the current enterprise. AS-IS models are required for current operations and for reacting to events. TO-BE models. These models represent the future enterprise, and are critical for planning the next change initiatives, as recognized both by EA[8, 9] and project management[10, 11] communities. In fact, to plan a project that will start in 6 months, you need to know how the enterprise will be when the project starts, not what it is today, as many changes can come in the meantime. Naturally, AS-WAS models are just the old AS-IS and do not pose any challenge. But AS-IS and TO-BE models are real challenges, since they must be take into consideration the multiple ongoing change initiatives. This difficulty has a substantial impact on the ability to plan change initiatives and, consequently, has an impact on the costs, time and risks of achieving their expected outcomes[8, 11]. So, the focus of our research has been in finding a low effort method that allows enterprise to have updated AS-WAS, AS-IS and TO-BE models and EA views. To keep architectural models and views updated, one needs to address two main issues: (i) how to gather information about the changes in the enterprise models and views and, (ii) how to update the architectural models and views based on the gathered information. Again, our experience in actual companies has shown us directions for such questions. – Gather information about the changes. Our finding is was that, in general, it is easier to gather information about what people are currently doing than about what they did in the past. Since what people are doing today is what most likely will be enterprise TO-BE, this finding means that it is easier to know the expected TO-BE than the AS-IS of the enterprise. So, since TO-BE models will become AS-IS and AS-WAS, this finding tell us that the focus should be target to TO-BE models. 4 Pedro Sousa et al. – Update EA views. Our finding is that hand-draw EA views will likely remain obsolete much longer than generated views. Hand-draw models requires plac- ing symbols in a drawing canvas, where aesthetic aspects are one key concern and time consuming factor. Therefore, to keep such views updated, one needs both to update the contents as well as the aesthetic aspects. So, this finding tell us to avoid hand-draw view and support only automatic generated views from gathered models (information). Atlas2 was designed to explore the findings presented above. It is an EA tool conceived to reduce the effort needed to keep EA views updated in enterprises designed in a decentralized, distributed and asynchronous process using multiple design tools. In Atlas, EA views are generated automatically and have a time bar allowing a seamless navigation in time, from past to future state of each EA view. Information about changes is gathered by the observation of the plans of ongoing change initiatives. This approach was first presented in[12], initial implementation was described in [13, 14], and results from first projects were presented in[15, 16]. The term Enterprise Cartography was coined in[17]. In the next section we present the concept of Enterprise Cartography, and then we present relevant aspects of the Atlas tool in supporting the above ideas. 2 Enterprise Cartography Simply put, EC is the process of abstracting, collecting, structuring and rep- resenting architectural artifacts and their relations from the observation of en- terprise reality. The expression ”enterprise reality” refers to the present state of the enterprise. Traditionally, the observation of this reality is a subjective perception of an observer, and consequently it is probable that there are differ- ent actors that perceive different realities of the same enterprise. However, as we propose and will become clear along the text, the perception of the present state of the enterprise (the reality) is sustained on relevant facts captured in logs and models, and represented through artifacts based on previously defined and agreed upon models. We refer to ”architectural artifacts” as the enterprise’s observable elements whose inter-dependencies and intra-dependencies express the architecture of the enterprise. Naturally, different institutions may consider various sets of artifacts as part of their architecture. To abstract, structure and represent the architecture related artifacts, one needs the whole set of knowledge and concepts implied in architecture visualization and representation. For example, the concepts of semiotic triangle[18, 19], the model of architecture description presented in ISO IEEE 1471[3] and a symbolic notation, such as the one used in ArchiMate[20], are concepts necessary to the production of EA views. Ongoing change initiatives and their plans are an essential part of enterprise reality because they define the near future TO-BE of the enterprise if no further 2 www.linkconsulting.com/atlas Atlas: the Enterprise Cartography Tool 5 decisions are taken that might have an impact on them. This is a fundamental concept that we call emerging AS-IS, which we define as the state of the enter- prise after successful completion of ongoing change initiatives. This corresponds to the inertia of a body; if no contrary action is taken, inertia determines the body future position and speed. Similarly, if no opposite actions are done, on- going initiatives determine the future of the institution and thus the TO-BE of models and architecture. Given that in today enterprises, change initiatives are omnipresent, the con- cept of Emerging AS-IS is not only an essential capacity for the planning of new change initiatives, but also for the monitoring of the enactments of ongoing change initiatives. When driving a car the faster the car is moving, the farther ahead one should focus our eyes to match the longer time and distance context within which we need to steer it. Likewise, when steering an enterprise, the faster the enterprise is changing, the more important is to know the emerging AS-IS, as time flows. Enterprise cartography is a purely descriptive perspective, since it does not explicitly incorporate the purposeful design of the new enterprise artifacts, as one expects in EA. Such a difference is also evident in the definitions of the architect and cartographer roles. According to the IEEE Standard Glossary of Software Engineering Terminology[21], the term architect is defined as ”The person, team, or organization responsible for designing systems architecture”, and in the Merriam-Webster dictionary[22], the term cartographer is defined as the person who makes maps. So, an architect is essentially a person that designs and shapes intended changes to the architecture of the present enterprise reality, while a cartographer is essentially a person that aims at representing reality as it happens, including such changes as they are occurring. 2.1 Enterprise Cartography Principles Principle 1: Change initiatives are enterprise artifacts. A change initiative is an enterprise artifact. This statement is in line with most architecture guidelines such as the Work Package concept in both TOGAF[2] and ArchiMate[20]. However, we go further and also state that their plans can be observed as part of the enterprise AS-IS models. We as- sume that change initiatives have plans because they purposefully aim at some desire goals and therefore should have plans to achieve them. Further- more, these plans and goals includes TO-BE models of the enterprise . Principle 2: Changes in the set of productive artifacts are planned ones. This principle states that artifacts do not become productive or non- productive randomly, but only as a result of change initiative. Since change initiatives are also enterprise artifacts (principle 1), an artifact becomes pro- ductive or non-productive only by the action of another productive artifact (the change initiative). Notice that the assumption that ongoing change ini- tiatives are productive artifacts, is sustained by the purposefulness aspect of the change initiative, by which the enterprise becomes more valuable after the purposeful changes than before. 6 Pedro Sousa et al. Principle 3: All enterprise artifacts have a five-state life-cycle: con- ceived, gestating, alive, retired and removed. Despite the fact that common EA notations (e.g.[20] do not formalize ar- tifacts states, it is many convenient to have models that mix existing and not existing artifacts, to express model changes. In this principle we say that existing artifacts with an enterprise do not ”fell from the sky”, but go through an evolution process instead. Let us first consider as productive the artifacts as the ones that are somehow involved in the enterprise business processes that produces values. In figure 1 we present these five states, their fundamental transitions and there classification with productiveness: Non Productive Yet , Productive and No Longer Productive states. Fig. 1. Existence Artifact life-cycle – Conceived state, as the first state of existence. It corresponds to a state where the artifact is planned but its materialization into a productive artifact did not started yet. A conceived artifact is an idea that exists TO-BE models (or plans) of some change initiative, even if itself is still in the conceived state. – Gestating is the state when an artifact is being constructed or acquired to become productive. As conceived artifacts, gestating ones do not play a role in the enterprise transactions and processes. This state only differ- entiates from the conceived state by the fact that the change initiative that aims at putting the artifact into production has already started. An ongoing change initiative is necessarily a productive artifact, since it can have an impact on other productive artifacts and is expected to produce value after its completion. – Alive. An alive artifact plays purposeful roles in the enterprise to create value. Conceived and Gestation artifacts might have an relationship on life objects, namely in the ones that are conceiving or creating them. But their relation is a passive one, not a purposeful role as alive objects must have to create value. From Principle 2, it is clear that an artifact cannot Atlas: the Enterprise Cartography Tool 7 be brought into existence as alive; it always exists first as conceived before being alive. Notice that in this paper we only consider Alive as the only productive state. However, one can consider other productive states, such as for ex- ample the Deprecated state. However, it is not relevant for the purpose of this paper and we continue with the case of alive as the only productive state. – Retired 3 . is when an alive artifact no longer plays a role in the enterprise transactions and processes to create value. As in the conceived and gesta- tion states, a Retired artifact may still have an impact on alive artifacts. In fact, even if it does not create behavior or value to the enterprise, it may be the target of several housekeeping activities that are necessary after being dead. The dead state can be achieved directly after gestating state, without becoming alive. An artifact planned to become alive by a given change initiative might never be alive either because the initiative was canceled or because it simply changed plans and decided to no longer put that artifact into production. – Removed. Represents the post-Retired state where the artifact has no im- pact in the remaining artifacts. A removed artifact is unable to interact with alive enterprise artifacts. An artifact can move from conception di- rectly to removal when it never materialized in a gestation, meaning that it never went beyond an idea. Principle 4: The TO-BE state precedes the AS-IS state. This principle states that productive artifacts in the AS-IS model existed before in the TO-BE models of some changing initiative. Furthermore, such models were part of the enterprise observed AS-IS at some point in time prior to the current time. Principle 5: The emerging AS-IS can be inferred by observing the AS- IS of an enterprise. The emerging AS-IS state differs from the AS-IS state by the artifacts planned to be brought into production/retirement by ongoing change ini- tiatives. Since ongoing initiatives are alive artifacts, their plans (TO-BE models) are in the scope of the cartographer observations of the enterprise reality. Therefore, one can foresee the set of productive artifacts at some point in time in the future by consolidating the AS-IS with the TO-BE models of the ongoing change initiative whose completion date precedes the desired moment in time[12]. This can be stated as: P (tm ) = P (t0 ) ∪ N Y P (CItn ) \ N LP (CItn )∀t0 ≤ tn ≤ tm (1) Where P (t) represents Productive artifacts at time t, N Y P (CIt ) and N LP (CIt ) represents respectively Not Yet Productive and Not Longer Productive arti- facts in plans of Change initiatives that produces results at time t. 3 In previous publications the Retired stated was named as Dead. 8 Pedro Sousa et al. 3 Atlas Overview Altas is a web based EA tool providing all functionality one could expect from such a tool. It allows the full configuration of the meta model, i.e. the classes and references types whose instances are used to express models of the organization. Users can also configure in and out data both in format as well in contents for integration with other tools and systems. Atlas supports custom configured user interfaces. Given the wide scope of us- age of EA tools within organizations, it will likely be used by employees without basic modeling concepts. So, besides allowing the configuration of elements in Atlas default interfaces (e.g, tabs in object edition properties), it allows users to configure specific forms, where users only see the desired properties, even if they are from different objects. Atlas also provides analytic elements such as charts, dashboards and EA views that we called blueprints. Atlas also supports the configuration of behavior associated with EA views, validation rules, state propagation between objects in the repository, among others. Such behavior can be stated both in queries and rules that run directly on the selected repository as well as in jobs and batch’s that run on a dedicated sandboxes. Fig. 2. Atlas collecting AS-IS and TO-BE models and produce AS-WAS, AS-IS and TO-BE EA views We now focus the description of how Atlas supports enterprise cartography. A typical scenario is presented in figure 2 where information from several sources, including office tools, is processed and feeds the generation of AS-WAS, AS-IS and TO-BE EA views and analysis. In this scenario, enterprise artifacts and their relationships exist in multiples sources, and each source will likely have its own meta model. Furthermore, information in each source may be related with the past, present or future of EA. Atlas: the Enterprise Cartography Tool 9 3.1 Model transformation Model transformation occurs whenever data flows between sources with different meta models, as is the case when Atlas gathers information from other sources, and has been a relevant topic in software development and integration[23]. Among the different technologies to handle model transformation[23], in At- las we adopted a two step approach, each with its own technology. The first step deals with the format transformation and is based on XSLT[24] which is very common and convenient for processing XML files. The second step deals with the actual model transformation, and uses a high level type-based rules that operates on types, instances and relationships. Consider the case where one wants to import a BPMN[25] model and that Data Stores must be imported as Applications in the Atlas repository. To con- figure such rule, one assigns a batch to the desired source or file extension and then defines three jobs. The first job is configured with the XSLT script that converts the BPMN tool format into Atlas XML format. The second job is con- figured with text file script with the transformation rules, that transforms the source model and objects into Atlas model and objects. Finally the third job imports the transformed objects into the Atlas repository. In the example given, the transformation rules script is a ”rename data type Data Store to Applica- tion”. The names of the Data Stores in the BPMN model are matched against Applications in the Atlas repository, and unmatched Data Stores will yield the creation of new Applications, as discussed in the next section. If several batchs are assigned to the same source or file extension, the user is requested to select one to upload the file. This is a very useful feature since within the same enterprise, different teams or departments may use the same notation differently and different rules might be required. Another rather important aspect is to be able to perform different a behaviour in case of the imported artifacts match with objects that already exist in the Atlas repository or if new objects were created during the importation. The rules allows the importation behaviour to be dependent of any state in the Atlas repository, but the match for existing objects is done solely on the object names, as discussed next. 3.2 Object Names In the scenario presented in figure 2 one needs to establish a mechanism to match objects existing in different sources that correspond to the same enterprise artifact. In other words, one needs an identification mechanism valid throughout the different sources to match imported objects against the ones that already exist in the Atlas repository. The use of 128 bits Object Identifiers (OIDs, also known as UUIDs) ensures uniqueness for most practical purposes even when generated by different and independent tools. However, these system-generated OIDs are not useful in the scenario presented in figure 2, since the same enterprise artifact would have objects with a different OID in each source. 10 Pedro Sousa et al. Change is also a factor against the use of OIDs. Consider that a process modeling tool holds a model of the sales process in which the CRM application is used to inquire the status of the client payments. Later, the process changes and instead of using the application CRM, it now uses the application ERP for the same purpose. This change can be done simply by change the application name, from CRM to ERP. However, in this case, the name has change but the OID in the process modeling tool is the same, despite the enterprise artifact has changed. This leads to a situation where the same object now referrers to a different enterprise artifacts, breaking the existing biding between OIDs and enterprise artifacts even in the context a single tool. User defined object names can easy the task of matching objects between sources, if object names correspond to the names of the artifacts have in the enterprise. However, in most cases, object names are used defined and normally are not unique, since uniqueness is assured by OIDs. In Atlas, we took a differ- ent approach where identification and denotation is established by user defined object names[26] and OIDs are not disclosed to user, except for audit traces. This approach implies that, from the user perspective, objects of the same class cannot have the same name. In practice this can be a strong restriction in large enterprises where one could expect to have several organizations with different business processes or actors with the same name. For example, in the case of Portuguese National Health System, one could expect to have Actors with the same name in different hospitals. To support this scenario, users can define composite object names, by selecting object properties to be used for its identification, as primary keys in relational databases. In this case, the name of the object could be defined by both hospital and Actor names.Notice that users can change the name of objects, given that they are object editable properties. Despite the fact that in most situations users deal with a flat object name space, full object names are unique URLs composed as follows: serverURL/RepositoryName/ClassName/ArtifactNameField N. .. .ArtifactNameField 0. The concatenation of the fields ArtifactNameField N to ArtifactNameField 0 must be unique within the objects of the same ClassName. All fiels but the last are optional (i.e can be null ), except the last one ( ArtifactNameField 0 ) that cannot be null. 3.3 Object State In Atlas, object state is defined as a set of properties values, whose types are user defined. A time bar in the object edition interface allows users to visit properties past states, up to the time of its creation. Basic types as Numeric, Text, Rich Text, Hyperlink, Boolean are available. Users must define their own reference types for reference properties Object properties do not change type (structure) over time, this means that, for example, a numeric property cannot not become a reference property. How- ever, object sate, as a collection of properties, can change structure over time Atlas: the Enterprise Cartography Tool 11 since properties may be added or removed from its class over time as discussed in the next section. Therefore, objects of the same class can have an entirely different set of properties. References properties are assured to be either null or to refer to one or more objects. There are no dangling references, since reference value assignment trig- gers object creation and object deletions nullify references. In Atlas, object are created when their names are registered thus, by assigning a new name (value) to a reference properties a new object is created with that name. Such created object has no state yet, only a name. By default reference properties have no state associated besides besides the name of the denoted object. However, in some situations it is very convenient to add properties to references. This is done by binding a class with a reference property, whose structure becomes the structure of the class. Any class defined in the meta model can be bound to a reference property, and the same class can be bounded to different reference properties. 3.4 Meta model Co-Evolution As described earlier, classes also change over time whenever users remove or add properties. By moving back the time bar in the class edition interface, one can see the class properties at any point in time, up to time the class was created. Property creation and removal does not affect the state of the objects in the repository. If a property is deleted from a class at a given time, it will no longer be visible in the object’s structure after that time, however, as soon as the time bar goes back in time the deleted property will appear in object state history with the corresponding values. Besides adding and removing properties, Atlas also provides support for com- plex operations in meta-model and is able to propagate the necessary changes to objects in the repository. For example, the Property to Class meta model operation promotes a textual property to a reference property to a class created from the original text property. An example could be promoting the Home Ad- dress text property of a Client class into a reference property to a new class Home Address, so that clients with the same address could share the same ob- ject. A meta-model evolution primitive catalog, with primitives such as Flatten Hierarchy, Merge Class, Split Class, Property to Class, Class to Property, among others[27, 28] is available. These type of changes in the meta model requires the changes on existing objects in the repository according with the changes made to the corresponding classes. To support such operations, Atlas is able to inform the impact that each change has in the objects existing in the repository and execute them if the necessary actions can be performed automatically [29, 30, 31]. 3.5 Object life-cycles Object life-cycle is defined over a set of object user defined properties of type, one for each life-cycle state. Users can define several life-cycles for the same class. 12 Pedro Sousa et al. For example, for the application artifact, one may define the existence life-cycle and technical quality life-cycle. For each life-cycle, users can define any number of states, and assign a color to each one, so that objects are shaded with the color corresponding to the state of the object at the selected date in the EA view. As explained in the next section, Atlas has specific built-in behavior asso- ciated with the visualization of object life-cycles that requires uses to classify them as Not Yet Productive, Productive or No Longer Productive. Users define life-cycle states in order and some sates may be declared as Productive. The states prior to the first Productive state are considered Not Yet Productive and states after the last Productive state are considered No longer Productive. 3.6 Visualizing AS-WAS, AS-IS and TO-BE EA views In atlas, EA graphical views are generated on-the-fly given its unique name, in the form of an URL as serverURL/RepositoryName/EAViewName?arguments. This means that, by placing hyperlinks to EA views, users that access and in- teract with them outside the Atlas tool in documents or in other web interfaces. EA views are defined in a simple XML language, where one can define con- tainers that can hold others containers or a content query whose result set de- termines the objects that will be displayed inside that container. Containers can be set in a hierarchy and grow and shrink within user defined limits according to the number of objects of the query result set. Objects can also be containers, whenever one wants other results sets to be presented inside. Once generated, EA views are interactive interfaces where users can navigate in time, run predefined analyses, jump to another EA views and drag objects between containers, triggering containers out-query and in-query to do the nec- essary state update associated with the object movement between containers. For example, dragging an object of actor John from a container representing Sales Unit to a container representing Legal Unit will trigger the corresponding out-query on the Sales Unit and in-query on the Legal Unit containers with the actor John as argument. In what concerns time navigation capability of EA views, in Atlas each and every EA view is as a movie, where one can see its contents from the minimum to the maximum date found among all objects that encompass the EA view. As presented in figure 3, the time bar has two handlers, one on the left for the lower date and another in the right for the upper date. Fig. 3. EA view Time bar By moving the time bar handlers back and forward one can see the architec- ture view in the selected time. The visualization can occur either in Absolute Atlas: the Enterprise Cartography Tool 13 Mode or Gap Mode. In the Absolute Mode, the view presents the contents that corresponds to the time selected. Two options can be selected: – Default: Only productive objects at selected time are presented. Symbols are presented in their default color. – life-cycle: All objects are presented, but their symbols is shaded with the life- cycle colors. For example, a typical life-cycle configuration is to shade in grey the artifacts that are Not Yet Productive at the selected time, and to shade in red the objects that are No Longer Productive objects at the selected time. In Gap Mode, the Visualize the view presents the gap between two points in time Ti and Tf , by shade the objects symbols according to the difference of life-cycle state of each object on the selected Ti mes Ti and Tf [32]. In this mode, artifacts are marked as: – Introduced. An artifact is considered to be introduced between Ti and Tf if it is Not Yet Productive at Ti but it is Productive at Tf . – Withdraw. An artifact is considered to be withdraw between Ti and Tf if it is productive in Ti and is No Longer Productive in Tf . – Changed. An artifact is considered to be changed between Ti and Tf if it is Productive in both Ti and Tf and if at least one artifact with which it has a reference to as been introduced or removed between Ti and Tf . The users can select the depth of the graph traversal analysis and for each step, the references to be used. In the next three figures (4 to 6) we present the same EA view with different options and dates of visualization. The first figure presents the architecture at 10/05/2018 in absolute mode with life-cycle option on. The container in the middle show the components of application Account Management App, that consume services in the container on the middle left, that in turn and provided by applications in the leftmost container. Likewise, the Account Management App components provide the services presented in the middle right container that are consumed by the applications in the rightmost container. Bellow, one presents the data objects used in each service. Objects shaded in grey or red are, respectively, Not Yet Productive or No Longer Productive at 10/05/2018. By switching the life-cycle mode off, the shaded objects (both introduced and Withdraw) disappear from the EA view, leaving only the objects that were, are or will be4 productive at 10/05/2018. The corresponding figure is not shown since it can be easily perceived. By moving the left part of the time handle back in time to 05/04/2014, the visualization switches to Gap mode between 05/04/2014 and 10/05/2018, as presented in figure 6, where introduced objects appear in green and withdraw ones appear in red. Next, we set the life-cycle mode on again, mixing the Gap and life-cycle modes, as presented in figure 5, where the evolving objects are shaded in two 4 Both the dates used in this example (05/04/2014 and 10/05/2018) could refer to the past, present of future. 14 Pedro Sousa et al. halves: On the left side, with the color associated with the life-cycle state at the first date (05/04/2014) and, on the right side, with the color associated with the life-cycle state at the second date (10/05/2018). Fig. 4. EA view at 10/05/2018 with object life-cycle Fig. 5. EA view Gap between 05/04/2014 and 10/05/2018 The time bar presented in these three figures show four markers, excluding the extremes, revealing the dates of change in that EA view. These dates cor- respond to object life-cycle evolution but can also be traced back to the change initiatives that have produced such evaluations, as explained next. Atlas: the Enterprise Cartography Tool 15 Fig. 6. EA view Gap between 05/04/2014 and 10/05/2018 with life-cycle 3.7 Change Initiatives According to cartography principles, enterprise artifacts evolve in its life-cycle as a result of some planned change initiatives. In Atlas, used defined class may be a change initiative class, and more than one change initiative class may exist. For example, one may define the Project class as change initiative of Technology artifacts, and the Work-Package class for business changing initiatives. For simplicity, Atlas assume that change initiatives produce the expected re- sults at the very end, meaning on the date they become non-productive. To model a situation where a change initiative produces results before its non productive date, one must use a hierarchy of change initiatives, where the top one has a child for each result it has to produce with the non productive date matching the desired date. The relationship between change initiatives and object life-cycle states is a key factor to simplify the update and management of enterprise artifacts life- cycle dates. For example, if a project, that is replacing one application by a new one delays one month, this delay should be reflected in the life-cycle of both applications, specifically in the old application retirement date and in the new application alive date. In Atlas this relationship is established by a user defined reference property declared at the class level, either at the change initiative class or at the object class. For example, in a typical scenario, one may define the Alive List and the Retired List reference properties in a project class to identify the objects that will become alive and retired. Such relationships allow the update of objects life- cycle according to the life-cycle of the corresponding change initiative. In this scenario is, the kickoff and completion of change initiatives yields the following behavior: – When the change initiative starts: propagate the current date to both change the initiative alive date and gestation date of objects in the Alive List. 16 Pedro Sousa et al. – When the conclusion date of a change initiative has a new forecast: propagate the forecast date to the retired date of the change initiative, to the alive date of objects in the Alive List and to the retired date of objects in the Retired List. Such state propagation is not a built-in behaviour in Atlas and must be con- figured in state propagation rules associated to object life-cycle. This provides more flexibility and independence regarding to the actual life-cycle states the user can define for each class. A more advanced usage of these dependencies and rules is to perform repository coherency validation analysis, in particular based on the time dependent relationships[33]. 4 Conclusion The goal we pursuit with Atlas and Enterprise Cartography is to be minimize the effort required to provide updated and trustful EA views, in enterprises where their architecture is the result of many local architectures, each designed with different drivers and optimization factors. So far, we can say that achieving this goal is fundamentally dependent on the enterprise’s ability to provide good enough plans and descriptions of their change initiatives. Using the scenario presented in previous section, this boils down to having the Alive List and the Retired List of change initiatives completed. In such case the effort required to keep AS-IS and TO-BE EA views updated is non-existent in practical terms. Since the Alive List and the Retired List of a given change initiative represent, for all practical matters, what needs to be done in that change initiative and what impact it has in the enterprise, they are also related with the cost, time and risk of that change initiative. In other words, the can conclude that the more the enterprise is willing to manage cost, time and risk of their change initiatives, the more likely will be the success of our proposal. However, we also conclude that we still miss a clear and easy mapping be- tween project management practices and standards with the EA artifacts and their life-cycle evolution to easy the completeness of change initiatives. For ex- ample, if a project intends to create and deploy a new application service on a given date on a given infrastructure, then these facts should be stated somehow in the project plan and deliverables, so that they can be subsequently imported to complete the Alive List and the Retired List of the corresponding change initiative. The Project Management Body of Knowledge[5] defines the work-breakdown structure as a ”A hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and cre- ate the required deliverable.” Since enterprise artifacts life-cycle is by defini- tion a result (deliverable) of a project, they are likely to appear in project work-breakdown structure. We are currently working in the establishment of a more formal mapping between enterprise artifact life-cycle and project work- breakdown structure[11]. The idea is to integrate Atlas with the project man- agement tools used in the enterprise and capture the information needed for Atlas: the Enterprise Cartography Tool 17 completion of change initiatives and make enterprise cartography a more simple and accessible capability to enterprises. Acknowledgements This research was supported by the Link Consultings project IT-Atlas (n 11419), under the IAPMEI, 2020 Portuguese PO CI Operational Program. References 1. Hoogervorst J. A. (2009) ”Enterprise governance and enterprise engineering”. Springer. 2. The Open Group. (2011). ”TOGAF Version 9.1”. (10th ed.). Zaltbommel, the Netherlands, Van Haren Publishing. 3. 1471-2000 - IEEE Recommended Practice for Architectural Description of Software- Intensive System. Replaced by ISO/IEC 42010. 4. Proper, H.A., Winter, R., Aier, S., de Kinderen, S. (Editors)(2017) ”Architectural Coordination of Enterprise Transformation”, Springer. 5. Project Management Institute (2017). ”A Guide to the Project Management Body of Knowledge” (PMBOK Guide)Sixth Edition Newtown Square, Pa, September 22. 6. Bischoff, S., (2017). ”The Need for a Use Perspective on Architectural Coordination” pp 87-98, in Proper, H.A., Winter, R., Aier, S., de Kinderen, S. (Editors)(2017) ”Architectural Coordination of Enterprise Transformation”, Springer. 7. Roth, S., Zec, M., Matthes, F., (2014): Enterprise Architecture Visualization Tool Survey 2014. Technical Report. Sebis, Technische Universit at Munchen. 8. Ugwu, K. (2017). ”Understanding the complementary relationship between enter- prise architecture and project management”. in Architecture and Governance Mag- azine (online version, accessed in May 2018). 9. Labusch, N., (2017). ”Information Requirements for Enterprise Transformation” pp 111-117, in Proper, H.A., Winter, R., Aier, S., de Kinderen, S. (Editors)(2017) ”Architectural Coordination of Enterprise Transformation”, Springer. 10. Schomburg, K., Barker, T. (2011). ”Integrating the IT PMO with enterprise archi- tecture for better government”. In proceedings of PMI Global Congress 2011North America, Dallas, TX. Newtown Square, PA: Project Management Institute. 11. Bernardo, M., Sousa, P., (2018) ”Portfolio Management. Enabling a dynamic Or- ganization IS representation”. 22nd International Congress on Project Management and Engineering (ICPME 2018), Madrid, Spain. 12. Sousa, P., Lima, J., Sampaio, A., Pereira, C., (2009). ”An Approach for Creating and Managing Enterprise Blueprints: A case for IT Blueprints”. The 21st Inter- national Conference on Advanced Information Systems, Lecture Notes in Business Information Processing, vol. 34, pp. 70–84, Springer-Verlag, The Netherlands . 13. Sampaio, A. (2010) An Approach for Creating and Managing Enterprise Blueprints. Master Thesis in University of Lisbon - fenix.tecnico.ulisboa.pt 14. Leal, R., (2010) Navigation model between Architectural Views: ”An approach for a new paradigm: Navigation in Enterprise Architecture”, Master Thesis in University of Lisbon - fenix.tecnico.ulisboa.pt 18 Pedro Sousa et al. 15. Sousa P., Gabriel R., Tadao G., Carvalho R., Sousa P.M., Sampaio A. (2011). ”En- terprise Transformation: The Serasa Experian Case.” In: Harmsen F., Grahlmann K., Proper E. (eds) Practice-Driven Research on Enterprise Transformation. PRET 2011. Lecture Notes in Business Information Processing, vol 89. Springer, Berlin. 16. Sousa P., Sampaio, A. Leal, R. (2014). ”A case for a Living Enterprise Architec- ture in a Private Bank”, In proceedings of the 8th Workshop on Transformation & Engineering of Enterprises (TEE 2014), July, Geneva. 17. Tribolet, J; Sousa, P.; and Caetano, A. (2014). The Role of Enterprise Governance and Cartography in Enterprise Engineering. Enterprise Modelling and Information Systems Architectures, 9 (1): 38-49. 18. Morris, C.W., (1938). ”Foundation of the Theory of Signs”, International Ency- clopedia of Unified Science, Vol. 1, No. 2. 19. Dietz, J. (2006). ”Enterprise Ontology - Theory and Methodology”, Springer. 20. The Open Group. (2015). ”ArchiMate 2.1 Specification”. Van Haren Publishing, Zaltbommel, www.vanharen.net. 21. IEEE. (2010). ”Systems and software engineering – Vocabulary”, in ISO/IEC/IEEE 24765:2010(E) , pp.1-418, Dec. 15 22. https://www.merriam-webster.com, accessed in September 2017. 23. Tratt, L. (2205) ”Model transformations and tool integration”, Software and Sys- tems Modeling, May 2005, Volume 4, Issue 2, pp 112122. 24. W3C (1999) XSL Transformations (XSLT). 25. Grosskopf, Decker and Weske (2009). ”The Process: Business Process Modeling using BPMN”. Meghan Kiffer Press. 26. Sousa, P., Rito, A., Alves Marques, J. (1995). ”Object Identifiers and Identity : A Naming Issue”, In IEEE Proceedings of the 4th International Workshop on Object Orientation in Operating Systems, Lund, Sweden. 27. Wachsmuth, G. (2007). Metamodel adaptation and model co-adaptation. In The European Conference on Object-Oriented Programming 2007 (ECOOP) (Vol. 4609, pp. 600624). 28. Cicchetti, A., Di Ruscio, D., Eramo, R., and Pierantonio, A. (2008). Automating co-evolution in modeldriven engineering, in Proceedings of the 12th IEEE Inter- national Enterprise Distributed Object Computing Conference, IEEE Computer Society, pp. 222231. 29. Silva, N., Ferreira, F., Sousa, P., Mira da Silva, M. (2016). ”Automating the Mi- gration of Enterprise Architecture Models”. In International Journal of Information System Modeling and Design (IJISMD) 7.2 pp 72-90. 30. Silva, N., Mira da Silva, M., Sousa, P., (2018). ”A Tool for Supporting the Co- Evolution of Enterprise Architecture Meta-models and Models”, In 27th Interna- tional Conference on Information Systems Development, August 22-14, Lund, Swe- den. 31. Silva, N., Sousa, P., Mira da Silva, M.(2018).”CO-EVOC: An Enterprise Archi- tecture Model Co-Evolution Operations Catalog”. In 24th Americas Conference on Information Systems, August 16-18, New Orleans, USA. 32. F.,Carolina, P. Sousa, A. Sampaio. (2016) ”Visualiazação da Evolução da Ar- quiteturas Empresariais”, 16 Conferênçia Associação Portuguesa de Sistemas de Informação (CAPSI), 22 September, Porto. 33. Xavier, A., Vasconcelos, A., Sousa, P. (2017) ”Rules for Validation of Models of Enterprise Architecture-Rules of Checking and Correction of Temporal Inconsisten- cies among Elements of the Enterprise Architecture”. International Conference on Enterprise Information Systems ,2, 337-344.