The need to maintain architectural representations of enterprises is an indescribable fact nowadays given their constant need evolve. However, despite the large number of Enterprise Architecture tools available, enterprises are unable to maintain architectural models updated, given the e ort it entails. Atlas is an Enterprise Architecture tool conceived to reduce the e ort needed to keep architectural models updated, in enterprises where changes are constant and design occurs in a decentralized, 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.
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,
architectural representations are an enterprise asset that must be governed[
We refer to enterprises and not to organizations since the rst term has
a wider scope according to the the Open Group de nition were "enterprise is
any set of organizations that have a common set of goals "[
We also consider a distinction between enterprise transformation and
evolution, the di erence being that the former is mostly related with top level
restructure and the later is related with the optimization of current state of
a airs[
Stefan[
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 e ort that such endeavor would entail. We believe that a signi cant part of such extra e ort results from the following organizational aspects: { Enterprise evolution uses multiple "Enterprise Architecture" tools. Enterprise evolution uses multiple tools for EA, being o ce 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 o ce document) a few weeks or months before the intended date. If the organization structure is modeled in some EA tool, e ort 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. Enterprise evolution is planned and designed by di erent units in an asynchronous and distributed process, involving many actors and many dimensions of concerns without formal mechanisms of communication between the di erent designers. For example, when a director decides to make changes in their department, 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 meetings, 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.
In such context, one can envisage the huge e ort required to update the models in the EA tools used. The fastest the enterprise changes, the more e ort 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 e ort 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 di erent points in time, namely: AS-WAS models. These models represent the enterprises past state of a airs, including 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 justi cations 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[
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 di culty 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[
So, the focus of our research has been in nding a low e ort 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 nding 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 nding 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 nding tell us that the focus should be target to TO-BE models. { Update EA views. Our nding is that hand-draw EA views will likely remain obsolete much longer than generated views. Hand-draw models requires placing 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 nding tell us to avoid hand-draw view and support only automatic generated views from gathered models (information).
Atlas2 was designed to explore the ndings presented above. It is an EA tool conceived to reduce the e ort 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 rst presented in[
Simply put, EC is the process of abstracting, collecting, structuring and representing architectural artifacts and their relations from the observation of enterprise 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 di erent actors that perceive di erent 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 de ned 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, di erent 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[
Ongoing change initiatives and their plans are an essential part of enterprise reality because they de ne the near future TO-BE of the enterprise if no further
decisions are taken that might have an impact on them. This is a fundamental concept that we call emerging AS-IS, which we de ne as the state of the enterprise 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, ongoing 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 concept 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 ows.
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 di erence is also evident in the de nitions of the
architect and cartographer roles. According to the IEEE Standard Glossary of
Software Engineering Terminology[
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[
This principle states that artifacts do not become productive or nonproductive randomly, but only as a result of change initiative. Since change initiatives are also enterprise artifacts (principle 1), an artifact becomes productive or non-productive only by the action of another productive artifact (the change initiative). Notice that the assumption that ongoing change initiatives 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.
Despite the fact that common EA notations (e.g.[
Notice that in this paper we only consider Alive as the only productive state. However, one can consider other productive states, such as for example 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 gestation 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 impact in the remaining artifacts. A removed artifact is unable to interact with alive enterprise artifacts. An artifact can move from conception directly to removal when it never materialized in a gestation, meaning that it never went beyond an idea.
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.
The emerging AS-IS state di ers from the AS-IS state by the artifacts planned to be brought into production/retirement by ongoing change initiatives. 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[
P (tm) = P (t0) [ N Y P (CItn ) n N LP (CItn )8t0 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 artifacts in plans of Change initiatives that produces results at time t.
Altas is a web based EA tool providing all functionality one could expect from such a tool. It allows the full con guration of the meta model, i.e. the classes and references types whose instances are used to express models of the organization. Users can also con gure in and out data both in format as well in contents for integration with other tools and systems.
Atlas supports custom con gured user interfaces. Given the wide scope of usage of EA tools within organizations, it will likely be used by employees without basic modeling concepts. So, besides allowing the con guration of elements in Atlas default interfaces (e.g, tabs in object edition properties), it allows users to con gure speci c forms, where users only see the desired properties, even if they are from di erent objects. Atlas also provides analytic elements such as charts, dashboards and EA views that we called blueprints.
Atlas also supports the con guration 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.
We now focus the description of how Atlas supports enterprise cartography. A typical scenario is presented in gure 2 where information from several sources, including o ce 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.
Model transformation occurs whenever data ows between sources with di erent
meta models, as is the case when Atlas gathers information from other sources,
and has been a relevant topic in software development and integration[
Consider the case where one wants to import a BPMN[
If several batchs are assigned to the same source or le extension, the user is requested to select one to upload the le. This is a very useful feature since within the same enterprise, di erent teams or departments may use the same notation di erently and di erent rules might be required.
Another rather important aspect is to be able to perform di erent 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.
In the scenario presented in gure 2 one needs to establish a mechanism to match objects existing in di erent sources that correspond to the same enterprise artifact. In other words, one needs an identi cation mechanism valid throughout the di erent sources to match imported objects against the ones that already exist in the Atlas repository.
The use of 128 bits Object Identi ers (OIDs, also known as UUIDs) ensures uniqueness for most practical purposes even when generated by di erent and independent tools. However, these system-generated OIDs are not useful in the scenario presented in gure 2, since the same enterprise artifact would have objects with a di erent OID in each source.
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 di erent enterprise artifacts, breaking the existing biding between OIDs and enterprise artifacts even in the context a single tool.
User de ned 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 de ned and normally
are not unique, since uniqueness is assured by OIDs. In Atlas, we took a di
erent approach where identi cation and denotation is established by user de ned
object names[
In practice this can be a strong restriction in large enterprises where one could expect to have several organizations with di erent 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 di erent hospitals. To support this scenario, users can de ne composite object names, by selecting object properties to be used for its identi cation, as primary keys in relational databases. In this case, the name of the object could be de ned 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 at object name space, full object names are unique URLs composed as follows: serverURL/RepositoryName/ClassName/ArtifactNameField N. ..
.ArtifactNameField 0.
The concatenation of the elds ArtifactNameField N to ArtifactNameField 0 must be unique within the objects of the same ClassName. All els but the last are optional (i.e can be null ), except the last one ( ArtifactNameField 0 ) that cannot be null.
In Atlas, object state is de ned as a set of properties values, whose types are user de ned. 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 de ne 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. However, object sate, as a collection of properties, can change structure over time 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 di erent 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 triggers 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 de ned in the meta model can be bound to a reference property, and the same class can be bounded to di erent reference properties.
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 a ect 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
complex 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
Address 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
object. A meta-model evolution primitive catalog, with primitives such as Flatten
Hierarchy, Merge Class, Split Class, Property to Class, Class to Property, among
others[
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 [
Object life-cycle is de ned over a set of object user de ned properties of type, one for each life-cycle state. Users can de ne several life-cycles for the same class.
For example, for the application artifact, one may de ne the existence life-cycle and technical quality life-cycle. For each life-cycle, users can de ne 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 speci c built-in behavior associated with the visualization of object life-cycles that requires uses to classify them as Not Yet Productive, Productive or No Longer Productive. Users de ne life-cycle states in order and some sates may be declared as Productive. The states prior to the rst Productive state are considered Not Yet Productive and states after the last Productive state are considered No longer Productive.
In atlas, EA graphical views are generated on-the- y 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 interact with them outside the Atlas tool in documents or in other web interfaces.
EA views are de ned in a simple XML language, where one can de ne containers that can hold others containers or a content query whose result set determines the objects that will be displayed inside that container. Containers can be set in a hierarchy and grow and shrink within user de ned 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 prede ned analyses, jump to another EA views and drag objects between containers, triggering containers out-query and in-query to do the necessary 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 gure 3, the time bar has two handlers, one on the left for the lower date and another in the right for the upper date.
By moving the time bar handlers back and forward one can see the architecture view in the selected time. The visualization can occur either in Absolute 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 lifecycle colors. For example, a typical life-cycle con guration 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 di erence of
life-cycle state of each object on the selected Times Ti and Tf [
In the next three gures (4 to 6) we present the same EA view with di erent options and dates of visualization. The rst gure 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 o , 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 gure 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 gure 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 gure 5, where the evolving objects are shaded in two
the past, present of future. halves: On the left side, with the color associated with the life-cycle state at the rst 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).
The time bar presented in these three gures show four markers, excluding the extremes, revealing the dates of change in that EA view. These dates correspond to object life-cycle evolution but can also be traced back to the change initiatives that have produced such evaluations, as explained next.
According to cartography principles, enterprise artifacts evolve in its life-cycle as a result of some planned change initiatives. In Atlas, used de ned class may be a change initiative class, and more than one change initiative class may exist. For example, one may de ne 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 results 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 lifecycle dates. For example, if a project, that is replacing one application by a new one delays one month, this delay should be re ected in the life-cycle of both applications, speci cally in the old application retirement date and in the new application alive date.
In Atlas this relationship is established by a user de ned 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 de ne 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 lifecycle according to the life-cycle of the corresponding change initiative. In this scenario is, the kicko 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. { 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
congured in state propagation rules associated to object life-cycle. This provides
more exibility and independence regarding to the actual life-cycle states the
user can de ne 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[
The goal we pursuit with Atlas and Enterprise Cartography is to be minimize the e ort required to provide updated and trustful EA views, in enterprises where their architecture is the result of many local architectures, each designed with di erent 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 e ort 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 between project management practices and standards with the EA artifacts and their life-cycle evolution to easy the completeness of change initiatives. For example, 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[
This research was supported by the Link Consultings project IT-Atlas (n 11419), under the IAPMEI, 2020 Portuguese PO CI Operational Program.