De-Siloing Enterprise HR Technology

By July 31, 2026Articles

De-Siloing Enterprise HR Technology: An Enterprise Architecture Approach to Peer-Driven, Asynchronous Knowledge Ecosystems in Cloud HCM Engineering

by Satish Chavali

Abstract

Enterprise cloud Human Capital Management (HCM) platforms require deep cross-module integration across HR, payroll, talent, and workforce analytics. Yet the engineering organizations that build these systems routinely suffer from communication silos that degrade both architectural coherence and deployment performance. This paper argues that Enterprise Architecture (EA) frameworks — specifically TOGAF’s Architecture Development Method (ADM), Team Topologies interaction modes, and Conway’s Law — provide the structural lens needed to diagnose and correct these dysfunctions. Drawing on Socio-Technical Systems (STS) theory, DevOps Research and Assessment (DORA) elite-performer research, and open-source governance models, we propose a three-component EA-aligned framework: democratic architectural forums modelled on the Request for Comments (RFC)/Architecture Decision Record (ADR) pattern, centralized asynchronous knowledge hubs as EA repositories, and structured cross-pollination networks informed by inner-sourcing. We contend that aligning the social architecture of HCM engineering organizations with EA principles is expected to reduce integration defects and accelerate deployment frequency, outcomes that cannot be achieved through top-down synchronous mandates alone.

Keywords: enterprise architecture; TOGAF; Conway’s Law; cloud HCM; socio-technical systems; asynchronous collaboration; microservices; DevOps; Team Topologies; knowledge management; inner-sourcing

1. Introduction

Cloud Human Capital Management platforms have become mission-critical infrastructure for large enterprises. These platforms manage employee lifecycle data for large portions of the global workforce [1,2], requiring engineering organizations to build and sustain deeply integrated, multi-module systems spanning core HR, talent acquisition, payroll, learning management, and workforce analytics [1,2].

The engineering challenge these platforms pose is qualitatively different from that of a single-product software company. Each module owns distinct data models, regulatory compliance requirements, and release cadences, yet must interoperate through shared APIs and common data schemas. In practice, engineering departments frequently operate within structural and communicative silos that surface directly in the quality and stability of the software they produce.

Enterprise Architecture offers a discipline-level response to this challenge. TOGAF’s Architecture Development Method (ADM) provides a governance cycle for managing architectural decisions across business, data, application, and technology domains [3]. Yet in cloud HCM organizations, EA is frequently applied only at the macro level (platform strategy, module roadmaps, vendor selection), leaving the day-to-day social and communication structures of engineering teams largely ungoverned by architectural thinking. This paper argues that EA frameworks, when applied to the social and organizational architecture of HCM engineering teams, can resolve the integration dysfunction that top-down coordination mechanisms fail to address.

2. The EA Problem: When Social Architecture Undermines Technical Architecture

Figure 1 — Conway’s Law: siloed communication mirrors into fragmented technical architecture

2.1 Conway’s Law as an EA Diagnostic

TOGAF’s ADM Phase B (Business Architecture) and Phase C (Information Systems Architecture) assume that communication structures within the enterprise will enable the architectural patterns being designed. Conway’s Law — the observation that organizations are constrained to produce designs that mirror their communication structures [4] — makes explicit the dependency that EA frameworks tend to leave implicit: *the social architecture of the engineering organization is itself an architectural artifact*.

In cloud HCM engineering, this manifests predictably. When teams are organized around module or product boundaries, the data models, APIs, and integration contracts they produce replicate those boundaries rather than the optimal technical topology. A core HR data master engine that should share data natively with payroll microservices and talent acquisition workflows instead communicates through brittle, loosely documented API bridges — each bridge a scar left by an organizational boundary to which TOGAF’s Phase C is rarely, if ever, applied.

Herbsleb and Grinter’s empirical research on distributed software development established that teams separated by organizational, geographical, or communicative distance produce components with significantly higher defect rates at integration boundaries than co-located, cross-functionally communicating teams [5]. In cloud HCM systems, these integration defect costs are directly visible to enterprise customers: payroll tax engines that fail to consume employee classification changes, talent platforms that cannot reflect HR record updates in real time, and workforce analytics dashboards that produce inconsistent headcount figures.

2.2 STS Theory and the Missing Social Architecture Layer

Socio-Technical Systems (STS) theory holds that technical systems achieve optimal performance only when their social and technical subsystems are jointly optimized [6,7]. TOGAF’s ADM addresses the technical architecture comprehensively, but organizations rarely apply the same rigor to designing the social systems through which architectural decisions are made, communicated, and enforced.

In cloud HCM engineering organizations, the social system is typically governed by a set of synchronous coordination mechanisms: Program Increment (PI) planning ceremonies, architecture review boards requiring multi-layer sign-off, and scheduled cross-team synchronization meetings. We contend that these mechanisms introduce meeting fatigue and may paradoxically reinforce the silos they seek to dissolve [9]. They are also architecturally counterproductive: they create information dependencies on specific individuals being present at specific moments, rather than encoding architectural knowledge in durable, searchable artifacts accessible to the full organization [14].

2.3 Technical Debt as an Architectural Consequence

The structural gaps between synchronous coordination and continuous engineering work produce a well-documented pattern of architectural technical debt. Upstream schema changes break downstream microservices. Emergency API wrappers are deployed to bridge incompatible data models. Hotfixes accumulate. Each remediation cycle consumes engineering capacity that could otherwise advance the platform’s technical capability.

The DORA (DevOps Research and Assessment) program’s longitudinal research establishes the organizational correlates of this dysfunction quantitatively. Organizations classified as low-performers on the DORA capability model, characterized by change approval processes requiring multiple layers of sign-off and infrequent deployment, showed deployment frequency dramatically lower than elite performers and mean time to restore service substantially longer, with differences measured in orders of magnitude (see Forsgren et al. [9] and State of DevOps reports [17]). Organizations exhibiting bureaucratic or pathological Westrum culture, characterized by siloed communication and high change-approval overhead, consistently cluster in low DORA performance tiers [9,16]. EA frameworks that govern only technical topology while leaving social communication ungoverned represent a significant governance gap.

3. Evidence from Adjacent Domains

3.1 Open-Source Governance Models

The open-source community has operated peer-driven, asynchronous architectural governance for decades. The RFC (Request for Comments) process originated in Internet standards governance and has since been widely adopted across open-source and engineering communities [10]. It allows any contributor to propose architectural changes through a structured written proposal, inviting asynchronous critique before a decision is reached. Architectural Decision Records (ADRs), which capture the context, decision, and consequences of each significant architectural choice, complement this process by creating a persistent, searchable audit trail that new contributors can consult [11].

RFCs and ADRs are directly analogous to the documentation outputs of TOGAF’s ADM. Where TOGAF produces Architecture Definition Documents, Architecture Requirements Specifications, and Architecture Decision records at the governance layer, RFCs and ADRs apply the same principle at the engineering team layer. This structural parallel is significant: it suggests that the RFC/ADR model is an extension of EA governance, not a departure from it into the daily practice of software engineering.

3.2 Team Topologies and Explicit Interaction Modes

Figure 2 — RFC/ADR governance sequence: democratic architectural forum in practice

Skelton and Pais’s Team Topologies framework provides a structural model for organizing software engineering teams that maps onto EA concerns about capability allocation and dependency management [12]. The framework distinguishes four team types — stream-aligned, platform, enabling, and complicated-subsystem — and three explicit interaction modes: collaboration, facilitation, and X-as-a-service.

Mapping cloud HCM engineering units onto the Team Topologies taxonomy produces immediate architectural clarity. Core HR record engines are complicated-subsystem teams. Payroll and localization services are stream-aligned teams consuming platform services. Shared API gateway and identity management components are platform teams. Integration teams bridging legacy on-premise HRIS systems to cloud modules occupy enabling team roles during migration transitions. Making these roles and interaction modes explicit — rather than leaving them to emerge organically from organizational reporting structures — directly addresses the architectural fragmentation problem that Conway’s Law predicts.

Team Topologies defines the *interface* between teams as an architectural decision that should be deliberately designed and documented, not left to informal negotiation. This is the gap that EA frameworks fill at the enterprise level: Team Topologies extends that discipline to the engineering team level.

4. An EA-Aligned Framework for Cloud HCM Engineering Organizations

To address these systemic bottlenecks, we propose a three-component framework informed by TOGAF’s ADM, Team Topologies, and open-source governance practice. Each component corresponds to a specific architectural governance gap.

The framework’s effective adoption depends on deliberate actions taken in the two ADM phases that precede the primary intervention points. TOGAF’s Preliminary Phase, the foundational phase for establishing EA capability, defines three prerequisites for the proposed framework. First, executive sponsorship: without a CTO- or VP-level mandate that asynchronous governance carries organizational authority equivalent to synchronous Architecture Review Board (ARB) decisions, RFC outcomes will be ignored and the forum will decay into an advisory body. Second, an EA operating model that explicitly includes engineering-layer governance as in-scope, not merely enterprise-level architectural guidance. Third, governance principles documented in TOGAF’s Architecture Principles catalog that authorize cross-module architectural proposals from any engineer [3]. Phase A (Architecture Vision) then performs the stakeholder alignment work that determines whether the social architecture transformation is organizationally viable. Phase A deliverables should be extended to include: a Statement of Architecture Work scoping the communication structure redesign; a stakeholder map identifying which module owners, ARB members, and engineering managers must be engaged before the RFC process launches; and a preliminary capability assessment establishing the current state of cross-module communication, including incident volume attributable to integration failures, ARB throughput and cycle time, and engineer survey data on knowledge-sharing friction. Without this baseline, adoption progress cannot be measured [3]. Figure 3 illustrates the full ADM phase sequence and maps each phase to the specific framework actions it enables. Phase D (Technology Architecture) is excluded because this framework targets social and organizational architecture; technology infrastructure is taken as a given at the enterprise platform level.

Figure 3 — TOGAF ADM: Full Phase Sequence for Social Architecture Framework Adoption (Preliminary through Phase H)

4.1 Democratic Architectural Forums (EA Governance at the Engineering Layer)

TOGAF’s Implementation Governance phase (ADM Phase G) defines processes for managing architectural changes, including impact assessment, compliance reviews, and decision escalation paths [3]. In large cloud HCM organizations, this governance layer is typically implemented through a central Architecture Review Board (ARB) that evaluates significant cross-module changes. The structural problem is that this board operates synchronously, requires senior representation, and creates a bottleneck that discourages the incremental, frequent API evolution that cloud platforms require.

The alternative is an internal RFC process modelled on open-source practice and operationalized within TOGAF’s governance structures. Under this model, any engineer can propose updates to data schemas, API contracts, or cross-module interface definitions by drafting a structured written proposal covering problem statement, proposed change, alternatives considered, and downstream impact assessment. A defined asynchronous review window of typically ten business days allows cross-functional engineers to critique and refine proposals without requiring synchronous attendance. The domain owner makes a final decision based on accumulated written feedback, not by consensus in a meeting; the ARB retains authority to escalate contentious decisions when cross-cutting architectural risk is identified.

ADRs formalize the outputs of this process: each significant architectural decision is recorded in a version-controlled document, linked to the RFC that produced it, and stored in the centralized knowledge hub. In cloud HCM organizations with high engineer turnover, ADRs are designed to reduce the re-litigation of previously settled design decisions and to provide new engineers with the architectural context they need to work effectively across module boundaries.

This model extends TOGAF’s governance structures to the engineering team layer rather than replacing them, ensuring that the Architecture Governance cycle operates continuously rather than episodically. In practice, the RFC lifecycle involves five stages: (1) Draft — the proposing engineer publishes the RFC and notifies affected module owners; (2) Open Review — a ten-business-day window during which any engineer may comment, request changes, or signal support; (3) Final Comment Period — a three-day window after the domain owner signals intent to decide; (4) Decision — the domain owner records the decision and rationale in the ADR, linked to the RFC; (5) Implementation Tracking — the ADR is updated with implementation status and linked to relevant pull requests. The five-stage lifecycle draws on open-source RFC practice and the ADR formalization approach established by Tyree and Akerman [11]. The ARB’s role transitions from a synchronous decision forum to an asynchronous quality assurance function, retaining authority to escalate contentious RFCs when cross-cutting architectural risk is identified.

4.2 Centralized Asynchronous Knowledge Hubs (EA Repository in Practice)

TOGAF’s ADM specifies an Architecture Repository as a structured store for architectural outputs: architectures held at Strategic, Segment, and Capability levels, alongside a Standards Information Base, Reference Library, and Governance Log [3]. In practice, large cloud HCM organizations maintain these at the platform or enterprise level, but the day-to-day integration knowledge that engineering teams need — dependency maps, schema versions, historical integration failure records, API change notifications — lives in synchronous channels: meeting recordings, private chat threads, and PI planning slide decks that are invisible to engineers who were not present at the moment of communication.

The operational principle we propose is an engineering-layer analogue to TOGAF’s Architecture Repository concept: all cross-team technical communication must exist in a durable, searchable, version-controlled form accessible to the full organization. This means schema changes are communicated through RFC documents, not verbal updates in stand-up meetings. Dependency maps are maintained as living documents in a shared knowledge hub (wiki or documentation platform), linked directly from the codebase. Historical integration failures are documented in postmortem records that inform future architectural decisions.

A well-structured knowledge hub should be organized into four content layers: (1) Architecture Layer — ADRs, RFCs, API contracts, and data schema definitions, version-controlled and cross-linked to the codebase; (2) Domain Knowledge Layer — module-level onboarding guides, integration pattern catalogs, and known failure mode libraries; (3) Process Layer — runbooks, incident post-mortems, and deployment procedures; (4) Cross-Pollination Layer — rotation notes, paired-engineering outputs, and inner-source contribution summaries. Access control should be read-open by default across all layers, with least-privilege write access and maximum read visibility. The key architectural insight is that information which exists only in a meeting recording or a private chat thread is architecturally invisible. It cannot be linked, searched, or reviewed by the engineer who needs it when a payroll microservice is failing in production at 02:00. Applying TOGAF’s Architecture Repository principle at the engineering layer can convert ephemeral social communication into durable architectural knowledge [14]: the outcome EA governance is designed to produce.

4.3 Structured Cross-Pollination Networks (EA-Informed Capability Development)

Figure 4 — Three-component EA framework: democratic forums, knowledge hub, cross-pollination

TOGAF’s Opportunities and Solutions and Migration Planning phases (ADM Phase E and F) explicitly address the organizational capabilities required to implement an architecture [3]. In cloud HCM engineering organizations, a persistent capability gap exists at the cross-domain level: engineers develop deep expertise within their own module and lack the vocabulary, context, and relationships to collaborate effectively with adjacent teams. This capability gap is an architectural constraint — it determines what integration patterns are practically feasible regardless of what the technical architecture specifies.

Structured cross-pollination programs address this gap. Fixed-term pairing rotations — matching, for example, a core HR record engineer with a talent management module designer for six to eight weeks to co-design a shared API or resolve a cross-module data consistency issue — build the cross-domain relationships and shared vocabulary that continuous integration requires. These pairings should be governed by the organization’s Capability Development roadmap, not left to individual initiative, to ensure systematic coverage of the cross-module dependency graph.

Inner-sourcing, defined as applying open-source contribution norms (pull requests, code review, issue tracking) to internal proprietary codebases, extends this principle beyond time-limited pairings [13]. When engineers from any module can submit pull requests to any other module’s codebase (subject to owner review and merge approval), knowledge flows continuously across team boundaries and module owners receive early visibility of the integration needs their consumers are trying to address. This is an architectural governance mechanism: it distributes architectural awareness across the organization rather than concentrating it in a small group of senior architects.

5. Discussion

Figure 5 — TOGAF ADM: Precondition vs. Intervention-Phase Distinction (Preliminary and Phase A as preconditions; Phases B, C, E–G as primary intervention points)

5.1 Participation Equity in Open Architectural Forums

Transitioning to peer-driven architectural governance introduces participation equity challenges that EA practitioners must address explicitly. Open forums can create disparities where less vocal engineers, non-native English speakers, or engineers from underrepresented groups find their contributions weighted inequitably against those of senior or more assertive colleagues. Organizations implementing democratic architectural forums should set clear norms for written rather than verbal critique, considering anonymized early-stage proposals where appropriate, and appointing rotating facilitation roles to surface contributions from engineers who do not self-promote. These are social architecture decisions — and like all architectural decisions, they should be explicitly documented and governed.

5.2 Tooling Choices and Implementation Realism

The framework proposed here is tooling-agnostic, but practical implementation requires deliberate platform choices. RFC and ADR workflows are well-supported by version-controlled documentation platforms and should be maintained alongside the codebase they document. Knowledge hub platforms should be evaluated against searchability, API accessibility for automated cross-linking with issue trackers and deployment pipelines, and access control granularity. Any new tooling must be accompanied by an explicit deprecation plan for the synchronous channels it replaces. Without this, engineers default to familiar synchronous habits and the asynchronous knowledge hub becomes a graveyard of outdated documentation — an architectural anti-pattern that undermines the governance outcomes the framework is designed to produce.

5.3 Legacy Integration Constraints

Applying EA-aligned social architecture frameworks cannot resolve all coordination constraints in cloud HCM environments. Many providers maintain integration bridges to legacy on-premise HRIS systems that enforce synchronous, batch-oriented data exchange patterns architecturally incompatible with event-driven microservice communication. These technical constraints bound what organizational change can achieve. Future work should examine how automated contract testing frameworks (such as Pact), machine-readable API specifications (OpenAPI), and static analysis and dependency scanning tools can identify cross-module dependency violations before they reach production — complementing the social architecture interventions proposed here and reducing the residual coordination overhead that legacy integration constraints impose.

5.4 Organizational Change Management Considerations

The framework proposed here introduces a substantive change to how engineering teams communicate, make decisions, and build shared knowledge. Introducing asynchronous democratic forums in place of synchronous Architecture Review Boards, or replacing informal knowledge-sharing with structured cross-pollination rotations, are not purely technical interventions — they require deliberate organizational change management (OCM). Practitioners should anticipate three categories of change impact.

First, role redefinition. Senior architects who currently hold gatekeeping authority in synchronous ARBs must transition to quality assurance, facilitation, and escalation roles within the asynchronous RFC process. Routine final decisions move to domain owners; ARB authority is reserved for contentious cross-cutting RFCs. This shift — from routine decision-making to stewardship and escalation — requires explicit role redesign, updated performance criteria, and in many cases, targeted coaching. Engineering managers must similarly recalibrate how they evaluate team contribution, rewarding written architectural engagement alongside delivery output.

Second, adoption sequencing. Organizations with entrenched synchronous coordination habits should not attempt simultaneous adoption of all three framework components. A phased approach — beginning with the knowledge hub as a low-resistance entry point, then piloting the RFC process in one module team, then scaling cross-pollination rotations — reduces adoption friction and allows the organization to build change capability incrementally. Note that this rollout sequence deliberately differs from the presentation order in §4: the knowledge hub is adopted first because it carries the lowest organizational resistance, not because it is architecturally primary. Each phase should include a retrospective checkpoint aligned with TOGAF’s ADM Phase H (Architecture Change Management) to assess adoption quality before proceeding.

Third, psychological safety. Edmondson’s research establishes that psychological safety is a significant predictor of team members voicing dissent and surfacing problems [8]. While Edmondson’s empirical base concerns synchronous co-located teams, the principle applies here by analogy: open critique forums are more likely to produce quality improvements when participants feel safe to challenge proposals without career risk. Organizations with low psychological safety baselines — common in hierarchical engineering cultures — should address this precondition before launching open RFC forums. Facilitated retrospectives, anonymous early-stage proposal periods, and visible leadership participation in the RFC process as contributors rather than arbiters are recommended practices for building the psychological safety that peer-driven governance requires to function as intended.

Figure 6 provides a phased adoption roadmap aligning each framework component to the ADM phase governing its introduction [3], the OCM actions required, and measurable success criteria. The phased sequencing approach draws on Kotter’s change management model [15], particularly the steps of building a guiding coalition (executive sponsorship), generating short-term wins (knowledge hub pilot), and consolidating gains to scale RFC governance organization-wide.

Figure 6 — OCM phased adoption roadmap aligned to TOGAF ADM

6. Conclusion

Enterprise Architecture frameworks provide a powerful diagnostic and design language for addressing the communication dysfunctions that degrade integration quality in cloud HCM engineering organizations. Conway’s Law, read through the lens of TOGAF’s ADM, reveals that the social communication structure of an engineering organization is itself an architectural artifact — one that determines what technical architectures are practically achievable and what integration defect rates are structurally inevitable.

The three-component framework proposed here — democratic architectural forums extending TOGAF governance to the engineering layer, centralized asynchronous knowledge hubs operationalizing the TOGAF Architecture Repository principle, and structured cross-pollination networks addressing EA capability gaps — offers a practitioner-oriented model for engineering leaders seeking to align social and technical system design in cloud HR technology organizations.

The evidence base from open-source governance, DORA longitudinal research, and Team Topologies provides strong conceptual support for this direction. What remains is empirical evaluation within production cloud HCM engineering environments: controlled studies measuring deployment frequency, lead time for changes, change failure rate, and mean time to restore before and after adoption of each framework component. The model proposed here offers a starting point for that research program, grounded in established EA principles and informed by evidence from adjacent domains.

Declarations

Competing Interests: The author declares no competing interests.

Grant Information: No grants supported this work.

Data Availability: No data are associated with this article.

References

  • 1. Strohmeier S. Research in e-HRM: Review and implications. *Human Resource Management Review*. 2007;17(1):19–37.
  • 2. Marler JH, Fisher SL. An evidence-based review of e-HRM and strategic human resource management. *Human Resource Management Review*. 2013;23(1):18–36.
  • 3. The Open Group. *TOGAF Standard, Version 9.2*. Reading: The Open Group; 2018.
  • 4. Conway ME. How do committees invent? *Datamation*. 1968;14(4):28–31.
  • 5. Herbsleb JD, Grinter RE. Splitting the organization and integrating the code: Conway’s Law revisited. In: *Proceedings of the 21st International Conference on Software Engineering (ICSE)*. Los Angeles: ACM; 1999. pp.85–95.
  • 6. Cherns A. The principles of sociotechnical design. *Human Relations*. 1976;29(8):783–792.
  • 7. Trist EL. *The Evolution of Socio-Technical Systems: A Conceptual Framework and an Action Research Program*. Toronto: Ontario Quality of Working Life Centre; 1981.
  • 8. Edmondson A. Psychological safety and learning behavior in work teams. *Administrative Science Quarterly*. 1999;44(2):350–383.
  • 9. Forsgren N, Humble J, Kim G. *Accelerate: The Science of Lean Software and DevOps*. Portland: IT Revolution Press; 2018.
  • 10. Raymond ES. *The Cathedral & the Bazaar*. Sebastopol, CA: O’Reilly Media; 2001.
  • 11. Tyree J, Akerman A. Architecture decisions: Demystifying architecture. *IEEE Software*. 2005;22(2):19–27.
  • 12. Skelton M, Pais M. *Team Topologies: Organising Business and Technology Teams for Fast Flow*. Portland: IT Revolution Press; 2019.
  • 13. Stol KJ, Fitzgerald B. Inner Source — Adopting Open Source Development Practices in Organizations: A Tutorial. *IEEE Software*. 2015;32(4):60–67.
  • 14. Davenport TH, Prusak L. *Working Knowledge: How Organizations Manage What They Know*. Boston: Harvard Business School Press; 1998.
  • 15. Kotter JP. *Leading Change*. Boston: Harvard Business Review Press; 1996.
  • 16. Westrum R. A typology of organisational cultures. *Quality and Safety in Health Care*. 2004;13(Suppl II):ii22–ii27.
  • 17. DORA/Google Cloud. *State of DevOps Report*. Google LLC; 2023.

Leave a Reply

Share