Lost in decentralization? Governing emerging technologies within enterprise architecture

Local versus enterprise-level optimization

First, the literature shows a fundamental tension between local optimization (solving a specific unit’s problem quickly) and global optimization (improving the effectiveness of the entire enterprise in the longer term) (Beese et al., 2023b; Schilling et al., 2018, 2019). Local development teams tend to prefer specialized IS solutions that fit their specific needs, at the risk of creating application silos that do not align with enterprise-wide goals (Boh and Yellin, 2006). Decentralized software development through LCDPs—where decision rights are distributed to local entities, such as end-users—enhances this challenge because it empowers business units or departments to develop applications that prioritize their immediate localized needs over long-term enterprise-level interests (Malaurent and Avison, 2016).

Architectural drift and technical debt

When the balance between local and enterprise-level interests is threatened, a consequence of LCDP use can be architectural drift: “the movement away from a chosen architectural direction based on external influences” (Perks and Beveridge, 2003: 402). In other words, architectural drift refers to a state in which the evolution of an architecture diverges from the agreed-upon policies and principles. Although this is a well-known phenomenon in EAM, LCDP use can amplify this challenge when the prioritization of citizen developers’ interests over the overarching architectural plan leads to compromises, errors, lapses, and omissions in the design and implementation of IS that introduce architectural inconsistencies and unwarranted dependencies.

Applications created by end-users frequently lack documentation, consistent patterns, or maintainability considerations (Barricelli et al., 2019). This means that these applications can contribute to the organization’s technical debt. Technical debt refers to choices made early in the development process that are expedient in the short term, but that defer various costs (for refactoring, improvement, maintenance, etc.) “down the line,” essentially meaning that the same work will cost more to do later than it would in the early stages of development (Kruchten et al., 2013). Ultimately, this negatively influences efficiency, transparency, predictability and flexibility of the architecture (Rinta-Kahila et al., 2023). Citizen developers can perceive enterprise standards as an “extra burden” or a cumbersome barrier to project progress (Cram et al., 2015; Schilling et al., 2018), choosing to bypass these standards at the cost of the enterprise-wide perspective and creating misalignments that must be reconciled later (Gregory et al., 2018).

Escalating architectural complexity

Prioritizing local interests over enterprise-level goals and the resulting architectural drift can lead to an overly complex, inflexible and costly IS landscape (Tamm et al., 2022). Divergence from EA artifacts can lead to a rapidly increasing number of and diversity in applications, as well as (partial) overlaps between them. This can create an unmanageable level of complexity, which negatively influences each of the architectural outcomes (Beese et al., 2023b). Decentralized software development through LCDPs makes this “waning of the initial system architecture” (Schmidt and Buxmann, 2011: 170) more likely. When local units can rapidly build solutions to address immediate challenges or opportunities, this creates high levels of IS heterogeneity and redundant systems (Ahlemann et al., 2021; Haki et al., 2020). Likewise, at the level of the data architecture, decentralized development can lead to information silos where incompatible data formats and standards are adopted by different units to serve their own local applications, rather than integrating these with enterprise-level sources (Ajer et al., 2021; Boh and Yellin, 2006; Haki and Legner, 2021).

At the same time, the principle of requisite complexity holds that every system should contain a minimum level of complexity to deal with requirements stemming from the system’s environment (Boisot and McKelvey, 2011). When EA principles are maintained too strictly, this may lead to restrictions that limit EA complexity to a level that is not in line with this principle. This, in turn, may be a reason for users to develop applications that do serve their needs in terms of meeting complexity, but violate formal EAM principles.

Operational and security risks

Decentralized software development can threaten operational continuity (Van der Raadt et al., 2010). Inadequate decisions at the local project level can raise costs and complicate the implementation of necessary changes, potentially threatening the viability of the whole organization (Schmidt and Buxmann, 2011). Furthermore, the previously identified challenges in terms of complexity, drift and technical debt each negatively influence the transparency and predictability of the architecture, making it very difficult to foresee the unintended effects that a change to one component might have on related system components (Beese et al., 2023a).

Specifically, an increasingly important challenge for EAM resulting from the rise of decentralized software development concerns security. A fundamental risk here is the erosion of compliance, a core EA metaprinciple to ensure conformance to both internal standards and external regulations (e.g., GDPR, NIS2, and financial reporting rules) (Haki and Legner, 2021). Rapid, local development often evades formal compliance assessments or architectural quality gates (Gregory et al., 2018). Furthermore, when non-experts build applications, they may inadvertently violate privacy laws, security mandates or other guardrails (Ajer et al., 2021). The previously mentioned escalation of architectural complexity also presents a security risk, as “complexity is the enemy of security”: a complex systems landscape means more modules and connections (not all of them known or sanctioned), more potential software bugs, and on the whole an increased (and more difficult to comprehend) attack surface (Schneier and Vance, 2025).

Erosion of centralized top-down governance

Fundamentally, increasing decentralization of software development leads to an erosion of centralized EA governance. Ahlemann et al. (2021) identify EA Governance as one of four EAM capabilities, next to EA modelling, EA planning, and EA implementation. This capability focuses on developing EA-related decision rights and accountabilities, ensuring that EA development is in line with long-term objectives and not compromised by opportunistic decision-making (Ahlemann et al., 2021: 7). EA Governance is a control function aimed at steering EAM and facilitating monitoring, reporting and escalation.

The distinction between centralized and decentralized approaches towards governance relates to a difference in terms of locus of control (where decision-making power resides, either in a single person or small group or distributed across lower levels). Centralized governance means that architectural plans and policies, decision rights and accountability structures originate at the senior leadership level and are imposed on lower levels of the organization (Schilling et al., 2018; Weill and Ross, 2004). This is traditionally how this control function is shaped, relying on coercive mechanisms like standards and principles to ensure enterprise-wide alignment (Ahlemann et al., 2021; Haki et al., 2020; Schilling et al., 2018). End-user development challenges this reliance because local entities often perceive such coercive mechanisms as an unwelcome restriction of their design freedom (Beese et al., 2023b). Furthermore, the typical speed of user development (especially in the age of LCDPs and AI) makes it difficult to enforce compliance assessments or quality gates intended to ensure solutions fit the long-term target architecture (Ahlemann et al., 2021; Boh and Yellin, 2006). Thus, end user development would favor a more decentralized approach, where the architecture is primarily influenced by the actions and decisions of lower-level agents, aggregating upward without being designed from above (De Haes and Van Grembergen, 2009; Gregory et al., 2018). This approach assumes that effective governance often emerges from practice rather than being designed from above (Ciborra, 1994, 2000).

Phase 1: Template coding

We began with an a priori coding template derived from the synthesis of prior literature and our EA governance lens distinguishing between what to govern (EA activities, artifacts, and applications), who to govern (actors, their roles and decision rights), and how to govern (centralized and decentralized approaches). We applied these codes deductively to all interview transcripts and secondary sources within our case database to ensure systematic capture of theoretically salient issues (e.g., standards compliance, decision rights, and shadow IT risk). Table 3 summarizes the deductive template and examples; the full codebook is provided in Appendix C.

OPEN IN VIEWER

Table 3.

Overview of deductive coding (incl. anchors in literature, description, and exemplary quotes).

Code	Description	Exemplary quote
WHAT_Architectural Drift & Shadow IT	Citizen-built apps emerging outside established guardrails, expanding shadow IT and driving architectural drift, the movement away from a chosen architectural direction (Perks and Beveridge, 2003)—as local optimization needs prevail over enterprise coherence (Beese et al., 2023b; Fischer et al., 2017; Gregory et al., 2018).	“We’ve experienced significant challenges with shadow IT… Excel and Access… Mendix applications followed a similar pattern…”
WHAT_ Technical Debt & Escalating Complexity	Portfolio growth and heterogeneous development practices increasing technical debt—expedient short-term choices that defer future rework costs (Kruchten et al., 2013)—and driving IS landscape complexity that negatively influences efficiency, transparency, predictability, and flexibility of the architecture (Beese et al., 2023b; Rinta-Kahila et al., 2023; Tamm et al., 2022).	“Every additional Mendix app increases complexity…” (M6); “Technical debt has become a major concern… nobody adequately documents their apps.”
WHAT_Operational & Security Risk	Non-expert development threatening operational continuity and eroding compliance with internal standards and external regulations such as GDPR and NIS2 (Ajer et al., 2021; Haki and Legner, 2021; Van der Raadt et al., 2010). Architectural complexity further expands the security attack surface, as “complexity is the enemy of security,” creating more modules, connections, and potential vulnerabilities (Schmidt and Buxmann, 2011; Schneier and Vance, 2025).	“We discovered significant security vulnerabilities because Mendix applications were often released without thorough security evaluations.”
WHO_ Role Ambiguity & Decision Rights	Ambiguity in ownership and decision rights across the LCDP lifecycle among EA/IT, business units, and citizen developers, creating unclear accountability structures that stall decisions and invite opportunistic development choices (Ahlemann et al., 2021; Gregory et al., 2018; Weill and Ross, 2004).	“There is confusion about who owns governance now… where does our responsibility stop, and theirs start?”
WHO_Coordination & Stakeholder Function	Friction between business units, IT, and citizen developers over authority and accountability, generating coordination costs, rework, and resistance to governance requirements (Beese et al., 2023b; Galbraith, 1973; Gregory et al., 2018).	“Constant conflicts arise about who has authority… IT sees itself responsible… citizen developers feel ownership.”
HOW_Governance Balance (Centralized–Decentralized)	Calibrating governance by pairing codified standards, risk tiers, and proportionate gates with participatory enablement (peer review, communities of practice) so that architectural integrity is protected without sacrificing agility. When developers perceive governance as legitimate and supportive rather than coercive, compliance improves and workarounds decline (Beese et al., 2023b; Gregory et al., 2018; Tiwana et al., 2013).	“Our refined governance approach combines clear, formal standards and periodic compliance audits with informal elements like peer reviews and developer communities. This carefully managed balance maintains architectural integrity without hindering developers’ agility or creativity.”
HOW_Risk-Tiering & Proportionate Control	Proportionate governance that scales assurance depth with business and technical risk: lightweight checks for prototypes and low-impact departmental tools, and deeper, multi-party review for enterprise-critical changes, with periodic recalibration based on incidents and usage signals (Gregory et al., 2018; Tiwana et al., 2013; Weill and Ross, 2004).	“We classify solutions into tiers, prototype, departmental, and enterprise-critical, and the gates scale with impact. Low-risk items ship with a checklist and automated tests; high-risk changes go through security and architecture review. We revisit tier assignments after incidents and adjust the thresholds if needed.”

Phase 2: Inductive refinement

We then iteratively expanded and refined the codebook by introducing emergent subcodes when data did not fit existing template categories. For instance, while we began with the concept of “shadow IT,” interviews revealed nuances such as varying perceptions of “distributed compliance” and unanticipated forms of “project ownership” that did not entirely align with our initial template. Table 4 provides illustrative examples of emergent codes; additional emergent subcodes are documented in Appendix C. This abductive process supported theory elaboration while maintaining traceability to both prior concepts and empirical material.

OPEN IN VIEWER

Table 4.

Examples of emergent codes (incl. description and exemplary quotes).

Emergent code	Description	Exemplary quote	Maps to
Distributed Compliance	Indicates that, rather than a single centralized compliance approach, different departments ended up managing their own regulatory checks-challenging the initial “shadow IT” concept.	“In our company, every department managed its own compliance checks instead of relying solely on central IT – this decentralized approach was unexpected but proved beneficial.”	How (participation), Who (roles)
Project Ownership	Evolution from the assumption that IT would solely own projects to a model where business units also assume ownership, enhancing innovation and accountability.	“Initially, we assumed IT would own every project, but when business units started taking ownership, the outcomes improved dramatically.”	Who
Reframed Shadow IT	Reflects a nuance where what was initially labelled as “shadow IT” is reinterpreted as a source of organic, employee-led innovation once properly managed.	“What we once dismissed as shadow IT eventually turned into a hub of innovative ideas when teams were allowed to develop solutions independently.”	What
Enhanced Stakeholder Engagement	Highlights the emergent need for broad-based involvement-bringing non-technical voices into the conversation-to foster a more collaborative and agile integration process.	“Engaging non-technical staff early on broke down silos and led to a more inclusive, agile decision-making process that we hadn’t anticipated.”	Who and How

We then consolidated and refined the codebook by resolving overlaps and clarifying boundaries between closely related codes, while retaining case-specific subthemes captured through inductive refinement. Building on these refined codes, we developed within-case summaries and case memos that linked governance challenges to observed governance mechanisms and supporting evidence.

Phase 3: Within-case synthesis

For each case, we developed structured case memos and within-case summaries that linked (i) governance challenges, (ii) observed governance mechanisms and practices, and (iii) supporting evidence. In parallel, we coded contextual boundary conditions as case-level attributes (regulatory intensity, LCDP maturity, integration complexity, scale of citizen development; Table 1) to enable systematic cross-case comparison.

Phase 4: Cross-case comparison

We compared cases using matrices that contrasted governance challenges and “how-to-govern” mechanism portfolios across the boundary conditions in Table 1. This enabled assessment of literal replication across the three challenge domains (strategic, technical, operational) and theoretical replication in how governance mechanism portfolios varied under different contextual conditions. These comparisons informed the cross-case strategy clusters reported in the Findings section (Table 5).

OPEN IN VIEWER

Table 5.

Cross-case mapping of challenges to strategy clusters, concrete practices, and outcomes.

Dimension	Governance challenge	Strategy cluster [mechanism]	Governance practices and instruments	EAM outcomes
What to govern	Proliferation & shadow IT → architectural drift	Visibility & portfolio hygiene [Information symmetry]	Mandatory app registration; ownership & data metadata; periodic audits; portfolio rationalization (retire duplicates/obsoletes)	↑ transparency (portfolio visibility, lineage); ↑ predictability (audit readiness, data governance)
	Inconsistent practices → technical debt & maintainability risk	Engineering hygiene & reusable assets [Information symmetry]	Release criteria: docs as gate; reference architectures; secure templates; planned refactoring windows	↑ efficiency (↓ rework; ↑ reuse ratio); ↑ transparency (documentation baseline)
	Non-compliant releases → security exposure	Security-by-design & enablement [Secure-by-default conditions]	Risk-tiered pre-release checks (data classification, secrets, pen-test); env separation; developer training & checklists	↑ predictability (↓ critical vulnerabilities; ↑ policy-conformant releases); ↑ transparency (security posture)
Who to govern	Role ambiguity → unclear ownership & stalled decisions	Role redefinition & RACI [Enacted decision-right alignment]	RACI across LCDP lifecycle (ideate → retire); decision rights catalog; EA/IT shift gatekeeper → guide	↑ efficiency (↓ decision latency; ↓ escalations); ↑ predictability (clear accountabilities)
	BU/IT/citizen friction → coordination cost & rework	CoE & participatory governance [Perceived legitimacy + decision-right alignment]	CoE as integration hub; central intake/triage; participatory forums (standards backlog co-owned)	↑ flexibility (co-designed governance adapts to change); ↑ efficiency (↓ coordination cost & rework)
	Skill & literacy variability → execution risk	Capability building & permissioning [Developer capability]	Tiered curricula & badging linked to permission scopes; mentoring; enablement assets (patterns, connectors)	↑ efficiency (↑ quality at first review); ↑ predictability (↓ security/QA defects in novice apps)
How to govern	Over/under-formalization → lost agility or lost control	Balanced portfolio & risk-tiering [All five mechanisms]	Risk tiers mapping to control depth (prototype vs. core); lightweight gates for low-risk; periodic portfolio reviews	↑ flexibility (↑ cycle time for low-risk apps); ↑ efficiency (↑ conformance for high-risk); ↑ all four EAM outcomes
	Weak legitimacy & autonomy loss → bypass & superficial compliance	Transparent communication & exemplars [Perceived legitimacy]	Explain the why for each control; publish decision logs & exemplars; two-way feedback (policy revisions)	↑ flexibility (voluntary compliance supports agility); ↑ all four EAM outcomes (legitimacy ↓ workarounds)

Two researchers independently coded an initial subset of the data and reconciled differences through negotiated agreement, iteratively refining code definitions in a shared codebook and holding calibration meetings. To further strengthen robustness, we assessed inter-coder reliability on a stratified subset (two interviews per case; 286 meaning units/excerpts) that both researchers coded independently using the final codebook. Agreement was substantial (Cohen’s k = 0.73; Cohen, 1960; Landis and Koch, 1977). Remaining discrepancies were resolved through discussion and incorporated as minor refinements to the codebook (Appendix C).

To ensure interpretive rigor and trustworthiness, we adhered to several strategies (Lincoln and Guba, 1985). First, we conducted member-checking by sharing preliminary thematic summaries with key informants to confirm that our interpretations accurately reflected their experiences. Second, we periodically engaged in peer debriefings, reviewing segments of coded data and discussing potential biases or ambiguities in the coding scheme. Third, we maintained a transparent audit trail of coding iterations, memos, and analytical decisions in a shared repository, allowing us and other researchers to trace how final themes emerged from the raw data. Finally, we remained reflexive about our own positions as researchers, acknowledging subjective influences that might shape our interpretation of organizational actors’ accounts (Klein and Myers, 1999; Walsham, 2006).

LCDP adoption and use at FinComp

FinComp’s adoption of Mendix was a direct response to what respondents vividly described as an architectural “trauma”: the discovery of hundreds of unmanaged, end-user developed applications that had accumulated silently across the organization, creating serious regulatory exposure and data governance failures. Operating under high regulatory intensity and high integration complexity, the bank required a solution that would consolidate shadow development into a single, auditable environment. Mendix was selected because it met requirements for control, visibility and cloud-readiness. From the outset, governance emphasized proportionate control: every application is registered with minimal documentation, a Center of Excellence serves as a front door for triage, and standardized templates embed authentication and data-handling controls from the start.

“There’s a bit of a trauma because we had like hundreds of unmanaged IT end user developed applications and there were huge problems, and our regulators were really telling us: get a grip, get control.” (F1).

What makes FinComp analytically distinctive is its governance evolution from strict centralization to a federated model. An initial centralized, top-down approach, with a central team controlling all development and enforcing formal review boards, created distance from business units and ultimately undermined the flexibility that justified LCDP adoption. The organization responded by separating “enabling” from “delivery”: the central team retained responsibility for the platform, toolchain, and guardrails, while development ownership shifted to business-facing teams. This federated approach also gradually opened space for citizen developers in a tightly regulated capacity, a notable evolution given that citizen development had originally been formally prohibited. FinComp thus illustrates how governance models must adapt iteratively, and how explicit delineation of responsibilities allows formal control and federated autonomy to coexist.

LCDP adoption and use at HealthComp

HealthComp adopted Mendix primarily to address a resource constraint: growing demand for specialized clinical applications clashed with a persistent developer shortage, forcing departments to rely on improvised Excel and scripting tools that introduced security and integration risks. The platform was scoped to campus service and non-critical workflows, with mission-critical clinical systems retained on traditional pro-code paths (i.e., conventionally programmed systems developed by professional software engineers). HealthComp’s trajectory is analytically distinctive because of a partial reversal: the Mendix footprint shrank from roughly 70 to 40% of new applications as currency fluctuations inflated licensing costs and eroded the platform’s cost-effectiveness rationale, making HealthComp a case in which external economic pressures forced explicit governance recalibration.

“We faced a unique combination of increasing demand for specialized, department-specific applications, alongside very limited in-house developer capacity. Our main EHR system wasn’t designed to manage every specialized or unique workflow that individual departments needed. As a result, departments often relied on improvised solutions, typically using Excel or rudimentary scripting, which posed significant security and data integration risks.” (H9).

Governance at HealthComp evolved through a CoE-led participatory model that gradually drew citizen developers (e.g., nurse managers and senior administrative coordinators) into review and standards discussions. This participatory dynamic is the case’s principal analytical contribution: as citizen developers moved from passive rule-followers to active co-designers of governance standards, compliance improved and resistance diminished. HealthComp demonstrates how participatory governance can shift the perceived legitimacy of controls from externally imposed requirements to collaboratively developed guidelines, even in a resource-constrained and heavily regulated context where overall LCDP adoption remained mixed.

LCDP adoption and use at ManuCorp

ManuCorp’s adoption of Mendix in 2021 was simultaneously top-down and bottom-up: a corporate “digital acceleration” directive aligned with strong demand from business units seeking to replace shop-floor Excel and paper workflows with digital applications. This dual momentum produced the most extensive LCDP community among the three cases—over 500 employees across corporate IT, operations IT, factory-level teams, and regional sites—spanning use cases from small workflow replacements to larger supply chain management solutions. The breadth and geographic heterogeneity of this community, crossing multiple divisions and geographies, made coordination the central governance challenge.

“One of the most significant hurdles was aligning the pace of innovation inherent in Mendix with our established enterprise processes. While Mendix allows for rapid prototyping and agile iterations, our legacy systems and internal governance models often operate on a slower timeline. This disconnect necessitated a delicate balance between speed and stability.” (M7).

ManuCorp’s key analytical contribution is a concrete instantiation of multi-tier governance at scale. The organization constructed a layered structure combining a central competence center for intake and triage, an EA board for architectural review of higher-risk designs, and regional “Mendix champions” who provided first-line support and local governance at the plant and country level. This approach resolved a coordination problem that neither purely centralized nor purely decentralized models could address: champions absorbed routine governance friction locally, maintained alignment between local practice and enterprise standards, and escalated only genuine exceptions. ManuCorp therefore illustrates how decentralized governance roles can be institutionalized to sustain architectural coherence as LCDP adoption scales across geographies and divisions.

Challenges

The introduction of LCDPs into enterprise environments generated governance challenges that cut across all three dimensions identified in prior literature: what is governed, who governs, and how governance is enacted (Gregory et al., 2018; Tiwana et al., 2013), Left unaddressed, these challenges erode the four architectural outcomes of EAM; efficiency, flexibility, transparency and predictability (Beese et al., 2023a). The following sub-sections trace each dimension as it emerged across the three cases.

What to govern: Proliferation, architectural drift, and security exposure

Across the three organizations studied, a predominant challenge was the widespread proliferation of decentralized, citizen-developed applications. Such applications frequently emerged outside established governance boundaries, generating an extensive landscape of shadow IT and leading to significant architectural divergence. A Product Owner at FinComp clearly illustrated the seriousness of this issue:

“We’ve experienced significant challenges with shadow IT previously; people often built solutions using Excel and Access without our knowledge or control. Mendix applications followed a similar pattern, complicating our ability to ensure centralized governance and compliance.” (F1)

This proliferation intensified existing architectural complexity and strained governance processes as portfolios grew and organizations faced escalating difficulties managing their IT ecosystems. Reflecting on this, an enterprise architect from ManuCorp succinctly noted:

“Every additional Mendix app increases complexity, making our governance processes increasingly challenging.” (M6)

Compounding these pressures, heterogeneous and inconsistent development practices and inadequate documentation drove the accumulation of technical debt, impacting long-term maintainability and amplifying operational inefficiencies. Describing this challenge from a practical standpoint, a systems analyst at HealthComp emphasized:

“Technical debt has become a major concern because nobody adequately documents their apps. Eventually, this turns into a maintenance nightmare.” (H5)

Third, security exposure rose as citizen-developed applications were deployed and released without fully adhering to established security standards and protocols. This practice substantially increased organizations’ vulnerability to security threats. Highlighting the criticality of these risks, a senior product owner at ManuCorp explained:

“We discovered significant security vulnerabilities because Mendix applications were often released without thorough security evaluations.” (M1)

The question of what to govern was further complicated by the breadth and heterogeneity of the application portfolios citizen developers assembled. Governance boundaries could not simply be drawn around high-risk systems; they had to extend to everyday workflow tools that, taken together, constituted the bulk of the portfolio. A professional developer at ManuCorp described the scope:

“I think one major example is they have an Excel solution currently and they want to get rid of that Excel solution or paper and pen in the shop floor. I think that makes up to 80 or 90% of the applications our citizen developers are developing. And beside that, we have some bigger applications regarding supply chain management and stuff like that.” (M3).

Who to govern: Role ambiguity, coordination friction, and capability variability

The introduction and widespread adoption of LCDPs also altered organizational stakeholder dynamics by elevating citizen developers as influential actors alongside traditional EA and IT functions. This shift disrupted existing role partitions and created ambiguity regarding ownership, decision rights and limits of authority. A senior enterprise architect at FinComp illustrated the depth of this challenge clearly:

“There is confusion about who owns governance now. Citizen developers create their apps independently, and suddenly, we have to decide—where does our responsibility stop, and theirs start? It’s becoming a significant source of tension internally.” (F8)

Role ambiguity frequently led to coordination and alignment challenges among key stakeholder groups, especially between business units, traditional IT departments, and the emerging citizen developer community. Differences in decision-making authority and ongoing conflicts over accountability created consistent organizational friction. An IT Manager at HealthComp clearly described the practical implications of these coordination challenges:

“Constant conflicts arise about who has authority over citizen-developed applications. Business stakeholders often think it’s their call; IT sees itself responsible for infrastructure and risk, and citizen developers typically feel ownership over their solutions.” (H6)

Coordination friction also extended to resource allocation decisions that spanned functional and financial boundaries. At ManuCorp, governance responsibilities cut across operations and finance, requiring negotiated arrangements rather than unilateral authority:

“Finance was alarmed by potential license cost overruns while operations wanted to deploy ten new apps across factories. We negotiated a partial cost-sharing model: once usage hits a threshold, that division covers part of the incremental license. Showing how the apps freed up scarce developer time helped ease the tension and let operations proceed.” (M9).

Additionally, governance effectiveness suffered due to wide variability in citizen developer competence and governance literacy. These developers constituted a diverse stakeholder group with varied professional backgrounds, inconsistent technical proficiency, and differing levels of understanding regarding governance requirements. Such variability increased complexity when organizations attempted to standardize governance practices, further intensifying organizational risks, especially related to security and regulatory compliance. An EA specialist at ManuCorp highlighted this challenge clearly:

“Citizen developers range widely in their technical skills and understanding of governance. Some adapt quickly and become effective developers; others continuously struggle, and that inconsistency creates risks that are difficult for us to manage consistently.” (M4)

How to govern: Calibrating formal and informal control

A central challenge across all three cases was finding an effective balance between centralized, top-down control and decentralized, bottom-up enabling approaches. Across all examined cases, organizations consistently encountered significant challenges in establishing this balance. Approaches that were either overly centralized or insufficiently structured resulted in distinct but equally problematic outcomes.

The studied organizations initially emphasized centralized governance instruments such as stringent compliance requirements, detailed documentation, and centralized oversight. However, they quickly realized that these rigid control structures undermined the innovation and agility promised by LCDPs. Citizen developers, whose primary motivation was rapid innovation, often perceived top-down governance mandates as overly bureaucratic and obstructive, leading to frustration and reduced productivity. A domain architect at FinComp illustrated this challenge vividly:

“When our governance became too prescriptive, citizen developers felt discouraged. The process grew cumbersome, completely eroding the agility we initially sought through Mendix. On the other hand, reducing controls excessively led to a proliferation of unmanaged, redundant applications, significantly raising complexity and risks.” (F4)

Conversely, relying too heavily on decentralized, bottom-up approaches without sufficient structure created equally significant problems. Such approaches, while initially appealing due to the freedom they offered developers, frequently led to uncontrolled application proliferation. Such uncontrolled growth exacerbated architectural drift, dramatically increased technical debt, and heightened organizational exposure to security threats. A senior Enterprise Architect at ManuCorp summarized this unintended consequence clearly:

“Informal governance seemed attractive initially because it gave citizen developers freedom. However, without clearly defined standards or rules, we quickly faced severe issues: applications lacked consistency, documentation was ignored, and complexity rapidly became unmanageable.” (M9)

A further challenge was weak legitimacy; when communication was neither clear nor supportive, developers viewed governance mandates as arbitrary obstacles rather than necessary guidelines. These perceptions fostered resentment, undermined compliance, and severely diminished the effectiveness of governance initiatives. An IT Project Manager at HealthComp articulated this issue explicitly:

“Many developers did not understand the governance requirements or their importance. To us, governance felt like unnecessary bureaucracy rather than meaningful oversight. Consequently, compliance became minimal or superficial, and developers often bypassed rules altogether.” (H10)

Relatedly, perceptions of loss of autonomy under top-down control structures diminished citizen developers’ intrinsic motivation, creativity, and overall job satisfaction; turning potential innovators into passive participants or even active resistors. An IT Manager at ManuCorp described the impact:

“Developers felt their creativity was curtailed. Instead of innovating, they became passive and disengaged. Governance should empower developers, but under our centralized approach, this message was not effectively conveyed.” (M7)

In conclusion, our cross-case analysis identifies LCDP-related EA governance challenges that span three intertwined dimensions: what is governed (proliferation, technical debt, and security exposure), who is involved (role ambiguity, coordination friction, and capability variability), and how governance is enacted (balancing centralized, top-down control with decentralized, bottom-up enablement, and building legitimacy for governance mandates). Together, these challenges (if left unattended) negatively affect each of the architectural outcomes identified in the literature (Beese et al., 2023a): efficiency is threatened by redundancy and technical debt, flexibility by over-centralization, transparency by shadow IT and portfolio opacity, and predictability by security vulnerabilities and unchecked architectural drift.

Strategies

Table 5 provides an overview of the strategic responses to these challenges we found across the different case studies, organized according to the following concepts:

- The governance dimension to which the strategic response pertains (what, who, or how);

Across cases, we observed that the effectiveness of governance initiatives designed specifically to manage and mitigate challenges resulting from LCDP use did not hinge on control alone or enablement alone. Rather, effective governance encompassed portfolios in which formal structures, rules and gates were deliberately paired with informal coaching, participation, and community routines. Together, these clusters establish the balance that allows organizations to protect architectural integrity and regulatory conformity while sustaining the speed and local initiative that drive value from low-code development.

Mechanisms

The strategy clusters described above, each comprising a set of governance instruments and enabling practices, do not work in isolation, nor do they produce improvements simply by being present. Something must connect the activation of a cluster to observable changes in organizational behavior and architectural outcomes. We refer to these connective processes as mechanisms: the causal structures that explain how a governance activity reliably generates a particular outcome. Following Henfridsson and Bygstad (2013: 911), a mechanism is not the practice itself but the generative logic through which the practice works. For instance, mandatory application registration is a practice within the visibility and portfolio hygiene cluster; the mechanism it activates is information symmetry, the condition in which architects, governance boards, and citizen developers share an accurate, current picture of the application landscape. It is that condition, not the registration act alone, that enables reuse, reduces drift, and supports risk-tiering decisions. Across the three cases, our data reveal five mechanisms through which the portfolio of strategies translates governance activity into improved EAM outcomes.

First, information symmetry and shared situational awareness emerge when mandatory registration, minimal documentation standards, and portfolio hygiene are paired with coaching and community demonstrations. These instruments and practices make the application landscape visible, clarify lineage, and enable reuse, directly addressing the proliferation and opacity challenges in the what dimension.

Second, the perceived legitimacy of governance increases when guardrails are transparent, proportionate, and shaped with user participation, and when a CoE provides timely advice and explains the rationale behind rules. Under such conditions, rules are experienced as reasonable and usable, which reduces resistance and workarounds, resolving the legitimacy challenges in the how dimension.

Third, developer capability grows when tiered learning pathways and permission scopes are tied to demonstrated competence and reinforced by hands-on application and the sharing of proven patterns. Capability is a proximal driver of first-time quality and governs the quality risk associated with citizen developer variability in the who dimension.

Fourth, enacted alignment of decision rights occurs when responsibilities across the low-code lifecycle are clearly codified and put into practice, reducing decision latency and the need for escalation. This mechanism directly resolves the role ambiguity and coordination friction challenges identified in the who dimension.

Fifth, secure-by-default development conditions arise when risk-tiered checks, environment separation, and policy-conformant pipelines are embedded in everyday work and supported by secure templates and targeted training. These conditions reduce severe vulnerabilities without imposing unnecessary delay, directly addressing the security and compliance challenges in the what dimension.

The five mechanisms are not independent but mutually reinforcing, elements of a single causal infrastructure. Information symmetry creates the shared situational awareness that makes legitimate rule-setting possible, guardrails experienced as proportionate and transparent depend on the visibility that registration and portfolio hygiene provide. Legitimacy, in turn, enables capability development: citizen developers engage seriously with learning pathways and permission structures only when governance is perceived as reasonable rather than obstructive. Capability reduces escalation load, which allows decision-right alignment to function efficiently. When developers can resolve issues at their own tier, the need for escalation to architects or governance boards diminishes. Finally, information symmetry completes the loop by making secure-by-default conditions operational: embedded pipeline checks and environment separation work as intended only when the application landscape is sufficiently visible and documented. It is through these interdependencies, not through any single instrument or practice in isolation, that the strategy portfolio produces durable improvements in EA outcomes. A portfolio that activates all five mechanisms simultaneously generates a governance dynamic that is qualitatively different from one that relies on any subset: the mechanisms amplify each other, and their joint activation is what distinguishes governance that sustains itself over time from governance that requires constant manual enforcement. The mechanisms are thus not merely correlates of governance effectiveness but the causal structures through which strategy clusters produce EA outcomes and because they are mutually reinforcing, activating the full portfolio generates a self-sustaining governance dynamic that no individual mechanism could achieve in isolation.

It is important to note that the centralized–decentralized and formal–informal dimensions of governance, while related, are analytically distinct. Centralized versus decentralized governance concerns the locus of control: centralized governance concentrates decision-making authority in a single unit or role—such as a Chief Architect or central EA office—while decentralized governance distributes authority across business units, project teams, or individual developers (Boh and Yellin, 2006; Gregory et al., 2018). Formal versus informal governance, by contrast, concerns the mode of control: formal control relies on explicit standards, performance evaluation, and hierarchical enforcement, whereas informal control originates from intrinsic motivation, self-regulation, and interpersonal interaction (Beese et al., 2023b; Ouchi, 1979). These two dimensions are orthogonal: a centralized governance model may employ informal mechanisms (as when a Chief Architect builds norms through coaching rather than mandates), and a decentralized model may use formal controls (as when distributed business units are each required to complete structured risk assessments). Our findings show that organizations responded to LCDP governance challenges not by choosing between these orientations but by composing portfolios that combined centralized instruments with informal enabling practices—a configuration our data suggest is distinctively effective for governing citizen development.