key: cord-0983512-qmlkl6go authors: Tummers, Joep; Tobi, Hilde; Catal, Cagatay; Tekinerdogan, Bedir title: Designing a reference architecture for health information systems date: 2021-07-08 journal: BMC Med Inform Decis Mak DOI: 10.1186/s12911-021-01570-2 sha: b2da466e60a07af7d3e984e2a4f91cc789d1161e doc_id: 983512 cord_uid: qmlkl6go BACKGROUND: Healthcare relies on health information systems (HISs) to support the care and receive reimbursement for the care provided. Healthcare providers experience many problems with their HISs due to improper architecture design. To support the design of a proper HIS architecture, a reference architecture (RA) can be used that meets the various stakeholder concerns of HISs. Therefore, the objective of this study is to develop and analyze an RA following well-established architecture design methods. METHODS: Domain analysis was performed to scope and model the domain of HISs. For the architecture design, we applied the views and beyond approach and designed the RA’s views based on the stakeholders and features from the domain analysis. We evaluated the RA with a case study. RESULTS: We derived the following four architecture views for HISs: The context diagram, decomposition view, layered view, and deployment view. Each view shows the architecture of the HIS from a different angle, suitable for various stakeholders. Based on a Japanese hospital information system study, we applied the RA and derived the application architecture. CONCLUSION: We demonstrated that the methods of the software architecture design community could be used in the healthcare domain effectively and showed the applicability of the RA. SUPPLEMENTARY INFORMATION: The online version contains supplementary material available at 10.1186/s12911-021-01570-2. Healthcare relies on health information systems (HISs) to support various care processes and receive reimbursement for the care provided. Examples of functionalities are financial management, daily reporting, and medication management [1] [2] [3] . Unfortunately, current HISs still have some drawbacks. For example, lack of interoperability resulting in care professionals having difficulty communicating files [4, 5] . Other studies on HISs reported problems with poor interface design [6, 7] , poor security [8, 9] , missing features [10, 11] , lack of professional support [12, 13] , limited use [6, 14] , and low data quality [1, 15] . Most of these problems occur when relevant standards, procedures, and guidelines are not followed effectively. Because HISs consist of many interrelated software modules that should communicate, coordinate, and evolve over time [16] , the software architecture is critical in HIS design. Bass et al. [17] define the software architecture of a program or a computing system as: "The structure of the system, which comprises software elements, the externally visible properties of those elements, and the relationships among them. " The software architecture supports communication on the system, guides design decisions, informs maintenance, and facilitates architectural analysis of the overall system [18] . *Correspondence: joep.tummers@wur.nl 1 Information technology, Wageningen University & Research, Hollandseweg 1, 6701KN Wageningen, The Netherlands Full list of author information is available at the end of the article There are two main approaches for software architecture design: informal and formal. The back-draw of informal software architecture design relying on boxesand-lines models, is that such a representation of the system is hard to understand because it is not standardized and does not follow a particular language. The formal approach follows the well-established ISO/ISEC/ IEEE 42010 standard [19] , which ensures unambiguous communication. A particular type of architecture that is generic and can help design specific software architectures for multiple software systems is the Reference Architecture (RA). An RA is a generic design that can be used to derive specific Application Architecture (AAs) based on the identified stakeholders' concerns, more quickly and with higher quality [20, 21] . The RA serves as an architecture blueprint for future software architects and should provide a standardized lexicon, taxonomy, and (architectural) vision [21, 22] . In the (grey) literature, several RA designs have been proposed for HISs [23] [24] [25] [26] [27] [28] [29] [30] . More information on these RAs is available in the Related Work Section. In practice, the derivation of the AAs from RAs is not trivial for two basic reasons. First of all, some of the proposed RAs do not focus on HIS in general, but only address the hospital sub-domain [29, 31] . Secondly, the proposed RAs do not seem to follow a proper architecture documentation guideline. [26] [27] [28] 30] . Furthermore, these RAs are far from complete, which hampers the design of the required AAs. The problems stakeholders experience with HISs require more clarity in healthcare's complex digital landscape, a clarity that RA provides. Therefore, the objective of this article is to develop an RA for HISs following well-established architecture design methods. The RA is dedicated to the healthcare domain and is represented using the software architecture viewpoints. To illustrate and evaluate the RA, an AA was derived in a case study on a Japanese hospital. The paper concludes with lessons learned and a discussion of the proposed RA. The following research questions were identified: • RQ1: What are the stakeholders and their concerns related to HISs? • RQ2: What is a feasible Reference Architecture for HISs? • RQ3: Does the Reference Architecture allow for the derivation of a specific Application Architecture? Our approach to these questions is depicted in Fig. 1 . Domain analysis is defined as the systematic activity for deriving and storing domain knowledge to support the engineering design process [32] . Domain analysis consists of domain scoping and domain modeling. Domain scoping identifies the domain's scope and the necessary knowledge sources to derive the key concepts [33, 34] . Domain modeling aims at representing the domain knowledge in a reusable format. Based on the domain analysis, we choose the relevant viewpoints [35] for our architecture design step. We continued with a case study, to evaluate the RA's suitability for deriving an AA. The RA can be used as a starting point for creating an AA [20] . The AA is described in this study as the software model of a specific application displayed through a combination of architectural views. To begin, an RA was created. The view of the RA was used to generate the corresponding view of the AA, as seen in Fig. 2 . The adopted approach for the RA design. Numbers inside tasks represent corresponding section numbers depicts the procedure followed for this derivation. For each view of the reference architecture, this approach was used; the application's necessary entities were first listed; then entities from the corresponding RA view were chosen based on the entity from the application. The required entity is reused if it could be identified in the RA; otherwise, a new entity was introduced to the AA. If the entity is located in the RA, it was examined to see if it can be reused in its original state or whether it has to be changed. If the names of the modules were the same or if the modules were interchangeable (e.g., financial management vs. economic management [37] ), the modules were considered entirely reusable. The module may be composed or decomposed if it is not reusable in its present state and thus had to be modified. In a composition, multiple RA modules were merged into a single AA module. As an example of a composition, a data transfer module and data collection module could be merged into a data processing module (see [38] ). After the decomposition, an RA module is broken down into several smaller modules in the AA. Finally, the reusability of the RA's entities was explored and the RA's usability (to derive the AA) considered. Concluding, making an AA for a particular settings (i.e. case study), serves as validation for the RA [20, 36] . This approach as described above and depicted in Fig. 3 , has been used in a variety of other domains such as agriculture [36] , supply chains [39] , and smart warehouses [33] . To scope and model the domain, we performed a systematic literature review [40] to identify papers in which HISs, their domains, stakeholders and, concerns and features were described. This resulted in a set of 11 papers [7, 10, [41] [42] [43] [44] [45] [46] [47] [48] [49] . HISs cover a wide range of sub-domains within healthcare. Many HIS papers focus on the hospital subdomain [7, 42, 47] , others focus on the primary care [10] , pediatrics [43] , outpatient care [45, 47] , and Methods used for deriving the AA. Each view from the RA will lead to a view in the AA, Adopted from [36] Fig. 3 Approach followed in building AA from RA Adapted from Tummers et al. [36] diabetes care [49] . The most common stakeholders and their concerns for HISs development are presented in Table 1 . While some stakeholders are generic for HISs, such as the patient, other stakeholders are more domain-specific, such as the Laboratory. To model the features of the HIS domain, feature modeling was adopted. A feature model represents the domain knowledge and desired system by distinguishing common, alternative, and optional(e.g., sub-domain specific) features of the system, and the interdependencies amongst these features [50] . The feature is defined as "a prominent or distinctive user-visible aspect, quality, or characteristic of a software system or system" [51] . Sub-features of a more general feature are shown under the most general feature in a tree-shaped model [51] . Our feature model for the HIS is presented in Fig. 4 and is based on the features mentioned in the literature. We split the full set of features into six main features (Middle column of Fig. 4 ). The Generic Management Information System (MIS) feature contains non-domain-specific features. The Data management feature contains features related to the management of data and data-driven decision-making by care professionals. Medication management and Patient monitoring are typical HIS features. Planning & scheduling is a feature mainly used by secretaries and administrative staff. Last, but certainly not least, the Security feature must ensure the system's resilience and protection of its data. In the next section, the selected viewpoints were used for designing the RA are described. In the subsequent sections, the HIS RA views were built from these four viewpoints. Although the HIS's main purpose is to assist in the current daily operations, it should also be flexible and adaptable to facilitate different long-term visions [16, 52] . To do so, the RA needs to cover all features of the feature diagram in Fig. 4 . The RA should also cater to users in all different sub-domains of healthcare and facilitate tailoring to local needs. After all, a hospital HIS needs to meet different demands than a general practitioner's HIS and thus, will have different architectural decompositions. For modeling the RA, we adopted the Views & Beyond (V&B) approach [35] . This approach consists of selecting out of 17 predefined viewpoints the ones of interest to certain stakeholders. The four viewpoints of particular interest to key stakeholders in the healthcare domain selected for modeling the HIS RA are the context diagram, decomposition view, layered view, and deployment view. The context view of a system contains the entities that are outside the system's scope but have a direct relation with the system [53] . The context diagram represents the context view and shows the system boundaries, environment, and the entities it communicates with [54] . The reference context diagram for the HIS is presented in Fig. 5 . The external entities and their communications with the HIS were based on the stakeholders and their concerns from Table 1 . Six external entities are considered obligatory: the HIS cannot function without them. The optional entities can be absent in simpler HISs such as automated data sources or are (sub)domain-specific, such as the laboratory. Besides, some (sub)domains may require specific entities that are not shown in the reference context diagram. Many entities have two-way communication with the HIS, meaning that the HIS communicates with the entity and vice versa. External entities with a one-way communication with the HIS, are rarer. For example, a governmental organization can receive reports from the HIS, but this organization has no authorization to access the HIS data. We only describe one type of communication per interaction due to space limitations, in practice, there are many more possibilities. The decomposition shows how a system can be decomposed into multiple (sub)modules and how they relate to one another (parent-child). This view often is the basis for HIS design, development, and system documentation [55] . The decomposition view helps to check for the presence of the required modules for all stakeholders. The HIS RA decomposition view consists of six modules with 34 sub-modules, see Fig. 6 . The first module is Medication management, containing sub-modules related to medication handling, distribution, and safety monitoring. The second module is Patient monitoring and contains sub-modules related to the assessment, admission, discharge, status, and referrals of patients, and is input for the electronic health record. The Patient monitoring module also contains a sub-module labeled Patient portal in which the patient can check his/her files. The Security module with the sub-modules Authentication, Authorization, and Security mechanisms must ensure the privacy and security of the HIS and its data. Module number four is Planning and scheduling, with sub-modules used by various stakeholders to ensure proper care coordination. The Generic MIS module is not healthcare specific. Its sub-modules are important to keep track of assets, such as staff and inventory, to provide means for organization-wide communication, quality control, and financial affairs. Often the features from the generic MIS module can be found in so-called enterprise resource planning (ERP) systems. These systems are business management system solutions which are used for managing, automating, and integrating all the business functions within an organization [56] [57] [58] . These five modules generate data, which needs management. This happens in the Data management module, which has sub-modules to ensure proper import, sharing, analysis, and data search. Figure 6 shows all described modules and sub-modules of the RA for HIS. A specific Application Architecture (AA) consists of a selection of these modules tailored to the stakeholders' requirements. The layered view reflects the software modules' allocation into different layers, based on a unidirectional "allowed to use" relationship between the layers Clements et al. [35] . We decided to base our layered view on the standard of enterprise software systems because of its flexibility (Fig. 7) . Starting at the top, the layered view consists of a presentation layer with a User Interface (UI). The presentation layer relies on the business logic layer that determines how data are created, stored, and processed. The business logic layer contains the Planning and scheduling, Generic MIS, Patient monitoring, and Medication management modules from the decomposition view (Fig. 6) . These four modules, the backbone of any HIS, generate and use data from the Data management layer. The Data management layer contains sub-modules to simplify access to the data. To provide overall HIS security, a vertical layer connected to all three horizontal layers was added. This Security layer contains the modules: Authentication, Security mechanisms, and Authorization for safety and security at all system layers. In the deployment view, software modules are allocated to the hardware entities on which they are executed. This view is useful for analyzing the performance, availability, reliability, and security aspects of the system [35] . Due to the vast diversity of HISs, we decided to develop a generic deployment view that can represent many of HISs across care domains The deployment view (Fig. 8) shows one or more clients and zero or more servers. If there is a client only, and no server, the deployment is a standalone desktop application or a thick-client with all modules on the client-side. A client-server application consists of at least one server and multiple clients, for example, thin clients with modules located on one or multiple servers. Finally, a system with multiple clients and multiple servers that communicate using cloud computing technology is cloud-based. A system will most likely have a back-up server in case the original server goes down, but a combination of other types of servers is also possible. These other types of servers could include load balancing servers to allow for big data analytics, as well as application servers, web Tummers et al. BMC Med Inform Decis Mak (2021) 21:210 Fig. 6 The reference decomposition view of the HIS servers, and database servers. The RA deployment view also provides space for a web-based application. In that case, only an internet browser is required on the clientside with which the end-user can use the HIS. The server is often provided by the software supplier, which contains the modules to host the web page and store the data. Depending on the specific requirements the allocation of the modules as identified in the decomposition view can be allocated in various different ways over the selected nodes in the deployment view. This study's primary objective was to propose and evaluate the RA. We decided to base the illustration and evaluation on a case study from the literature, as no site visits were possible due to the COVID-19 pandemic. For our case study, we used the well-detailed article by Jahn et al. [59] in which they compare a Japanese and German hospital HIS using the three-layer graph-based meta-model ( 3LGM 2 ) [31] . When presented and inspected visually, the 3LGM 2 model combines the UML decomposition view, uses view, and layered view. Our case study was done by developing an AA. for the Japanese Chiba University Hospital (CUH) based on Jahn et al. [59] . Figure 3 shows the approach followed to build the AA. The 104 modules of the CUH model in Jahn et al. [59] (page 6 Fig. 5) were mapped onto the features from our feature module (Fig. 4) . We added 47 sub-features to meet the level of detail presented in Jahn et al. [59] . Interestingly, Jahn et al. [59] listed more detailed Patient monitoring and Generic MISs features, which we included as sub-features in Additional file 1: Fig. 1 . In contrast, our RA was more detailed concerning the other HIS features. Although the stakeholders of the HISs are not explicitly mentioned in Jahn et al. [59] , we were able to make the application context diagram based on mentioned systems such as a Laboratory Information Systems and a Pharmacy Department System. The stakeholders and other entities of such systems combined with the obligatory entities and interactions from Fig. 5 , provided the application context diagram. There was no need to add extra external entities (see Fig. 2 in the Additional file 1). We used 12 out of 15 (80%) entities from the RA context diagram. The decomposition view extracted from Jahn et al. [59] is presented in Additional file 1: Fig. 3 . Despite slightly different wording in the labels of (sub)modules, we could make the decomposition view, which listed 104 modules from the feature model. Seven sub-modules from our RA were not found in the Japanese HIS and removed from the application decomposition view. Therefore, we utilized 27 out of 34 modules from the RA decomposition view, resulting in a re-use of 79%. Although the authors used the term "layers" differently than we do, the provided information allowed us to derive the layered view using our own design choices. The result was the same as depicted in Fig. 7 above. Jahn et al. [59] provide limited information about the CUH HIS deployment, but it does show the CUH databases. From this information, we inferred the deployment situation at the hospital. The deployment view is available in Fig. 9 . As discussed above and shown in the Additional file 1, we could successfully derive an AA for the CUH case from our RA. Making the views for the case study took us about two days (16 h) . Based on this case study, we made some minor changes to our RA, which were already included in Figs. 4, 6, and 7. To the best of our knowledge, this is the first RA for the health care domain built using standard architecture design approaches from the software architecture community. In this discussion, we critically reflect on our results and compare this study with related work. For the domain analysis, we relied on scientific articles. A more extended data collection from grey literature or expert interviews might have yielded different input for the viewpoint selection. We believe that the scientific articles provided a factual basis for the viewpoints because of their diversity across care domains, and, indeed, our case study did not suggest otherwise. Based on the key stakeholders' concerns and input from the domain analysis, four viewpoints were selected to model the RA. Together, these viewpoints gave a broad and solid overview of HISs. The Context Diagram and Decomposition View showed the architecture from the stakeholders' perspective, the Layered and Deployment View provided a standardized technical representation of HISs. The Deployment View (Fig. 8) was modeled generically to allow for various deployment alternatives, as illustrated in the case study (Fig. 9) . In current practice, the modules described in the decomposition view are often implemented by a combination of systems. In a hospital, for example, a hospital information system, an order management system, a pharmacy information systems, and many more systems are used. At first sight, a fully integrated ERP system would be an option to align these processes and systems. However, there are several difficulties in using ERP systems in the healthcare sector. First of all, the alignment of business processes with the ERP system is not an easy task, and the success of the project, therefore, depends on the complexity of the processes in the environment. For this alignment, either the processes or the ERP system have to be adapted, but some ERP systems require a lot of effort to be adapted to the required processes. Another problem is related to the vendor lockin problem [60] . When an ERP system is adapted for the healthcare provider, there is too much dependency on the vendor and the consultants who can provide the required services. The case study was based on a peer-reviewed article due to the COVID-19 pandemic. Although Jahn et al. [59] did not explicitly name stakeholders, the paper contained sufficient detail to derive the context diagram and the decomposition view. Similarly, we were able to derive the layered and deployment view based on the detailed information Jahn et al. [59] provided. The use of four views to derive the AA was demonstrated. In theory, the same procedure can be used to generate other potential perspectives (e.g. use views, layered views etc.). To do so, the appropriate views must be defined based on the chosen system's particular application requirements [35] . Till all the necessary views have been determined, the approach described above will be followed; that is, reference views will be established first, followed by application views. [59] When using this reference architecture for the development of a new system, it is very important to make use of the different standards for HISs. In order to ensure interoperability with other systems, standards such as HL7 FHIR should be used [61] Furthermore, the diagnoses in the systems should also be standardized using codes such as ICPC-2 or ICD11 [62, 63] . Future work will expand towards cases in the longterm care domain to further demonstrate our RA's applicability. Several other RAs for HISs have been published. The pioneer RICHE RA from 1993 [23] has an open architecture with three layers: user applications, basic applications, and information systems. Despite its old age, the paper described many problems that have remained unsolved up until today. Wartena et al. [24] described in 2010 a RA for a personal telehealth ecosystem with a focus on networking and communication, ignoring other features. More RAs for HISs are found in grey literature, such as white papers and technical reports. These RAs are often characterized by none [25] or some diagrams only [26] [27] [28] , and do not apply any formal software architecture modeling technique, as defined in the computer science literature [64] . We found three papers that used diagrams systematically to describe their RA for hospitals [29, 31] , and healthcare in general [30] . Nictiz [29] presented an RA for hospitals using an Archimate model [65] . Their RA showed similarities with ours: their domain 'reference model' contained many elements from our decomposition view and layered view. However, the Archimate Model is limited to the scope of enterprise modeling [66] and is based on the by now replaced IEEE 1471 standard [67] . In contrast, UML has a much broader scope and contains many more modeling concepts to choose from, 150 instead of 50. Winter et al. [31] based their RA for the hospital domain on the UML-based 3LGM 2 model, which had also been used by Jahn et al. [59] . Winter and colleagues' metamodel for modeling Hospital Information systems, shows similarities with our RA as explained in Section 5. An RA with a similar scope to ours is ATOS' "IT Reference Architecture for Healthcare" [30] . They did not use UML models, but an informal approach to display the ICT services for HIS development. Their RA shows some overlap with our decomposition view but ignores a deployment view. Compared to the other RAs, our RA is generic, uses UML models, and addresses the entire healthcare domain. In this study, we showed that the methods of the software architecture design community could be used in the healthcare domain effectively: we proposed a generic RA for HISs. We have shown the suitability of the RA for deriving the AA for a University hospital in Japan. Our method of evaluating an RA was successful for one case study. In our future work, we will use this method to a greater extent and apply the reference architecture for designing the architecture of various other HISs. Assessing the ability of health information systems in hospitals to support evidence-informed decisions in Kenya Electronic health record adoption in US hospitals: the emergence of a digital "advanced use'' divide Recommendation system using feature extraction and pattern recognition in clinical care systems Decision support systems for adoption in dental clinics: a survey. Knowl-Based Syst Electronic health records and support for primary care teamwork A typology of electronic health record workarounds in small-to-medium size primary care practices The implementation of clinician designed, human-centered electronic medical record viewer in the intensive care unit: a pilot stepwedge cluster randomized trial Comparison of two heuristic evaluation methods for evaluating the usability of health information systems Current status of electronic medical record systems in hospitals and clinics in Korea Electronic health record usage behaviors in primary care medical practices: a survey of family physicians in Canada Nursing student experiences regarding safe use of electronic health records: a pilot study of the Safety and Assurance Factors for EHR Resilience guides A six-year repeated evaluation of computerized clinical decision support system user acceptability Usability problems do not heal by themselves: national survey on physicians' experiences with EHRs in Finland Development process of a mobile electronic medical record for nurses: a single case study Development of mHealth applications for pre-eclampsia triage Health care information systems: architectural models and governance Software architecture in practice Software architecture IEEE 42010 Systems and software engineeringarchitecture description Aligning business processes and IT of multiple collaborating organisations A reference architecture primer. Eindhoven, White paper. Eindhoven Univ. of Techn of Defence/Office of the DoD CIO: reference architecture description The RICHE reference architecture Continua: the reference architecture of a personal telehealth ecosystem Extreme: Healthcare reference architecture Nationwide health information network exchange. Nationwide health information network: enterprise architecture overview. technical report Connected health reference architecture Nictiz: Domain reference model for hospitals version 2 ATOS. IT Reference architecture for healthcare 3LGM2-modeling to support management of health information systems Obstacles in data distribution service middleware: a systematic review Design of a reference architecture for developing smart warehouses in industry 4.0 Classifying and evaluating architecture design methods Documenting software architectures: views and beyond Reference architecture design for farm management information systems: a multi-case study approach. Precision Agriculture Research about based-SOA agriculture management information system IFarm: development of cloud-based system of cultivation management for precision agriculture Realizing chain-wide transparency in meat supply chains based on global standards and a reference architecture Guidelines for performing systematic literature reviews in software engineering The value of electronic medical record implementation in mental health care: a case study A comparison of electronic health records at two major Peking University Hospitals in China to United States meaningful use objectives Assessing the impact of a primary care electronic medical record system in three Kenyan rural health centers Usability evaluation of an electronic medication administration record (eMAR) application convenient online submission • thorough peer review by experienced researchers in your field • rapid publication on acceptance • support for research data, including large and complex data types • gold Open Access which fosters wider collaboration and increased citations maximum visibility for your research: over 100M website views per year submit your research ? Developing and deploying medical information systems for Serbian public healthcare: challenges, lessons learned and guidelines Integration of footprints information systems in palliative care: the case of Medical Center of Central Georgia Regenstrief Institute's medical gopher: a next-generation homegrown electronic medical record system Advice for decision makers based on an electronic health record evaluation at a program for all-inclusive care for elders site A patient-facing diabetes dashboard embedded in a patient web portal: design sprint and usability testing Feature-driven design of SaaS architectures Feature-oriented domain analysis (FODA) feasibility study Towards the design of resilient largescale engineering systems The complementary use of IDEF and UML modelling approaches IT infrastructure and management (For the GBTU and MMTU) Software engineering: principles and practice Obstacles of on-premise enterprise resource planning systems and solution directions Alliances, rivalry, and firm performance in enterprise systems software markets: a social network approach Moving beyond the single site implementation study: how (and why) we should study the biography of packaged enterprise solutions Comparing a Japanese and a German hospital information system Critical analysis of vendor lock-in and its impact on cloud computing migration: a business perspective Hl7 fhir: an agile and restful approach to healthcare information exchange World Organization of National Colleges, Academies, and Academic Associations of General Practitioners/Family Physicians. In: ICPC-2: international classification of primary care World Health Organization. International classification of diseases for mortality and morbidity statistics, 11th Revision Life cycle processes-Requirements engineering ArchiMate 2.0 specification: Open Group Standard Advances in government enterprise architecture Standard for describing the architecture of a "softwareintensive system Publisher's Note Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations Not applicable.Authors' contributions JT did the domain analysis, the first version of the figures, and prepared the concept paper. JT and HT prepared the final manuscript for submission. All authors contributed to the research design, the development of the reference architecture, the Case study, and the manuscript. All authors read and approved the final manuscript. This research did not receive any specific grant from funding agencies in the public, commercial, or not-for-profit sectors. It is part of a larger set of projects that have been funded by the Dutch Ministry of Health, Welfare and Sport. The online version contains supplementary material available at https:// doi. org/ 10. 1186/ s12911-021-01570-2.Additional file 1. Application architecture figures.