The paper reports the findings of case studies on the application of the C4 software architecture development method. It focuses on development of edge and cloud systems and aims to analyze peculiarities of collaborative software design and practices of designing the edge and cloud systems. Three applied research projects are considered on the development of smart systems. The C4 method proved valuable in establishing a common understanding on the development of distributed systems. However, there were significant diferences among the projects in a way the method was applied and a level of details represented in software architecture. That is at least partially influenced by the organizational structure of development teams. The research is envisioned to lead to a set of recommendations and best practices for software modeling, applying the C4 method and the collaborative development of distributed systems in general.
Many modern information systems are characterized by a high level of complexity due to their distributed nature, data heterogeneity, scalability requirements and other factors. Systems architecture provides an overview of the envisioned technical solution by defining key components and their relationships. It helps developers to conceptualized and reason about technical challenges and plays an important role in communication of the solution among stakeholders, allocation of work to development teams, analyzing non-functional requirements and evaluation of design choices.
Architecture has been recognized as a way to coordinate software development activities [
Visualization of software architecture facilitates collaboration and comprehension [
We have applied the C4 method in several applied research projects conducted in collaboration between a university and industry. These projects deal with development of software systems for sensing enterprises and involve using IoT, big data and edge and cloud technologies. The development work is divided between the university and industry partners (more than one industry partner in some cases). This paper aims to summarize experiences accumulated during the system architecting phase and on usage of the C4 method in particular.
The overall goal of this research is to understand challenges and best practices of development of architecture of distributed systems and edge and cloud systems in particular. The evaluation is performed with respect to key features and components of the edge and cloud system architectures reported in literature. In future research, that would lead to a set of recommendations one could use to guide the system development process in the collaborative environment. Case study research [8] is adopted as a research method. System architecture documentation as well as messages exchanged among the developers during the development process are analyzed from three applied research projects.
The rest of the paper is organized as follows. Section 2 briefly reviews the C4 method and analyzes existing work on architecture of edge and cloud systems to identify typical features of this architecture. The case study is reported in Section 3, and Section 4 concludes.
2.1. C4 Method C4 is a method for development of software architecture [6]. It allows for a gradual decomposition of the system, defining the main components and designing and detailing the specific services sequentially. The C4 method is an "abstraction-first" approach to diagramming software architecture, and it attempts to mimic a way software architects and developers think about software design and development [6]. It uses a limited set of constructs (i.e., person, software system, container and component) arranged in four levels of elaboration. The design process starts with a context diagram (a landscape diagram can be added as an optional Level 0 diagram), proceeds with a container diagram and a set of component diagrams for each container. A detailed design can be elaborated at Level 4 using variety of software engineering techniques such as UML. This paper concerns levels one to three.
C4 starts with identification of the core software system to be built and defines its context in the Context diagram (Level 1). This diagram shows users of the software system and key related systems. The Container diagram (Level 2) splits the software system into applications and data stores required to have a running system. It is useful for showing the overall allocation of responsibilities to specific parts of the software system. The component diagram (Level 3) is created for each container and shows major building blocks and their interactions. A component is a grouping of related functionality and has a clear access interface. Technology choices and implementation details can be represented at this level.
The C4 Domain specific language (DSL) allows to describe software architecture following the model-as-code principle. Elements of the software architecture and their relationships that define the software model are declared. These elements are subsequently arranged into views displayed as diagrams. Various visual aids can be added to the diagrams.
The C4 method was selected primarily because of its ability to clearly allocate responsibilities to parties involved as well as due to its light-weight approach and quick ramp-up. Other advantages of the method are a collaborative on-line workplace, version management, getting ready methodological guidance and DSL.
Edge and cloud computing combines an ability to process data at their origin with capabilities of
cloud computing. It finds applications in IoT solutions, Industry 4.0 and smart systems. It follows
a distributed computing paradigm requiring integration of diferent data processing technologies.
The key requirements towards the edge and cloud architecture include proactive control in real time,
decoupling of control from physical devices, interoperability, visualization, data availability, scalability,
operational/long-term data storage and eficient usage of computational resources [
A case study research is conducted to observe application of the C4 method in practice. The cases selected are three university and industry joint applied research projects. All projects deal with development of smart systems. The university and companies involved have their own separate development teams with separate management, and the chief system architect was from the university’s team. Diferent companies were involved in the projects while the core university’s team was the same although two persons served as the chief architect in these projects.
• Do system architects follow best practices of design of edge and cloud systems? • What are peculiarities of using the C4 method? • Does using the C4 method facilitate collaboration among the teams? The first research question compares the models created with the reference model reported in literature with focus on types of components used. The second question aims to identify diferences and commonalities of using the C4 method across the projects. Finally, one is interested into utility of using C4 or similar methods, and the third question aims to provide initial insights on value of the method.
One completed and two on-going projects are selected for exploration. Project 1: The project aims to create a platform for ensuring a safe working environment that integrates advanced information and communication technologies and biotechnologies. The platform combines business continuity planning, IoT, computer vision, machine learning and wastewater analytics technologies for comprehensive Covid-19 and other infections risk assessment, mitigation and prevention in workplaces where the nature of work limits remote working options, such as shift-based manufacturing companies. Project 2: The project concerns work-in-progress inventory management in the production environment. A production operator receives information about production orders what includes a list of materials required to produce an end-product. Sensing technologies such as computer vision and RFID provide data on location of the materials. These data are aggregated and processed to create a materials pick-up route, which is executed to set-up a production step. The production step yields an intermediate product, which should be placed in a suitable location on the shop-floor for the next production step. A software system is being developed as a service, which can be integrated with the existing ERP system used by the manufacturing company. Project 3: The aim of the project is to develop an edge-cloud based AI-driven power resource management and balancing platform for ofice buildings, which would be compatible with the building’s local systems and external data sources, and would maximise the use of renewable resources, minimise electricity costs while ensuring the desired level of user convenience. Although software systems are being developed in diferent efilds of application, they all rely on intelligent processing of sensor data and combine edge and cloud capabilities for eficient data processing.
Complete software architecture documentation was available for all three projects. That included diagrams and descriptions created as well as the complete version history of updates made in the models and diagrams during their continuous elaboration. A drawing tool based on templates was used in Project 1, while Structurizr on-premise installation was used in Project 2 and Project 3.
Project 1 is completed and Project 2 and Project 3 are currently entering the implementation phase.
Level 1 to Level 3 diagrams were elaborated in all projects. An optional Level 0 landscape diagram was created for Project 3 because the participants required a more detailed understanding of the application context. The architecture was strongly influenced by a three tier client-server system with easily recognizable data, application and presentation layers (Fig.1). That can be explained by having a legacy time management application at its core. The architecture is also characterized by a wealth connections with external systems. The architectures in Project 2 and Project 3 start with explicit separation of edge and cloud systems (Fig.2) and are influenced by the microservice approach.
Structurizr was not used in Project 1. Although the main syntax requirements were observed, diagrams also included additional pictograms and variety of explanatory comments. This approach was possible because the chief architect centralized the architecture management. A more distributed approach was taken in other projects and following DSL allowed to keep diagrams consistent and readable. Typical edge and cloud architecture components can be identified in all three projects (Table 1). Project 2 has the most advanced edge processing and limited number of edge devices, and the sensor data flow is also handled using the edge server using dedicated components for each sensor type. Project 3 stores and updates device profiles in the edge and has a central edge system responsible for data gathering and processing for a specific location (i.e., building). The cloud system is responsible for advanced analytical features using machine learning. Many technology choices are identified in the software architecture for Project 1, while Project 3 mainly uses generic terms, e.g., user interface wise just an abstract Front-end system component is provided. All three projects use diferent approaches to showing relationships. Technical terms specifying interfaces and protocols are used in Project 1 (Fig.3). Project 2 operates with a limited set of verbs and nouns to describe exchange of messages in style close to REST. Textual descriptions are in used in Project 3 (Fig.4). Project 3 also has the largest number of connections. Many connections were defined in the model and subsequently excluded from the views to improve readability. Many of the connections were made to service components such as logging and there were discussions of the most suitable ways to represent such service components. It is observed that diagrams are becoming more verbose as one moves to the component level. That is especially noticeable in elaboration of analytical features what might be explained by limited DSL expressiveness or uncertainty about solutions to be developed. Detailed descriptions were added to elements and connections in the diagrams in Project 3. The development company used subcontractors in this project and there very several additional rounds of reviews and approvals. None of the software architectures created explicitly accounted for security management what is an essential part for edge and cloud systems. Perhaps, the hierarchical structure of C4 is not well suited to representation of cross-cutting features. Nevertheless, Project 1 and Project 2 included components for device management in the cloud.
Getting started materials provided by C4 and a brief introduction sessions proved suficient for companies’ developers to pick-up the core principles and concepts of the method. The choice of the light-weight approach proved to be helpful because industry architects and developers were much less used to structured modeling methods and were primarily relying on free-form visualizations or low-level of abstraction forms.
The paper has explored empirical experiences on using the C4 software architecture method in three applied research projects on development of edge and cloud systems. The exploration was guided by a brief literature review on typical characteristics of edge and cloud systems. The overall observation is that application of the C4 method achieved its stated objective of coordinating software architecture development among development teams involved.
Although the typical features of the edge and cloud system are present in all diagrams, significant variations were identified among the projects. The software architecture is more detailed in Project 1, and it was used to guide the development process without much of an additional work on detailed design. It is possible that models in Projects 2 and 3 will be further elaborated as the projects are entering the implementation phase. The project’s organizational structured influenced the way the C4 method was used and models were prepared. The degree of centralization and the way reviews were organized had significant impact of appearance of the diagrams. The variations also suggest that software architects need additional guidance on using the C4 method.
The paper reports only analysis of the models created. However, it would be beneficial to survey projects’ stakeholders about their views on eficiency of the development process. That would yield a more comprehensive answer to the third question. The software architecture was implemented as planned in Project 1, while retrospectives for Project 2 and Project 3 will be performed in due time.