Archi Tool
Archi Tool
Archi Tool
ARchiTool
Name
University
Date
2
Abstract
"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
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
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.
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).
Archimate is a powerful tool to visualize TOGAF (Josey, 2016). It can be used to create visual
(OASIS, 2006). TOGAF is iterative and shows how the company evolves. Archimate includes
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
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
mechanical elements can be added to this layer. This aspect is represented by the TOGAF
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,
defined by the TOGAF framework (Josey, 2016). This is a description of the structure and
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.
(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
The tool also includes a number of connectors to make your model more comprehensive. You
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
References
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.
Process Design Language, in Proc. of the 1st World Congress on Formal Methods, Toulouse,
ISO. Basic Reference Model for Open Systems Interconnection, ISO 7498. International
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
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
OASIS. (2006). “Reference Model for Service Oriented Architecture 1.0: OASIS Standard.”
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.