logseq/pages/EditoringChairing___SOSYM-25-00005370.md

collapsed:: true type:: REVIEWS tags:: year:: 2026 venue:: SOSYM full-title:: date-start:: 12-01-2026 - 19:32 date-submitted:: external-links:: status:: DOING deadline-submission:: file:: parent:: todoist:: https://app.todoist.com/app/task/software-and-systems-modeling-manuscript-id-sosym-25-00005370-6fjGH2pWwHchxRFg

- ### [[Comments]]
	- My comment
		- All the reviewers recognized the benefits of applying Formal Cocept Analysis (FCA) to cloud resource management. However, there is the consensus to reject the paper for at the least the following criticalities:
			- Reviewers noted that the contribution is more aligned with cloud computing or operations research journals. The modeling presented does not reach the level of rich architectural or behavioral modeling expected for SoSyM.
			- Reviewers identified fundamental issues in the algorithms and formalizations. Specifically, the claim that the algorithm ensures "optimal" allocation was proven incorrect via counter-examples provided in the reviews.
			- The evaluation relies on synthetic workloads and a simulation environment (CloudSim Plus) without sufficient explanation of the underlying mechanics, a replication package, or a comparison against real-world industry traces.
			- The manuscript contains several "broken" references (e.g., Figure ??), typos, and structural issues where sections end abruptly or are incomplete (e.g., Section 5.4).
		- I believe the detailed feedback provided by the reviewers are helpful should you decide to refine the work for a more specialized cloud computing venue.
		-
			- ---
			- A sample check revealed several citations that appear to be non-existent or point to unrelated works (e.g., references [21-25]). In the current publishing climate, such "hallucinated" citations are a serious concern and suggest a lack of rigor in the preparation of the manuscript.
			-
			- **Methodological Weaknesses:** The evaluation relies on synthetic workloads and a simulation environment (CloudSim Plus) without sufficient explanation of the underlying mechanics, a replication package, or a comparison against real-world industry traces.
			- **Presentation:** The manuscript contains several "broken" references (e.g., Figure ??), typos, and structural issues where sections end abruptly or are incomplete (e.g., Section 5.4).
	- Reviewer 1 / REJECT
		- Confidential comment
			- I suspect there may be some use of generative AI in this submission. I only sampled a few references, and found issues in most of them. See this part of my review below:
			- The bibliographic references need to be thoroughly checked. I selected [21-25] as a sample, and found issues in all of them:
			- The DOI link for [21] points to a different ICWS 2010 paper ("Formal Specification and Verification of Data-Centric Service Composition"). Please correct your link.
			- I could not find the paper [22]. I could not find any paper with that title in Google Scholar at all, and volume 2, issue 1 of the Journal of Cloud Computing does not mention it either: https://link.springer.com/journal/13677/volumes-and-issues/2-1.
			- The DOI link for [23] does not work (https://doi.org/10.1109/ICSS.2013.6550432). The correct DOI is 10.1109/ICSS.2013.13.
			- The DOI link for [24] points to a different CLOUD 2012 paper. I could not find a paper with this title in Google Scholar (""An approach for tenant placement in multi-tenant saas applications"). I could not find this paper among the CLOUD 2012 papers, either.
			- I could not find the paper [25]. I could not find any paper with that title ("Formal concept analysis for dynamic resource reconfiguration in energy-efficient cloud computing") in Google Scholar, the DOI link does not work, and the relevant volume and issue of the journal do not list any papers with "Formal" in the title: https://www-computer-org.libproxy.york.ac.uk/csdl/journal/cc/2023/02.
			  
			  These incorrect references (or references to missing papers) are representative of the hallucinations caused by improper use of generative AI. I suggest the editor to thoroughly check the other references in the paper and make a decision on this aspect.
		- Publilc comment
			- In this article, the authors propose using Formal Concept Analysis to describe the interdependencies between tenants and application instances, and present an algorithm for consolidating tenants into a reduced set of application instances and servers, with the aim to reduce the number of active servers and therefore save energy. The authors show a comparison of their approach against other algorithms, running within the CloudSim Plus environment. The authors show results that compare positively against those of the other algorithms, and set a number of future research directions, including validation on real testbeds and extension to heterogeneous environments (as the simulation used homogeneous servers).
			  
			  While I appreciate the value of reducing the number of servers required to host a number of tenants, I feel that this paper is not a good match to SoSyM. The modelling in this paper seems to be limited to enumerating the servers, VMs, applications, and tenants, and setting the incidence matrix that relates tenants to applications. An enumeration of tenant-application dependencies is not a good example of the rich type of modelling (e.g. architectural / behavioural modelling) that I would normally associate with SoSyM papers. There is a subconcept-superconcept relationship implicit in FCA, but as far as I can tell this is automatically derived from the incidence matrix, so the contribution would be much more appropriate to a cloud computing journal (indeed, some of the cited works, like [40, 41], are from such journals), or to an operations research journal (given this is essentially a constrained resource allocation problem).
			  
			  In addition, it appears the algorithm itself is based on a multi-stage greedy search, which I would normally consider to be weak to local decision-making. In Section 5.2, the authors claim that "The algorithm's dual-phase approach ensures both optimal initial resource allocation and continuous optimization", which is a very strong claim. However, unless I have misunderstood Algorithms 2 and 3, I can think of one trivial counter-example that would show the algorithms cannot guarantee optimal results, as it is claimed. Consider this scenario:
			- We have three servers: s1 has capacity=30, s2 has capacity=20, and s3 has capacity=20.
			- Each server has a VM which takes up their entire capacity (for simplicity): v1 in s1, v2 in s2, and v3 in s3.
			- Each VM has an application instance: a1 in v1, a2 in v2, a3 in v3.
			- We have 3 tenants as well: they can be hosted in any of the three application instances, and delta(a, t) = 10 for every a in A and t in T.
			  
			  My understanding is that Algorithms 2 and 3 would work together as follows:
			- Algorithm 2 will first add t1 to s2, as it's the first server with the minimal stimulus of 20.
			- Algorithm 2 will then add t2 to s2, as it has the minimal stimulus of 10.
			- Algorithm 2 will then add t3 to s3, as it has the minimal stimulus of 20 among the servers that can still host it.
			- Algorithm 3 will power off s1 as it has the maximum stimulus and is not hosting any tenants.
			  
			  We have now ended up with 2 servers with a total capacity of 40 and a total unused capacity of 10, when optimally we could have just moved all tenants to the larger server with a capacity of 30. I acknowledge this is still an improvement over the original 3 servers, but it is not the optimal solution, so the authors cannot claim it "ensures [...] optimal initial resource allocation".
			  
			  Incidentally, the algorithm itself is *not* energy-aware. It aims to save energy, but it does not use any kind of energy-related information as far as I could tell. It is strictly grouping based on resource usage, and Section 4.2 explains the resources are CPU, memory, and I/O. This impacts the title as well, as it claims the approach is energy-aware.
			  
			  The above concern is a matter of ensuring the claims are adjusted to represent more faithfully the capabilities and limitations of the algorithm: the results in Section 6 would in principle support the argument that the algorithm is a valuable contribution. However, the study itself has problems:
			- To start with, I could not find any link to a research artefact that would allow for independent verification of the results.
			- The paper appears to assume that the reader is deeply familiar with the nature of the simulation implemented by the CloudSim Plus tool. However, as I mentioned above, SoSyM is not a cloud computing journal, and the audience will not be familiar with this tool (in fact, I have never heard of nor used this simulation tool).
			- The paper mentions the impact of the algorithm on simulated metrics such as energy consumption (Fig 9), SLA violations (Fig 15), energy savings (Table 9), and network latencies (Fig 17), without explaining how these are simulated by CloudSim.
			- Section 6.3.4 says that " FCA ability to identify optimal tenant groupings [...], making it particularly suitable for dynamic cloud environments", but it is unclear how this dynamism is reflected in the CloudSim simulation. Do tenants, applications, and/or their relationships change over time in the evaluated simulation? It is unclear how the authors have validated this particular claim.
			- Section 6.3.5 mentions three scenarios for sensitivity analysis based on demand variability, but it does not explain how this variability is quantified or implemented in the simulation. The metrics appear to be from single runs with 1000 tenants of each algorithm, which would not be appropriate for a sensitivity analysis due to the stochasticity of the simulation: Section 6.1 for example mentions that "each tenant requests a resource vector with values randomly generated between 100 and 500 units", so the results could potentially vary significantly from one run of the simulation to the other. I would have expected to see confidence intervals instead of individual values for each metric, based on not one run per algorithm, but rather a number of executions for each algorithm that would ensure the confidence intervals would be representative.
			- Incidentally, 6.1 mentions a "data center comprising 110 homogeneous servers", but only "10 application instances". How can there be fewer application instances than servers? Do the authors mean that each server has 10 application instances? How was the FCA tenant-application incidence relationship generated in these CloudSim simulations?
			  
			  I also note that this algorithm appears to be strictly limited to server consolidation, i.e. shutting down servers and migrating tenants to other servers - it cannot, for example, start a slightly larger server to reassign multiple tenants into it. It is also dependent on the definition of that incidence relationship, and it does not clearly explain how that relationship would be defined in a real-world environment. Who would know about all the application instances where every tenant can be hosted, and how would they maintain this information over time?
			  
			  Finally, the presentation of the algorithm needs a near complete overhaul, far beyond what would be appropriate for a revision:
			- First, while Section 4.2 talks about virtual machines, the algorithms do not use these virtual machines at all - they only work with servers, application instances, and tenants. The concept of VM could be removed altogether without impacting the algorithms at all - this seems like a severe oversight.
			- Section 5.1 makes some additional definitions (load of capacity server, capacity of physical server) that should be done instead in Section 4.2 (as the size and capacity of the server), and repeats some definitions (like delta(a, t)) that are already made in Section 4.2.
			- Section 4.2 defines reg(t) as a d-dimensional vector without having defined d first. Please reorder the definitions.
			- I understand that v_0 and a_0 are meant to be d-dimensional vectors. Please clarify.
			- State(s) should be renamed to Active(s) as it is strictly a Boolean predicate, rather than returning one of a larger set of states.
			- In (1), S_i is not defined anywhere.
			- In (2), the definition should have reused a(t), e.g. by saying "if a(t)=a_i". (3) should have been formalised similarly.
			- (4) appears to contradict a(t). a(t) indicates there is exactly one application instance hosting the tenant t, but (4) says that they must be assigned to *at least* one.
			- (5) mismatches the sentence above it. The sentence above it should say that "Each virtual machine must contain AT MOST a single copy of a given application instance".
			- Section 5 starts with the ACT and APT algorithm, but APT depends on the concept lattice having been set up first. Please rearrange the discussion to start with the concept lattice setup (Section 5.3), and then discuss the algorithms that use the lattice.
			- The Figure 2 flowchart does not clearly relate to the various algorithms, and could be much better explained via an algorithm rather than as a flowchart. It also has overlapping and crossing lines, and the notation does not follow any known standard (which is important to the SoSyM audience).
			- It is unclear whether a single round of consolidation (a single execution of Algorithm 3) is performed, or if several rounds are performed (e.g. until no further migrations are done). Please clarify.
			- The discussion of the algorithm mentions both ADD_NEW_TENANT (Algorithm 1), and ADD_TENANT_TO_SERVER (Table 2). Please unify.
			- Algorithm 4 suggests that execution stops on the very first super-concept where at least one tenant could be placed (the "break" on line 22). This contradicts the discussion in the paper. Please correct.
			- In Section 5.3, the summation of weights in the CM(CD) definition does not make sense. Suppose we have only three tenants (t1, t2, and t3), and only two concepts, one whose intention is {t1, t2}, and one whose intention is {t2, t3}. The first concept would have weight 2/3, the second concept would have weight 2/3. Adding them together would be 4/3, and not 1, but they would have CM(C) = 1. In fact, CM(CD) appears entirely superfluous and CM(C) should be enough.
			- The 3D visualisation in Figure 4 does not provide any value to the reader. It is incorrect to show values other than 0 and 1, as the incidence matrix is strictly binary in nature (either a tenant and an application instance are related, or not).
			- Figure 5 is more representative of the nature of the relationship, but it is not possible for the reader to follow the rearrangement of the applications and tenants. Please relabel the rows and columns in b) appropriately to clearly show how the applications and tenants in a) were rearranged to produce the shown clusters. For example, in Fig 5a T1 is related to A1, A2, A6, and A7, but in Fig 5b T1 is related to A1 to A4 - I would instead expect the first rows of Fig 5b to be A1, A2, A6, and A7. The caption says as much: "Reordered matrix".
			- Please explain to the SoSyM readers what is a "Galois correspondence" in Section 5.3.3.
			- In Figure 7, please clearly explain what you mean with "Relation" (is it the subconcept relation?), and who exactly (and how) selected C3, C6, and C4. I also note that if the arrows are meant to be subconcept relations, then the diagram is incorrect: C7 is not a subconcept of C5 as neither the tenants of C7 are not a subset of the tenants of C5, nor the apps of C5 are a subset of the apps of C7.
			- Section 5.4 is simply incomplete, being made up of just 3 lines and not showing any actual evaluation parameters.
			  
			  To conclude my review: the paper is not a good fit for SoSyM, the study is lacking a discussion of the underlying simulation and a link to a verifiable research artefact, the title of the paper and its claims need to be adjusted to reflect the strengths and weaknesses of the algorithm more accurately, and the formalisation of the algorithm is inconsistent and is in need of major improvement. I have also noticed a number of concerning issues about the bibliographic references, which I list below, as well as a number of minor presentational problems. For all these reasons, I think that the paper needs more work before it can be published than what would be appropriate for a revision.
			  
			  Here are my presentational and bibliographic comments:
			- There are typos in the text (e.g. "reacll" in Section 5.1), and broken references to figures and algorithms (Figure ?? and Algorithm ??).
			- Where Section 2.2 introduces the concept of FCA and says that Rudolf Wille introduced it in 1982, it should cite the original paper proposing this idea.
			- Figure 1 is poorly explained. Who is the "consumer" and who is the "producer"? Why are IaaS, PaaS, and SaaS stacked vertically like that? Which of these models is relevant to the paper, and how do "tenant" and "application instance" map to those models?
			- In Section 5.1, remove "sophisticated" from "sophisticated migration strategy". It is up to the reader to judge whether your strategy is sophisticated or not. Please limit the discussion to a factual description of your algorithm.
			- Section 5.1 ends abruptly, followed by a Section 5.2 header that does not contribute anything. Remove the Section 5.2 header to allow the discussion to flow into the itemised list, and reorganise the floating elements (Algorithm 2 to Algorithm 4, Figure 2, Table 2) so they do not disrupt the conversation.
			- In Section 6.2.1, the authors say that "We implemented a Q-learning-based scheduler [47]", but [47] appears to be from a different set of authors. Did the authors mean to say that they implemented the Q-learning-based scheduler described in [47]?
			- The bibliographic references need to be thoroughly checked. I selected [21-25] as a sample, and found issues in all of them:
			- The DOI link for [21] points to a different ICWS 2010 paper ("Formal Specification and Verification of Data-Centric Service Composition"). Please correct your link.
			- I could not find the paper [22]. I could not find any paper with that title in Google Scholar at all, and volume 2, issue 1 of the Journal of Cloud Computing does not mention it either: https://link.springer.com/journal/13677/volumes-and-issues/2-1.
			- The DOI link for [23] does not work (https://doi.org/10.1109/ICSS.2013.6550432). The correct DOI is 10.1109/ICSS.2013.13.
			- The DOI link for [24] points to a different CLOUD 2012 paper. I could not find a paper with this title in Google Scholar (""An approach for tenant placement in multi-tenant saas applications"). I could not find this paper among the CLOUD 2012 papers, either.
			- I could not find the paper [25]. I could not find any paper with that title ("Formal concept analysis for dynamic resource reconfiguration in energy-efficient cloud computing") in Google Scholar, the DOI link does not work, and the relevant volume and issue of the journal do not list any papers with "Formal" in the title: https://www-computer-org.libproxy.york.ac.uk/csdl/journal/cc/2023/02.
	- Reviewer 2 / REJECT
		- Dear authors,
		  thanks for your submission.
		  
		  Let me first start with the positive aspects of this submission.
		  The article is very interesting and has a well-defined goal: to minimize the energy consumption of cloud providers while satisfying SLAs and packing the maximum number of tenants while using the minimum number of servers. The approach makes use of an FCA formalization of the tenants and servers, and a set of algorithms for the consolidation and placement of tenants. The experimental Section 6 reveals how your FCA-based approach improves over a set of four related algorithms: the BFD, GA, vDRS, and RL. The comparison is well elaborated with a set of seven evaluation metrics, and results show how your FCA-based approach improves over the four alternative algorithms.
		  
		  Let me now discuss the negative aspects of this submission.
		  1) While the abstract and introduction refer to system modeling, this article does not find its best expression in the SOSYM magazine, in my opinion. Is FCA a model? Is this paper formally analyzing a model through model-based engineering techniques? Does FCA come with a metamodel?
		  
		  Let me first tell you that I had to do some deep reasoning and search on FCA before coming to this reflection. Based on my understanding and research, the FCA is a mathematical framework, grounded in lattice theory, for discovering and representing conceptual structures from data. It organizes objects and attributes into hierarchical "concepts" that reveal commonalities, facilitating knowledge discovery across different contexts. Therefore, the paper employs a mathematical model and algorithms built upon it to address an energy efficiency problem. I could not see "theoretical foundations of modeling languages and techniques", nor a model-based or model-driven approach to solve the identified problem.
		  Therefore, I honestly believe that other journals may provide a better fit with the identified solution.
		  
		  2) The FCA-based approach works under a number of assumptions, initially defined in Section 1.4, eventually discussed in Section 7.2, and with directions for future improvement analysed in Section 7.3. Overall, this is a concern, partially compensated for by the evaluation performed in Section 6. What I would need, however, is for the authors to clarify whether the comparative approaches also suffer from the same limitations/assumptions or not.
		  
		  3) There are a number of presentation and conceptual mistakes to be fixed or clarified.
		- Section 5.1 concludes with "The migration process operates systematically by:", then, Section 5.2 starts! The text on page 21 seems to be a continuation of Section 5.1, rather than a new Section 5.2.
		- Section 5.3: please fix the references to algorithms.
		- Section 5.4: it is incomplete.
		- Section 6.1: the decision to consider up to 500 tenants per server is justified. However, why consider resource vectors with a value between 100 and 500 units?
		- Section 6.2.1: please remove lines 12-32, since they are overlooked by Section 6.2.1. It appears that the current Section 6.2 is an outdated version of Section 6.2.1. Could you also provide a better justification for why the four selected algorithms represent the most common and advanced strategies?
		- Starting from Section 6.3, figures appear very far away from the text that cites them. Moreover, for some strange editing reasons, Figure x+1 is cited before Figure x, and this requires jumping a few pages ahead for searching the referenced figure.
		- A replication package for the conducted experiments is missing.
		- Section 6.3.3: in line 44, you report that the FCA-based approach is "superior to the greedy BFD approach". What do you mean by superior? Figure 15 clearly reports that the BFD approach is subject to fewer violations than the FCA-based approach.
		- Figures 16 and 17 are useless, since they are already included in Table 8.
		- Section 7: references are missing in both Figures and Tables.
		- Table 1 makes an interesting summary of tenant/VM placement approaches in cloud computing. The related text, however, shall quantify the "computational overhead of metaheuristics or the myopia of simple heuristics".
		- Formula 1 on page 13 reports that the objective of the proposed approach is to minimize the amount of server resources. This is true; however, the formula shall also make it visible the need to maximize the number of tenants on the minimum number of servers. It seems this part is missing from the formula.
		- Typo: page 14, line 35, it shall be "recall" rather than "reacll"
		- Typo: page 26, line 31, it shall be "Table 3" rather than "Table 2".
		  
		  OVERALL:
		  An interesting article that is, in my opinion, better suited for a different journal and requires some polishing.
	- Reviewer 3 / REJECT
		- The paper proposes a model-driven approach to address energy inefficiencies in multi-tenant cloud data centers caused by resource fragmentation and inter-tenant interference. The authors introduce a methodology using Formal Concept Analysis (FCA) to systematically identify semantic dependencies between tenants based on shared application usage, constructing a concept lattice to guide tenant grouping. Two core algorithms, the Algorithm for Placement of Tenants (APT) and the Algorithm for Consolidation of Tenants (ACT), are developed to leverage this lattice for optimizing resource utilization and minimizing network traffic. The approach is evaluated via simulation using CloudSim Plus, with results reporting significant reductions in active servers and energy consumption compared to baselines such as Best-Fit Decreasing and Genetic Algorithms.
		  
		  *Strengths*
		  
		  The application of FCA to the domain of cloud resource management represents a novel theoretical contribution, offering a structured method for visualizing and grouping hidden tenant-application relationships. The work addresses a relevant problem—energy efficiency in data centers—by considering both the consolidation of active servers and the reduction of network traffic overhead. The comparative analysis is broad, evaluating the proposed method against a diverse set of baselines including greedy heuristics, metaheuristics, and Reinforcement Learning agents. The paper is easy to read and follow.
		  
		  *Weaknesses*
		- The methodology relies on the assumption that the cloud provider possesses granular visibility into the specific application instances invoked by each tenant. This premise appears difficult to reconcile with standard IaaS environments, where providers typically manage Virtual Machines as "black boxes" and lack visibility into internal user-level application logic required to construct the proposed formal context.
		- The proposed model appears to suffer from ambiguity regarding the underlying cloud service model, as it lacks a clear concept of an "application provider." If interpreted within an IaaS/PaaS context where tenants deploy their own applications, the model allows application instances to share the same VM without addressing necessary isolation or ownership constraints. Conversely, if interpreted as a SaaS model where the provider owns the applications, the reliance on IaaS-centric metrics such as VM sizing and server capacity seems conceptually mismatched with the operation of identifying and migrating individual tenants.
		- The hypothesis that grouping tenants based on shared application usage minimizes inter-server network communication rests on the debatable assumption that these tenants communicate directly with one another. In typical web-based architectures, tenants usually communicate with the application instance rather than with peer tenants; therefore, co-locating tenants on the same server without explicitly ensuring the application instance itself is also resident on that node would likely yield negligible reductions in network traffic.
		- The model explicitly assumes that the formal context linking tenants to applications is "stable enough". This assumption may not align with modern cloud environments where autoscaling makes application instances ephemeral. The proposed lattice-based approach does not appear to account for the computational overhead or mechanism required to handle dynamic instance creation and destruction without frequent, potentially expensive re-computation of the concept lattice.
		- The evaluation relies exclusively on randomly generated synthetic workloads rather than validated industry traces. This threatens the robustness of the reported efficiency gains when subjected to the complex, bursty, and non-uniform traffic patterns typical of production cloud environments.
		- The validation is conducted solely within a simulation environment without implementation on a physical testbed. Consequently, the study may not fully account for real-world operational overheads, such as actual migration latency, network contention, and the energy cost of the lattice computation itself, which are acknowledged as limitations but not quantified.
		- The evaluation of the algorithm's scalability appears limited by the restricted scope of the experimental setup, which utilizes only 10 application instances. Since FCA lattice construction can exhibit exponential complexity as the number of attributes increases, testing with such a small attribute space may mask potential "attribute explosion" issues that could render the approach computationally infeasible in real-world scenarios involving thousands of distinct applications.
		- The reliance on a synthetic dataset with a high ratio of tenants (1,000) to application instances (10) may introduce bias into the results. This configuration forces an artificially high degree of overlap and dependency between tenants, likely creating dense clusters that favor the FCA algorithm, which might not be replicable in sparse, real-world datasets where tenant dependencies are less frequent.
		  
		  * Minor points*
		- The presentation of the paper's contributions, specifically the claim of introducing "A Novel Modeling Formalism," appears slightly imprecise. As Formal Concept Analysis is a well-established mathematical framework introduced in the 1980s, the contribution lies in the novel application of this technique to the domain of cloud tenant placement rather than the invention of the formalism itself.
		- The inclusion of an extensive background section detailing fundamental cloud computing concepts and service models (IaaS, PaaS, SaaS) seems superfluous for a specialized modeling audience in 2026. This space could be better utilized to elaborate on the specific complexities of multi-tenant resource management, as general cloud definitions are now considered common knowledge within the field.
		- There appears to be an inconsistency between the model's theoretical assumptions and the experimental setup. While the assumptions section explicitly lists "homogeneous servers" as a key constraint, the experimental configuration describes the use of servers with randomly generated capacities, complicating the assessment of how the baselines (such as Best-Fit Decreasing) performed relative to the proposed method.
		  
		  Overall, to strengthen the paper, the authors should clearly position the work in a precise cloud model (e.g., SaaS vs. IaaS) and clarify the role and ownership of applications, provide at least one concrete use case to make the assumptions and dependencies understandable, discuss in a realistic way how the approach copes with autoscaling and dynamic environments, better justify why the experimental setup reflects real-world conditions, and explicitly analyze the scalability and overhead of building and maintaining the FCA lattice as the number of applications and tenants grows.