Models are used in software engineering, enterprise architecture, requirements engineering, etc. In this context, models can give support in creating a shared understanding of what exists in an enterprise. For this purpose we suggest to use a cartography tool that stores and displays the variety of models. But cartography tools have limitations in the number of enterprise levels shown. Since every model has to conform to a unique meta-model, in this paper we report on a development of a SEAM meta-model used within the Solu-QIQ cartography tool to overcome the limitations of the default cartography meta-models.
Enterprise architecture (EA) is de ned as \a coherent whole of principles,
methods, and models that are used in the design and realization of an enterprise's
organizational structure, business processes, information systems, and
infrastructure" [
Having a cartography in an enterprise is important because it helps enterprise
architects, managers, governance bodies and all employees in general, to create
a shared understanding of what exists within and around the enterprise. With
this, decisions that optimize the usage of Information Technology (IT) resources
are made more easily. In the literature, an information system cartography is
also known as a top-down urbanization approach (IS Urbanization and
Enterprise Architecture, URBA-EA) [
fast way of EA modeling without losing the models correctness can be seen as cartography tool. We decouple the tool from the approach implemented in the tool. As a consequence, in Section 2, we give an overview of few EA tools and
and approaches according to features we nd important.
Iteraplan [
B Yes Partial Yes C Yes No Yes
the business down to IT, using the same notation. Also, the declarative way of modeling is an advantage when focusing on macro scenario descriptions. Solu
TOGAF [
II 4 4 4 User de ned III No No No Yes
IV No No Depends on the level Yes
business/IT alignment, and requirements engineering [
SEAM represents an organization as a hierarchy of service systems (from
business down to IT, also known as organizational level hierarchy). To clarify, we
use system to refer to any kind of entity in our surrounding: an organization,
an employee, an IT system, or an application [
as [w] (black boxes) or as a composite, denoted as [c] (white boxes). By modeling a system as a whole, we ignore the system's components and we focus only on the services o ered by the system. When we model a system as a composite, the components and their relationships are visible, so we see the implementation of the service and understand the responsibility of each component. In this case, the system seen as a composite is the parent in the organizational level hierarchy and the component systems are placed within the boundary of their parent. Essentially, there are no rules on the number of levels in the hierarchy.
Besides the organizational level hierarchy, we can specify the behavior
(functionality) of each system. There are two kinds of functionalities [
represents a service o ered by a system.
When we have both of the views (as a whole and as a composite) for the same system in one diagram, we can observe two types of connections (links), depicted in Fig. 1(c): { The two views are connected with a re nement (decomposition) link. Essentially, this link shows that it is the same system. The process in the system as a whole corresponds to the implementation of the service in the system as a composite. { In the system as a composite, the process is connected with plain links to other services that belong to the component systems as a whole. These links mean that the process invokes (uses) those services.
service system in a SEAM diagram. There exist other pictograms that specify the nature (type) of the service system (see Fig. 1(a)). The name of the system is written on the top of the pictogram, followed by a small letter in square brackets [w] or [c], denoting if it is a system as a whole or a composite respectively. Also, the pictograms used for a service and a process are depicted in Fig. 1(b).
In a service oriented environment, there is no de nite number of layers between the application layer and the layer where the nal end user participates in/consumes the service. In Fig. 2 we show four organizational levels in a SEAM model. In this example model there is an application in the third (Application 22 ), and in the fourth level (Application 31 ). We are not showing details of the application and infrastructure layers. They can be seen after we model its composite views, but for simplicity we don't show them here.
we will fail. The application layer is usually xed in one level, and we model a situation where we need an application layer in two di erent levels. Adding an extra application layer can solve the problem, but it also adds complexity and decreases scalability of the overall solution.
which is a great advantage. But this advantage makes it di cult to nd a metamodel that every SEAM model will follow. Finding this meta-model enables modelers to create SEAM models that capture more situations in a fast way by using the Solu-QIQ tool.
The already developed meta-models, which capture all methods which are
part of SEAM [
(Service System { Process and Service System { Service). By these two links we have partly captured the system decomposition link, and the whole and composite concepts. Let's say we have a service system sysX, that o ers the service serX (when sysX is seen as a whole), and a process procX that implements the serX, which is in sysX, when the system is seen as a composite.
its view as a whole. The same holds for a system connected with a process and a system's view as a composite. This decomposition scenario will be complete only when we know that procX implements serX. This is done by the connection between Service and Process in the meta-model.
Finally, we have a many-to-many relationship between a Process and a Service. The reason for this is the invoke (use) link. The Service ! Process (decomposition) link stands for \the service implemented by a process", and the Process ! Service (invoke) link stands for \the process uses a service". The cardinality of processes and services is di erent. On the process side it is 0..* because there can be services for which we don't know the implementation. For the services it is 1..* because there can not be a process that doesn't use a service. Also, once we have a process, we have the corresponding service. The distinction between these two types of links is stored as a ag in this many-to-many relationship.
of the SystemType. This SystemType is a typology that is used to distinguish what kind of system we want to show (see Fig. 1(a)). With this we implement the solution of having recursive layers. By giving the value Application to the system's type, we will know that that system is an application and belongs to the corresponding Application layer in URBA.
We tested the proposed meta-model by implementing it in Solu-QIQ. It is not intuitive that this meta-model is capable of showing in nite number of organizational hierarchy levels. For this purpose, we populated the meta-model in the tool with data that correspond to the SEAM model seen in Fig. 2. It is not enough just to insert data. It is up to us how do we interpret the meta-model and the data present. This is done by creating a query in Solu-QIQ that outputs enough data to show one organizational hierarchy level as a SEAM model. The nal Solu-QIQ output is depicted in Fig. 4 and it is obtained after de ning a style in the tool for the output of the query. We have to note that the output shows only one level at a time, and in this gure four separate outputs are shown.
the meta-model we provided. So in future, instead of drawing SEAM models, system by system, action by action, we can only populate the Solu-QIQ tool with the needed data, click on a button, and we will have the model ready.
of the approach through creating a mutually compliant meta-model. This tool is further on used for generating EA models. The overall goal is to have models of the EA that enables the IT to give better support to the enterprise's IT strategy. This is tightly connected with the de nition and implementation of an
with our chosen EA approach, SEAM, and an EA tool, called Solu-QIQ. This tool is inspired by the urbanization approach.
First, we explained why SEAM and a cartography tool such as Solu-QIQ are needed in an enterprise, and why it is important for them to coexist. Then, we gave a simple meta-model that captures the basic SEAM principles. We nish with the implementation of this meta-model in Solu-QIQ and show the output of a generated model. By doing all this, we showed the recursive side of SEAM and we display the e ciency of Solu-QIQ when dealing with recursive meta-models.
bility. SEAM is much more powerful than showing services, processes, service systems as a whole and as a composite. In order to bene t from the complete