Keywords

1 Introduction

Generally, context is any information that can be used to characterize a situation of an object. The object is a person, IT product or plan that are considered relevant to the interaction between users. Context has a significant impact on the way humans or machines act, on how they interpret things, and on how they combine their experience together to give it meaning. Generally, the perceived objects remain unchanged, but the perception of them and the relations among them are different. Taking into account the general properties of context, it should be noticed that context is always infinite. The context specification and description details depend on the purpose of why it is done, by whom and for whom. Every entity involved in the context formalization process introduces new backgrounds and perspectives. Context is always dynamic, because the real world is changing beyond the formalization. Context is also considered as a set of constraints that influence the behaviour of an object involved in a given task. An information system is adequate to its context, if the exchanged information is compatible in itself and if the resources required for information processing are available. For computerized application, context is typically the location, identity and state of people, computational and physical objects [1].

In this paper, the category of context information captures the relations an entity has established to other entities, e.g., information systems. Such surrounding entities can be persons, things, devices, services or information. The network of all relations and the structure of the related entities construct a context for a particular entity in this network. The structure of relations is changing dynamically, but essentially determines an entity’s context. In this paper, context obtains a specific role in communication of entities combined in the network. So, the context is a framework for the EA organizational analysis. Therefore, the EA context is interpreted as a network of stakeholders, a network of principles, and as a network of information systems surrounding the modelled enterprise.

In the paper, the deduction method of thinking is posited, so in the first part of the paper context is defined and widely discussed, its different interpretation are visualized with the mind mapping tool usage. Next, in the second part, the short case study is presented, where a certain types of context are considered and visualized in ArchiMate language.

2 Different Interpretations of Context

Business decision making states the importance of knowledge acquisition in a context. Decision making can be planned as a context awareness system, where tasks and situations are determined by the social environment of the decision maker. It is contrasted with the academic deliberations, where knowledge is out of context, i.e., abstract, de-contextualized.

ISO/IEC 25063 standard provides the Common Industry Format for documenting the context of use for information systems. So, the description of the context of use includes information about the users and all other stakeholders, the characteristics of each user group, the users’ goals, their tasks and the environment, in which the system is used. According to the standard, the context description is applicable to software and hardware systems, products or services. It provides a collection of data relevant for analysis, specification, design and evaluation of an interactive system from the perspective of various user groups [2].

Context can be used to decrease impact or enhance existing business measures. Context information is useful for business decision making, so for example:

  • Information about the current state: the user’s current location, time, activity, people nearby, physiological state, available services, network connectivity.

  • User preferences and relationships, including recommendations from people. This type of context information is interesting as it involves personal and social information in making business decisions.

  • Accumulated experiences and knowledge, therefore, historical information is used in relation to trust based on previous outcomes.

Beyond that, context can be identified with colours, size, distance, relation details, design, form or background. There is no single definition of context, no single application and no single method. Context enables to know, understand, see and act. For example, mobile phones represent people and their acting. Primary context covers location, activity, time, identity, weather, friend, email address, and phone number. Therefore, computerized systems are able to recognize users and send information to remind about somebody or something, on weather, on social events. Capturing data by sensors and mobile devices can be used for creating context based activities, for monitoring and forecasting the human behaviour [3].

3 Context Considerations in EA Frameworks

There are many frameworks that support the EA modelling and development, however, the context issues are really emphasized in the EA Framework provided by Zachman [4]. The Zachman Framework (ZF) analyses the basic structure for organizing business architecture through dimensions such as data, function, network, people, time and motivation. Zachman describes the ontology for the creation of EA through negotiations among several actors. The ZF presents various views and aspects of the enterprise architecture in a highly structured and clear-cut form. It differentiates between the following levels: Scope (i.e., contextual, planner view), Enterprise Model (i.e., conceptual, owner view), System Model (i.e., logical, designer view), Technology Model (i.e., physical, builder model), Detailed Representation (i.e., out-of-context, subcontractor), and Functioning Enterprise (i.e., user view). In the ZF, the EA context is expressed as the six aspects of the enterprise architecture. The ZF works with the following aspects: Data (what?), Function (how?), Network (where?), People (who?), Time (when?), Motivation (why?). Each aspect interrogates the architecture from a particular perspective. Taken together, all the aspects and some views create a complete picture of the enterprise. In the ZF, the first viewpoint is the planner’s view. There are the architect’s first sketches and drawings that base on the owner’s requirements and the description of an idea what the product, i.e., EA, would look like. On that level, these descriptions would list things important to the enterprise, processes performed by the business, locations where the business operates, organizations important to the business, events significant to the business and the business goals and strategies of the enterprise. They define the scope and boundaries for the enterprise. The plans in the first four viewpoints from the planner’s view to builder’s view are in context as they describe the product in entity. However, the plans at the component (i.e., Detailed Representation level) are out-of-context as they concern only parts of the total structure. This distinction is significant, because being out-of-context make these components highly reusable; if they are highly standardized, they can be used in many contexts.

Since 1999 the Federal Enterprise Architecture Framework (FEAF) has promoted shared development of business processes and interoperability as well as the sharing of information among US federal agencies and other governmental entities [5]. The FEAF components of an enterprise architecture cover architecture drivers, strategic direction, current architecture, target architectures, transitional processes, architectural components, architectural models, and standards. The architect is responsible for ensuring the completeness of the architecture, in terms of adequately addressing all the concerns of all various views, satisfactory reconciling the conflicts among different stakeholders. The framework emphasizes the role and the view of planner, owner, designer, builder and subcontractor in the EA development process. Therefore, the FEA (Federal Enterprise Architecture) is an attempt to unite some views and functions under a single, common and ubiquitous architecture. Each view is considered as providing a separate context. The FEAF is derived from the Zachman Framework, however, the user of realized architecture is not included in the development team. Planning of enterprise architecture according to the ZF meets some unclear situations (e.g., answer When? is difficult), therefore the FEAF seems to be the simplified and more intense version of the ZF.

The other frameworks of enterprise architecture, although focused on the architectural components development, also include questions concerning the EA views and viewpoints. The Ministry of Defence Architectural Framework (MODAF) is the UK Government specification for architectural frameworks for the defence industry [6]. The MODAF covers seven viewpoints. The All View viewpoint is created to define the generic, high-level information that applies to all the other viewpoints. The Acquisition viewpoint is used to identify programmes and projects that are relevant to the framework and that will be executed to deliver the capabilities that have been identified in the strategy views. The Strategic viewpoint defines views that support the analysis and the optimization of military capability. The intention is to capture long-term missions, goals and visions, and to define what capabilities are required to realize them. The Operational viewpoint contains views that describe the operational elements required to meet the capabilities defined in the Strategic view. This is achieved by considering a number of high-level scenarios, and then defining what sort of elements exist in these scenarios. The Operational views are solution-independent and do not describe an actual solution. These views are used primarily as part of tendering, where they will be made available to supplier organizations and form the basis of evaluating the System views that are provided as the supplier’s proposed solution. The System viewpoint contains views that relate directly to the solution that is being offered to meet the required capabilities that have been identified in the Strategic views and expanded upon in the Operational views. There is a strong relationship between the System viewpoint and the Operational viewpoint. The System views describe the actual systems, their interconnections and their use. This will also include performance characteristics and may even specify protocols that must be used for particular communications. The Service-oriented viewpoint contains a view that allows the solution to be described in terms of its services. The Technical viewpoint contains two views that allow all the relevant standards to be defined. This is split into two categories: current standards and predicted future standards [6].

The CIMOSA framework is based on four abstract views (i.e., function, information, resource and organization views) and three modelling levels (i.e., requirement definition, design specification and implementation description) [7]. The four modelling views are provided to manage the integrated enterprise model (i.e., design, manipulation, and access). The role of each view is to filter components out of the model according to given perspective. For the management of views, CIMOSA assumes a hierarchy of business units that are grouped into divisions and plants.

According to The Open Group Architecture Framework (TOGAF), an overall Enterprise Architecture consists of the four subsets, i.e., business, technology, data and application architecture. Beyond that TOGAF includes the following views: Function, Management, Security, Builder’s, Data Management, User (and the following physical views), Computing and Communications [8]. In that context, the Architecture Development Method (ADM) is regarded as describing a process life cycle that operates at multiple levels within an organization, operating within a holistic governance framework and producing aligned outputs that reside in an Architecture Repository (AR). Beyond that in TOGAF the Enterprise Continuum provides a valuable context for understanding architectural models. It shows building blocks and their relationships to each other and the constraints and requirements on a cycle of architecture development. In the EA development process, the viewpoints and views ensure a fragmentation and partial specification, however, this approach seems to be useful because of ambiguity and multi-interpretation of context.

4 Network of Stakeholders as EA Context

Shron argues that contexts emerge from understanding who you are working with and why you are doing what you are doing [9]. People learn the context from talking to others. The contexts set the overall tone of the projects, and guide the choices. The generic process of constructing the EA models consists of recognition of the environment of the initiatives, involved stakeholders, organizational culture and management commitment.

Martini and Aloini also argue that EA context is to be extended to cover learning about markets, practices such as lead user experimentation, unconventional tools, openness to external sources, practices that enable the search breadth and idea hunting [10]. Therefore, EA modelling requires studying the environment (see Fig. 1), wherein the business organization is immersed. Anthopoulos and Tougountzoglou [11] for digital city analysis consider a different set of factors. According to them, geographic factors refer to the geopolitical conditions in the country, city or region where the digital city will be located. Economic and market factors refer to wealth, enterprises and growth level in the particular area. The good financial conditions of households and firms support technology and innovative initiatives acceptance. Social factors concern the intention of local community to participate in project planning and project result exploitation. The political factors may support the transparency of public procedures and encourage the project initiation. Legal factors focus on the flexibility and the presence of rules and procedures for e-service deployment and use. Cultural factors concern social attitudes and indicate the existence of communities of common interests.

Fig. 1
figure 1

Enterprise architecture context specification

Full size image

Duffy [12] specified five different project cultures, which could be also included in the EA project implementation. Calendar-driven culture is characterized by an obsessive focus on schedule, movement from one milestone to the next and all decisions being based on short-term expectations. Requirement-driven culture focuses on functional and non-functional system requirements, and even a small change in the requirement specification is the signal of instability of the planned system. Documentation-driven culture is oriented towards producing the project documentation. The specific challenge is to determine which document to produce next. Quality-driven culture focuses on the quantifiable measures for characteristics such as performance, reliability and security, portability, maintainability, and scalability. The architecture-driven culture is oriented towards an accommodation of the new requirements. In that culture, the user can experiment with different versions of the system for its further incremental and iterative development. That culture supports the construction of adaptable frameworks, which are tuned to suit user requirements [12].

Technological factors refer to the technologies and technology standards that are involved in the EA projects, and to the existence of the appropriate IT industry. Human factors indicate the existence of supervisors and executives with proper skills.

The EA viewpoints define abstractions on the set of models representing the enterprise architecture, where each is aimed at a particular type of stakeholder and addressing a particular set of concerns. According to Lankhorst et al., viewpoints are designed for the purpose of service as a means of communication in a conversation about certain aspects of an architecture [8]. Each viewpoint means a different context. In general, the use of an architectural viewpoint will pass through a number of phases, i.e., scoping, creation of views, validation, obtaining commitment and informing the EA stakeholders. The activities cover generating EA views. The views are primarily the constructs for representing the architecture from different perspectives or viewpoints. The views are very effective as a means for communicating the architecture among the EA stakeholders. In EA frameworks and methodologies, there are different answers to who the stakeholders are.

Generally, in the EA environment, stakeholders need an influence on the EA realization by a number of drivers, e.g., strategy changes, a changing business and regulatory environment, and new technologies. Business managers are interested in business metrics and on reports that highlight some performance measures with the ability to view the same data but through different views. IT engineers are interested in system analysis and look for the metrics to determine the actual cause of critical events, e.g., operation shutdown or random maintenance episodes. Data scientists are responsible for performing ad hoc analysis on a multitude of data sets in heterogeneous systems, leveraging a wide variety of statistical and machine learning algorithms [13]. An obvious way to keep an adequate eye on the interests of stakeholders is a more direct involvement of them in enterprise architecture development activities and the assessment of top management.

The enterprise architects should be able to translate the strategic initiatives and areas of concerns in a concrete enterprise design. The areas important for the enterprise architect knowledge cover system thinking, business and organization, information, information technology, enterprise development and change. The enterprise architect is responsible for documenting, analysing and designing the business processes, business function, products, business units and business objects and the interactions between them. By the analysis of the entire business model, the enterprise architects are able to uncover the points where there is a need for action and the potential for optimization. There is a necessity to ensure the cohesion among all the other roles, i.e., application managers, project managers, process architects, business analysts, IT service providers, IT infrastructure providers, project portfolio controllers, IT strategists, IT managers, security representatives, risk managers, and quality managers (see Fig. 2). However, architecture development requires deep understanding of the enterprise business environment, which cover suppliers, customers, substitutes, government agencies, competitors, and new entrants as it is specified in Michael Porter model (see Fig. 2).

Fig. 2
figure 2

The EA stakeholders’ network

Full size image

The EA is typically to provide management with an outlook on the coming 3–5 years. The EA facilitates decision making processes by providing a holistic view of the enterprise, leading to better decision making. The enterprise architect is placed in a network of stakeholders (see Fig. 2). They are important only where presence of various diverse interests and elements of negotiations is apparent. Each of them represents a number of interests, which may include the achievement of the whole EA goals. As actors in a network, the EA stakeholders (see Fig. 2) achieve their significance by being in relation to one another. For further consideration, the Actor Network Theory (ANT) developed by Latour and Callon is useful to describe the creation and evolution of socio-technical networks [14]. According to the ANT theory, an actor is defined as an entity making other elements dependent upon itself. The position of the architect in the enterprise determines the associated controls of the EA development activities.

5 Network of IT Systems as EA Context

The stakeholders presented in Fig. 2 belong to certain business units, which dispose certain business information systems. These systems constitute an environment that should be respected in the EA development process. There is an opportunity to apply system context approach to emphasize the value of stakeholder systems. According to Mitra, system context documents how the IT system, which belongs to the analysed enterprise and which is typically represented as a black box, interacts with external entities, i.e., systems of competitors, suppliers, customers, and government agencies [15]. Analysis of the context of other network systems allows to clarify, confirm, and capture the environment, in which the system has to operate. The nature of the external systems, their interfaces, and the information and control flows are inputs to the downstream specification of the technical artefacts in the EA [15]. The System Context provides a catalogue of systems that are external to the system under consideration, the information flow with the external systems, the external events that the Technology System users need to be aware of or respond to, along with a catalogue of profiles of different types of user roles that will be accessing and interacting with the Information System to harness its capabilities [15].

Therefore, business architecture can be defined as the set of structures and stories that underpin “the business of business”. However, in each case, the relations among business systems are different, so they are discussed as follows:

  • No interaction, e.g., a certain anarchy, because the business organization is centred in itself, without external context.

  • Direct transactional interactions, i.e., supply chain, where the suppliers, customers and others are connected in the direct value network.

  • Indirect transactional interactions, including market systems of business analysts, recruiters, regulators, standards bodies, competitors in the overall marketplace for this type of enterprise.

  • Non-transactional interactions, but creating enterprise ecosystems, including investors, families, communities, non-clients, anti-clients, and others that can be impacted by and impact upon the business organization (see Fig. 3).

    Fig. 3
    figure 3

    The EA business partners’ systems

    Full size image

John Zachman emphasizes that in the EA development, the environment issues are described through ontologies. Hervas et al., specify three types of ontology [16]. The User Ontology is describing the user profile, their situation, i.e., location, activities, roles and goals, as well as their social relationships. The Device Ontology is the formal description of the relevant devices and their characteristics, associations and dependencies. The third, Physical Environment is defining the space distribution [16]. The enterprise ontology visualisation reveals the relevant elements of the context as well as metaphors, patterns, pipeline issues, interaction paradigms and methods, view structure, user’s social organization, data properties and scalability issues (see Fig. 3).

6 Network of Principles as EA Context

Wasson reminds that IEEE 1471-2000 definition of architectures focuses on the principles guiding the EA design and evolution [17]. Stair and Reynolds [18] think of principles as basic truths or rules that remain constant regardless of the situation. They provide strong guidelines for decision making. For example, practitioners in many disciplines prepare a code of ethics that determine the principles and core values that are essential to their work and govern their behaviour. Usually, principles are based on empirical deduction of observed behaviour or practices. The EA principles are strongly related to goals and requirements. Similar to requirements, principles define intended properties of EA systems. While a requirement states a property that applies to a specific system, a principle defines general characteristics that apply to any system. However, the principles are different for different enterprises and in each case the set of principles is different and as such, that collection of principles constructs the EA context. A principle must be specific for a given EA system by means of one or more requirements or constraints, in order to enforce that the EA system conforms to the principle. The EA principles can be descriptive, explanatory, predictive or prescriptive [19]. The scientific principles are cross-disciplinary and they are applicable in various design domains [20]. They are laws or facts of nature underlying the working of an artefact. The normative principles are based on artefacts such as strategy and influence other business, as well as guidelines, requirements or implementation plans. They are declarative statements that normatively prescribe a property of EA products. The principles are prescriptive because they concern the good practices of EA development, and they are predictive, because they concern the vision of ICT in the enterprise (see Fig. 4).

Fig. 4
figure 4

The EA principles’ network

Full size image

TOGAF defines an architecture principle as a qualitative statement of intent that should be met by the architecture. In ArchiMate, TOGAF visualisation tool, the Business Model Canvas is a source for motivating architecture principles and it states the business context for the EA description development. The canvas provides nine building blocks to describe the rational of how an organization creates, delivers and captures value. The building blocks are: customer segments, value propositions, channels, customer relationships, revenue streams, key resources, key activities, key partnerships and cost structure (see Fig. 4).

According to TOGAF, principles are general rules and guidelines that inform and support the way in which an organization sets about filling its mission [21]. In TOGAF, principles as inherent laws can be observed and validated and they always concern the stakeholders. In libraries of good practices for IT management and governance the principles useful for EA description development are also hidden. They should be revealed, considered and applied as the EA context. For example, Cobit 5 is based on 5 key principles for IT governance and management, i.e., meeting stakeholder needs, covering the enterprise end-to-end, applying a single, integrated framework, enabling a holistic approach, separating governance from management. In the EA development aspect, the principles concerning IT governance as a way of strategic thinking seem to be important. IT governance ensures that stakeholder needs, conditions and solution options are evaluated to determine balanced enterprise objectives to be achieved, setting directions through prioritization and decision making, and monitoring performance and compliance against the established objectives [22]. Compliance with applicable laws and regulations, reliability of financial reporting, and effectiveness and efficiency of operations are also emphasized in COSO (Committee of Sponsoring Organizations) internal control concept, affected by an entity’s board of directors, managers and other personnel and designed to provide reasonable assurance regarding the achievement of objectives [13].

The EA principles are a representation of an enterprise as they are embodied in the EA elements and their relationships in an appropriate model. They are fundamentals for description, construction and evaluation of system architecture. According to Sandkuhl et al., they are statements that provide a context for EA modelling and they support the transformation process of an enterprise [23]. The process of the EA principles development covers the following phases: principle identification and formulation, documentation, implementation, monitoring and adjustment. After the deployment, the EA principles should be communicated, regularly monitored and renewed during application.

7 Smart City Architecture Context—Case Study

Understanding context means allowing for familiarization with the nature of the business and sharing the information among the EA development team members. The EA development project is then considered in the perspective of the overall organization, which determines the project goals. The EA team needs to consider context when choosing which processes, practices and techniques they use and therefore they are sure they are doing the right things and they are not doing things that are unnecessary [24].

In the EA development process the context knowledge is explored in some subprocesses:

  1. 1.

    The EA project goals specification, context scope determining, taking into account appropriate views and viewpoints of the EA.

  2. 2.

    The EA knowledge contextualization, what means enriching the acquired knowledge with contextual information from different sources and about different entities included in the EA description.

  3. 3.

    The EA knowledge re-contextualization, what means creating knowledge through the sharing of experiences in the project team and monitoring the different sources of context. The re-contextualization is an iterative process. During which knowledge from different sources is evaluated and explored in the further plans and implementations.

  4. 4.

    The EA knowledge de-contextualization, which means knowledge abstracting and generalization in the computerized information system designing process.

  5. 5.

    Although the implementation of technical solution can be context free, the further deployment should be context sensitive, because it is realized in a certain social environment.

The context description for the EA development requires specifying the context scope, which determines what must be (or should) be considered for EA modeling and implementation. The context contents and its scope are relative and depend on the stakeholders involved in the EA modeling process. From the EA constructivist point of view, context scope and context knowledge are presented in the documentation of the project. The EA contextualization requires a critical reflection of the social and historical background of business activity, because the EA developer should see how the current behavior of citizen in the residential environment is emerging.

In the presented below case study, architecture description focuses on modelling the system architecture for the garbage collection in a municipality supported by mobile technology. The analysed problem belongs to the IT solutions for smart cities.

The smart city system architecture is realized in the circumstances of strong connection among IT governance and municipality strategy. The smart city architecture modelling starts with modelling of IT resources, i.e., hardware, software and networks as well as with modelling of the business processes and governance principles selection. The smart city architecture modelling is located in the city planning and formulated taking into account an analogy between city and system architectures (see Table 1). Taking into account the Table 1 content, the municipality planning can be considered as a certain waypoint for smart city architecture development and it is a context for city IT architecture. Therefore, knowing the city the designers of Waste Management System can develop, implement and deploy the system easily. The project starts from project goals’ specification, project feasibility recognition, and context scope identification. Wide spectrum of context knowledge encourages to reduction of the context aspects and to selection the most important issues. So, the EA developers are assumed to consider behaviours of citizens and city visitors, culture of waste management, demographics, local government priorities and principles, garbage collection transportation infrastructure, seasons of year and weather.

Table 1 Analogy between municipality planning and city IT architecture development
Full size table

The contextualization is realized in the aspect of the EA developers, however, that process is repeated, i.e., the re-contextualization is ensured by the other computerized system developers, designers, software engineers, and managers responsible for deployment. The context consideration and visualization in the EA model is validated in the iterative process of application development, business–IT alignment works, in experimentation process and through discovering new opportunities during mobile application development.

Although, the ArchiMate language express ideas on a high level of planning, the EA developers can use ArchiMate models to visualize assumptions, define desired business impacts and analyse user needs. The EA developers can use the ArchiMate models to drive stakeholder alignment and support prioritization of the needs. The stakeholders can discuss the various deliverables necessary to achieve a specific outcome and determine which ones will play the biggest part. For making good investments, the EA developers can identify options, compare solutions and control their research efforts.

Figures 5, 6 and 7 cover the EA model of wastage collecting in a municipality.

Fig. 5
figure 5

Waste management ICT architecture model: motivation and business layers

Full size image
Fig. 6
figure 6

Waste management ICT architecture model: business process in business layer

Full size image
Fig. 7
figure 7

Waste management ICT architecture model: application and technology layers

Full size image

ArchiMate 3.3.2 model consists of elements belonging to each of the following layers, i.e., Strategy, Business, Application, Technology, Physical, Implementation and Migration. In the presented in Fig. 5 model, the Business layer includes:

  • Actors, i.e., municipality citizen and dumping service client.

  • Services, i.e., dumping services, including the searching of information on garbage collectors, dumping service designing, service parameters’ registration and reviewing, dumping service optimization, compensation for dumping service providers, dumping process analysis.

  • Business processes, i.e., waste removal process (see Fig. 5).

The Motivation layer in Fig. 5 concerns the EA business strategy issues, i.e., EA driver, e.g., waste dumping needs, EA goal, e.g., citizen satisfaction, EA principles, e.g., municipality governance principles, service knowledge generating principles, EA assessment, e.g., waste management evaluation, EA requirement, e.g., social needs of environmental cleaning, EA constraint, e.g., citizen behaviours, (see Fig. 5). The specific context in the IT architecture is visualised by the icon “meaning” covering the knowledge on the garbage collecting process optimization. The EA Business layer focuses on business process, i.e., waste removal process covering the seven sub processes:

  • Package generating, i.e., generating the list of garbage collecting locations.

  • Dissemination of knowledge on wastages collecting and city cleaning.

  • Optimization of the transportation routes among locations for garbage collecting.

  • Garbage collecting services’ evaluation.

  • Dumping services’ registration.

  • Waste segregation.

  • Finalizing the work with the package, i.e., waste deposition (see Fig. 6).

In the EA models, Application layer includes the following components: financial application for service provider compensation, mobile device portal, dumping service information system, dumping services’ regulations and politics, support of ICT system for dumping service management. In the smart city architecture, the Technology layer comprises the following components:

  • Nodes: data server, application server.

  • Devices: mobile devices (md1 … mdn).

  • System software: service evidence database, dumping service management system applications (see Fig. 7).

In the presented model of system architecture for waste management in the city, the mobile devices for garbage collectors and optimization of waste deposition are emphasized (see Fig. 5). Mobile devices for garbage collectors seem to be important, because they are used to store the context data on dumping location and enable connections for the effective waste removal. In this case, mobile devices application allows for quick access to the data, real time information control and high speed decision making.

8 Conclusion

The smartness of the city is expressed by the number of intelligent buildings, cars, development of transportation infrastructure supported by ICT systems, as well as by the level of implementation of the system for supporting these assets, therefore, the Waste Management System can be placed among the other IT solutions. Modelling of the smart city context requires detailed specification of the modelling aspect and precise explanation if the subject of consideration concerns city economy, mobility of citizens, access to public services, reduction of wastage, and social capital development. The ArchiMate 3.3.2 tool supports the visualization of the EA context by the language elements of all layers, i.e., Strategy, Business, Application, Technology, Physical, Implementation and Migration. However, particularly important is the Business layer, where the “Principle” and “Meaning” elements (e.g., garbage disposal optimization in Fig. 5) are proposed to represent the context knowledge in the EA model. However, the language should be further developed to include the considerations on the EA context, which was in this paper visualised.