1

ARchiTool

Name

University

Date
2

Abstract

ArchiTool is a broad modeling language for enterprise architecture, including the

"service" structure for all enterprise layers. An earlier investigation into the usage of this

configuration inside ArchiTool's business layer discovered that it was impossible to map several

crucial social features connected to customer dynamics, and where a programming pattern

centered on ArchiTool's business layer. It resulted in suggestions for improving the form. This

analysis is expanded in this paper to incorporate service interactions seen between application

and technology levels. Understand how important it is to think about two contrasting viewpoints

on service modeling: a skill-based viewpoint and then a commitment-based standpoint. As a

result, a more comprehensive modeling strategy for ArchiTool's service relationships has been

proposed. This strategy can map business models that use the concept of services.
3

Introduction

A consistent description of the corporate architecture provides insights, enables

communication between stakeholders, and guides complex change processes. Unfortunately,

architects use their own modeling techniques and concepts, tool support, visualization

techniques, etc. for each architecture domain, so there is currently no corporate architecture

description language that enables fully integrated corporate modeling (Booch, Rumbaugh, &

Jacobson, 1999). In connection to the omnipresent concerns of business ICT alignment, the

language notion for articulating linkages among architecture and design representations at the

organization, application, but also technology levels plays a crucial role. This will use an existing

language or a standard such as UML for each (Henderson & Venkatraman, 1993). Architecture

domain. In particular, the use of services provided by one layer to another plays an important

role in associating aspects of layer behavior. The structural aspects of layers are linked by the

concept of interfaces, and the information aspects are linked by implementation relationships.

Enterprise architecture plays an important role in today's enterprise management.

Enterprises recognize that after early voluntary growth and years of accumulation of various

legacy systems, they need to create the organisms that make up some controlled enterprise to be

manageable increase. Enterprise architecture is one of the tools that can help you do this.

ArchiMate defines a layered structure that allows you to organize the elements of your

company. The lower tier supports the upper layers by providing services (OASIS, 2006).

Business layers, people, including organizations that deliver/terminate products/services are all

dealt with under this layer. The application layer provides services and applications to the
4

business layer, which are executed by software programs. The technology layer provides

facilities such as storage as well as messaging services that are executed by hardware and

software including wireless networks and database management systems (Josey, 2016).

There is a linkage between TOGAF standard and Archimate modeling language.

Archimate is a powerful tool to visualize TOGAF (Josey, 2016). It can be used to create visual

models of Business architecture, Applications, and Data architecture, and Technology

architecture. Another feature of Archimate is its applicability to model architecture in dynamic

(OASIS, 2006). TOGAF is iterative and shows how the company evolves. Archimate includes

elements to model it.

Figure 1: Baseline Structure of the ArchiTool

A concept is either an element or a relationship. This can be the logical connector of the

relationship. There are four types of elements: behavior, structure, motivation, and composition.

These types are defined by various aspects (Morabito, Sack, & Bhate, 1999). The active
5

structural aspect represents a structural element and represents the actual behavior in the system

(Henderson & Venkatraman, 1993). The behavioral aspect represents the behavior of the actor.

Structural elements are assigned action elements to indicate who or what is doing the action. The

side of the passive structure represents the object on which the action is performed. A compound

element is an element that consists of other elements from multiple aspects or layers of the

language.

In within application, every layer of the layered architectural framework has a distinct

purpose as well as duty. A presentation layer, for example, would have been in charge of all web

applications including browser interaction logic, while a business layer would have been in

charge of implementing particular business regulations that apply to the query (Henderson &

Venkatraman, 1993). Thus every layer of the structure creates an approximation of the effort

required to fulfill a certain business requirement. The presentation layer, as for instance, does not

have to notice or care how to collect consumer data; all it had to do is show it on a screen in a

specific way. The layered framework is a decent general-purpose design, so it's a nice way to

start for most projects, especially unless you are not sure which architectural pattern is right for

you. Nevertheless, there seem to be a few architectural considerations to keep in mind while

picking this style.

6

Figure 2: ArchiTool's Layer aspects

The business layer depicts the customer-facing management services that are provided in

the firm via enterprise applications carried out by business actors. The application layer connects

your business's application services with the apps that use them. The processors, memory, and

internet services necessary to operate an application, and even the networking and

telecommunication system applications which perform these functions, are represented by the

technology layer. To represent tangible devices, components, including distribution networks,

mechanical elements can be added to this layer. This aspect is represented by the TOGAF

extended model shown in Figure 3.

7

Figure 3: full framework of Archimate

Above the business layer, there are several strategic elements. In the following, we have

implemented and migrated several elements to model the development of the company. You can

see that there is another aspect to consider: motivation. These motivational aspects correspond to

the "Reason" column of the Zachman Framework. The motivational element is the element that

provides the context or rationale for a company's architecture. The language contains several

motivational factors such as stakeholders, values, meanings, impetus, assessments, goals, results,

principles, and requirements.

The business layer is typically used to model a company's business architecture as

defined by the TOGAF framework (Josey, 2016). This is a description of the structure and

interaction between business strategies, organizations, functions, business processes, and

8

information needs (Weinhardt, Blau, & Stober, 2009). In the picture, you can see how different

types of objects are connected. The active structural aspect of the business layer is the static

structure of an organization in terms of the units that make up the organization and its

relationships. They include business roles, business actors, and business collaboration.

Behavioral elements are business processes, business functions, or business interactions (Josey,

2016). The passive structural aspects of the business layer contain passive structural elements

that are manipulated by actions, such as business processes and functions, as shown in Figure 6.

The application layer is typically used to model an enterprise information system

architecture, including the application architecture defined in the TOGAF framework

(Weinhardt, Blau, & Stober, 2009). Describes the structure and interaction of the application.

The most important active structural element of the application layer is the application

component. Implement IT services to support your business processes (Figure 7). The

technology layer is typically used to model a company's technology architecture. The most

important active structural element of the technology layer is the node. It is a structural unit. This

is either device software or system software, an infrastructure software component that runs on

the device. The connections between the components of the technology layer are primarily

formed by the communications infrastructure. Use the path element for this (Figure 8).

Archi supports all the elements of Archimate and can create different perspectives. There

is a hint view that allows you to analyze each element type. There are also additional tools such

as B. Canvas modeling. You can use this tool to create, for example, the Ostervalder business

model. This tool allows you to create a large number of views within a model or between

different models. It contains all the elements of the latest version of the Archimate language and
9

evolves with it (Weinhardt, Blau, & Stober, 2009). When creating a model, all elements are

sorted by type, making it easier to navigate.

Figure 4: Models & Views

The tool also includes a number of connectors to make your model more comprehensive. You

can make the correct connection with the "magic" connector.

10

Figure 5: Elements and connectors in Archi

The software analyzes the type of element and its layer and recommends the correct arrow. Once

your model is complete, you can export it to a variety of file formats, as shown in the figure

below.
11
12

Literature Review

In today's corporate world, an integrated way of operating and technology is essential.

Nevertheless, in many businesses, an integrated perspective of the entire organization is still a

long way off. This is a critical issue since changes in a firm's strategy and business goals affect

all aspects of the firm, including the organization structure, business operations, enterprise

applications, data management, and technological infrastructure (Booch, Rumbaugh, &

Jacobson, 1999). Businesses must adapt procedures to their surroundings, open up existing

networks, and render them accessible to various stakeholder groups. Consider a firm that needs

to determine the impact of releasing a new product into the market (Arkin, 2002). The above

may need the creation of new company operations, the hiring of more staff, the modification of

organizations today, and the expansion of technological resources to handle the increased load of

these implementations (Booch, Rumbaugh, & Jacobson, 1999). This may need a change in

organizational structure. Many stakeholders may be discovered both inside and outside the

organization, ranging from higher leadership to software developers. To respond to the effect of

such wide-ranging trends, each stakeholder requires particular data provided in an

understandable manner (Arkin, 2002). It is quite difficult to get a clear picture of these changes

and how they interact and to give both decision-makers and programmers useful information.

The importance of both "soft" and "hard" components of an organization has been

highlighted in a plethora of literature on the subject of business alignment. Work, individuals, the

legal order, as well as informal organization are the four key alignment elements identified by

Nadler (1992). They emphasize an organization's transverse and longitudinal synchronization

features. The relationship between the popular approaches as well as the low-paid workers is

described as vertical alignment, whilst the relationship among environment and internal
13

consumers is described as horizontal alignment. distinguished both organizational strategy as

well as infrastructure, while on the other side, ICT approach as well as infrastructural facilities.

Business and information technology are both subject to alignment. Morabito (1999) divides

alignment into three stages: continuous alignment, appropriate alignment, and dynamical

alignment. Both of these are strongly tied to the alignment approach's necessary flexibility.

Difficulties with alignment have an impact on the entire organization and evolve. As employees

execute, understand, and modify their alignment to their process duties, the alignment would

have to be flexible promptly. On the other side, consistency, as well as suitability, are more

closely tied to structural alignment difficulties. The choice of the most appropriate parts of the

system as well as coordination between such elements is associated with consistency of

alignment. Compatibility refers to the identification of requirements that are compatible among

various components. Do design concepts from different components, for example, clash or not?

The realm of strategy alignment is, without a doubt, as varied as it is difficult. When addressing

business alignment difficulties, one must first grasp the organization's complexity, which is a

difficult endeavor in and of itself.

It is indeed crucial to remember that the categorization of concepts focuses on theoretical

domains or features and layers is just a broad one. It is difficult, and inappropriate, to draw a

clear line between features as well as layers since concepts that connect the many aspects and

levels play a crucial role in a cohesive architectural representation. Services as well as roles, for

instance, act as transitional notions between "solely functional" and "purely technical"

conceptions, a step ahead of both the later conceptual talks. Many other notions encompass

numerous layers and elements.

14

Using the connections described in the preceding section as a guide, it can be seen that

the architectural layers (enterprise, applications, and infrastructure) form a hierarchy inside an

organization. Starting with the business functions done is a popular approach to looking at a

company. These would be carried out by an organization's actor or role, maybe with the help of

one or more business applications, or perhaps even totally computerized. Such activities, on the

other hand, might be considered as services towards this business process, providing a distinct

added value to it. A bottom-up technique can also be used, during which business operations are

just a vehicle for delivering and financially exploiting reduced activities with the outside world.

One of the most precious things, in this perspective, is the capacity to conduct lower-level

operations, with operations serving as a mechanism of manipulation. When you use a service-

oriented approach, you get a ‘service hierarchy. This is quite identical to the ISO-OSI model's

layered model (ISO, 1984). Outbound services can be provided towards the next higher tier

according to each layer. The upper layer's types of services may rely on functions from the same

architecture layer or even a layer above. External application services, for instance, may be

required for organizational services. Internal services are utilized within the same

interconnection point; for example, one example application may access services provided by

another. Similarly, a business transaction may be thought of as a collection of subprocesses that

provide services to each other as well as the enclosing process. External work services are also

known as 'customer relations,' as they are provided to the company's current (external) clients.

The resultant integrated models can be used to solve "operational" challenges related to

the never-ending problem of business-ICT alignment. Having access to such linked models

brings up a world of possibilities, including influence evaluation and automated visualization.

These applications need sophisticated selection, visualization, and data interpretation in addition
15

to modeling and analysis. This is particularly true for realistic models, which may be rather large

and intricate. A great deal of study has gone into developing such procedures, which we will put

to good use. Nevertheless, the usefulness of these strategies to solve the alignment issue is

conditional.

Visualizations of Models of three models

Business Layer Model

Figure 6: business-layer model

At the business level, it is common to link actors and actions more flexibly by

introducing an intermediate concept of business roles. The idea is that the work an actor does

within an organization is always based on the specific role that the actor plays. There are at least

two reasons. First, roles are better suited than actors to explain the structure of an organization,

because roles within an organization can be expected to be much more stable than the specific

actors who play those roles. Second, multiple actors can play the same role, and conversely, a
16

single actor can play multiple roles. This allows you to see if an actor's assignment to a role

meets the desired characteristics. The architectural description focuses on structure. In other

words, the relationships between the entities in your organization play an important role. To

clarify this, the concept of business collaboration was introduced.

A partnership is a group of jobs within an organization that works together to achieve a

common goal. Partnerships as specified in the UML (U2 Partners, 2002) have encouraged

organizational partnerships, albeit UML partnerships relate to elements in the application layer.

Our corporate cooperation notion also bears a striking resemblance to the RM-ODP Organization

Language's 'network' approach (Tyndale-Biscoe, 2002) and the AMBER language's 'interactive

point' model (Eertink et al., 1999). The services idea, as mentioned in Section 7.2, plays a crucial

role in connecting models in the application's many tiers.

Given this ‘service-oriented approach, having the ability to explicitly describe the

organizational interface, i.e., the (physical and logical) places where the functions that a role

provides to the environment may be accessed, is beneficial. The same service may be provided

via a variety of interfaces, such as mail, telephone, or the Website. In opposed to application

modeling, existing business layer modeling techniques seldom recognize the idea of a business

interface. The 'channel' idea, as described in, for example, the NEML language looks a lot like a

business interface.
17

Application Layer Model

Figure 7: Application Layer Model

Every application component is the most important structural idea in the application

layer. This notion is used to describe any architectural item at the application layer, including

whole application software, sub-applications, and data management, as well as (recyclable)

application software that may have been utilized in one or maybe more applications. The UML

component is fairly close to this notion. Component interconnections are always an important

aspect of software architecture. As a result, we also propose the notion of application

cooperation, which is characterized as a group of application components that work together to

accomplish application engagements.

Partnership, as specified in the UML 2.0 recommendations, is quite close to this idea (U2

Partners, 2002). An application is indeed the (logical) point where such a function's services may

be obtained in a completely structural manner. An application contains some behavioral features

in a larger sense (as used, for example, within UML definition): it describes the set of activities

and events offered by the component, as well as those that are necessary from the context. As a
18

result, it's utilized to define a component's capabilities. A difference between a supplied and a

needed interface can be created.

Technology Layer Model

The network is the application layer's core structural idea. Inside the technology layer,

this idea would be used to model structural elements. This is the same as UML 2.0's node notion.

It tightly represents the structural component of an application, with a precise link to the

behavioral notions modeling its behavior. The environment connection is the (logical) place in

which other networks or software modules from the application level can engage a node's

infrastructure functions. Computer network software components are both borrowed from UML

2.0 (both of these are termed implementation environments in UML).

A device is a virtual system that represents a computational resource that may be used to

run artifacts. System software refers to the software infrastructure in which specified sorts of

components and types of information are delivered as artifacts. A node is typically made up of a

series of subnodes, including a server as well as a programming environment that models the
19

computer system. Communication infrastructure is primarily responsible for the interconnections

of components in the technology layer. The communication channel is the relationship among

multiple nodes that allows them to exchange data. A communication route's physical realization

is a model.

Conclusion

We have established a vocabulary for defining integrated corporate architectures in this

article. Because there is currently no architectural language for expressing the architecture of a

business as a whole, this approach tries to bring the numerous distinct architectural specifications

for various architectural areas closely around each other. It is not recommended to build a whole

new language since different languages and their accompanying methodologies are strongly

ingrained in organizations. As a result, our new language aspires to incorporate and expand on

popular and widely used languages like UML. Practical scenarios, in which the principles were

effectively implemented in real-life circumstances, have been used to validate and refine the

language. In this work, we specifically consider the following points.

Initially, at which level of precision must objects be conveyed, and, more broadly, how

does the incorporated language relate to existing comprehensive languages? This language's

notions for enterprise architecture characterization fall somewhere in the center of

comprehensive concepts for modeling individual areas, such as the UML for software modeling,

and highly broad architectural concepts that regard systems just as elements and their inter-

relationships. The language serves as a foundation for bridging the gaps between current

languages. This company's current effort aims to provide a tool interaction environment in which
20

models from multiple tools may be integrated. This encourages possible reuse in a way that the

original creator will recognize.

Second, what domains there in language must be recognised? The business, operational,

and technological levels of a company are now covered by concepts in the language.

Furthermore, we separate the data, behavior, and structure components for each layer. This

contains the data, product, process, organization, information, applications, and technological

infrastructure domains.

Finally, which ideas will be included in the language for every domain? Conceptual and

relationships for modeling the information, behavior, and architecture aspects are established for

each layer. The conceptual concepts of corporate entities as well as objects, roles, as well as

partnering, the behavioural concepts of overall organizational service, operational processes,

operations, and interconnections and activities, and the information processing concepts of

portrayal, intention, and meaning are all distinguished at the business layer. The architectural

notions of application interface, cooperation, functionality, including data object, as well as the

behavioral ideas of service portal, function, including engagement, are distinguished at the

application layer.

At the technology level, we distinguish between nodes, devices, execution environments,

infrastructure interfaces, communication path and network structural concepts, infrastructure

service behavioral concepts, and artifact information concepts. Fourth, how are relationships

between domains described? The use of services provided by one layer to another plays an

important role in associating aspects of layer behavior. The structural aspects of layers are

linked by the concept of interfaces, and the information aspects are linked by implementation
21

relationships. Looking at the metamodels of the different layers, we can see that they have a lot

in common.

They use a similar concept to model three aspects of the framework. This is done at

various levels of detail. It makes sense to recognize this common foundation of layer-specific

metamodels. This simplifies the formalization of metamodels and allows you to develop the

same or similar analysis and visualization techniques for both layers. Using a simple example,

we have shown that our concept can provide a coherent description of all aspects and levels of

the company.

An integrated model like this has been demonstrated to be quite beneficial in producing

insights, improving information flow, and measure the effect of significant changes. However,

even this simplified example demonstrates the necessity to handle the integration model's

complexity. To get the most out of your model, create a view that picks and visualizes key

aspects from these models for a certain stakeholder.

Future work

Finally, from this work, future research topics include the following. (I) Application of

the proposed solution in the representation of the actual scenario of the cloud service model.

Evaluate these and investigate the details of these scenarios. In a market-based vision, how to

make different levels of resources / talents available through services. (ii) Clarify the semantics

of product elements like ArchiMate's "service bundles" (this also necessitates clarifying the

semantics of aggregation and configuration relationships between products and services), and

(iii) additional languages. We will also suggest adjustments to the ArchiMate met model as a

logical continuation of our work to integrate the modeling characteristics outlined in this study.
22

We expect that the business modeling techniques and standards presented here will lead to more

ArchiMate business modeling concepts for cloud deployment models.

23

References

Arkin, A., Business Process Modeling Language, BPMI.org, 2002.

http://www.bpmi.org/bpmi-downloads/BPML1.0.zip

Booch, G., J. Rumbaugh and I. Jacobson, The Unified Modeling Language User Guide,

Addison-Wesley, 1999.

Eertink, H., W. Janssen, P. Oude Luttighuis, W. Teeuw and C. Vissers, A Business

Process Design Language, in Proc. of the 1st World Congress on Formal Methods, Toulouse,

France, Sept. 1999.

Henderson, J.C., and Venkatraman, N., Strategic Alignment: Leveraging Information

Technology for Transforming Organizations, IBM Systems Journal, 32 (1),1993

ISO. Basic Reference Model for Open Systems Interconnection, ISO 7498. International

Organisation for Standardisation, 1984

Nadler, D.A.,Gerstein, M.S., Shaw, R.B. and Associates, Organizational Architecture:

Designs for Changing Organizations. San Francisco. Jossey-Bass Publishers, 1992.

Morabito, J., Sack, I. and Bhate, A., Organizational modelling, Prentice Hall PTR, 1999.

Steen, M.W.A., M.M. Lankhorst and R.G. van de Wetering (2002), Modelling Networked

Enterprises, in Proc. Sixth International Enterprise Distributed Object Computing

Conference (EDOC'02), Lausanne, Switzerland, Sept. 2002, pp. 109-119.

24

Lankhorst, M. M., Proper, H. A., & Jonkers, H. The anatomy of the ArchiMate language.

International Journal of Information System Modeling and Design (IJISMD), 2002, 1(1),

1-32. 2.

Josey, A. TOGAF® Version 9.1-A Pocket Guide. Van Haren. 3. ArchiMate® 3.0.1 Specification

(2012-2017). http://pubs.opengroup.org/architecture/archimate3-doc/ 4.

Jonkers, H., Lankhorst, M. M., ter Doest, H. W., Arbab, F., Bosma, H., & Wieringa, R. J.

Enterprise architecture: Management tool and blueprint for the organisation. Information

systems frontiers, (2006 8(2), 63-66.

OASIS. (2006). “Reference Model for Service Oriented Architecture 1.0: OASIS Standard.”

OASIS, pp. 1–31.

Weinhardt, B. Blau, and J. Stober. “Cloud Computing - A Classification, Business Models, and

Research Directions,” Bus. Inf. Syst. Eng., vol. 5, (2009). pp. 391–399.