Systems, Architecture and Systems Architecture

One of the most persistent misconceptions is that architecture artifacts exist primarily to satisfy documentation requirements. Empirical work suggests something more important: certain artifacts act as boundary objects that enable cooperation across professional communities.

Boundary objects and why they matter

EA practice uses EA artifacts as instruments of communication and collaborative decision-making intended to bridge the communication gap between business and IT stakeholders (Kotusev, 2023, p. 1). Boundary objects are framed as material objects that enable diverse communities to cooperate: “adaptable to different viewpoints” while “robust enough to maintain identity” across them (Kotusev, 2023, p. 3).

What the empirical study found

Kotusev’s empirical analysis identifies five EA artifacts—business capability model, conceptual architectures, maxims, roadmaps, and solution designs—that support communication and collaboration between professional communities and “represent classical boundary objects,” used within routine decision-making processes constituting EA practice (Kotusev, 2023, p. 7). These artifacts facilitate translation across professional boundaries and allow knowledge to “occupy multiple social worlds,” supplementing face-to-face communication through durable representations of “congealed reality” (Kotusev, 2023, p. 7).

Two properties deserve special attention:

• Interpretive flexibility: different communities can use the artifact without requiring identical frames of reference (Kotusev, 2023, pp. 7, 13).
• Stability: boundary-object artifacts “do not get modified spontaneously without a preliminary conversation and agreement between their stakeholders” (Kotusev, 2023, p. 11).

Finally, these artifacts can provide shared language, shared meaning, and shared tools to span syntactic, semantic, and pragmatic knowledge boundaries (Kotusev, 2023, pp. 8–10).

What to do in practice

• Treat ADRs as boundary objects: add explicit sections for stakeholders, shared terms, trade-offs, and decision stability rules.
• Enforce stability: “No ADR change without stakeholder agreement.” Make the process visible.
• Make diagrams operational boundary objects: include legend + intent + constraints, not only boxes/arrows.
• Connect artifacts: ADRs should link to diagrams and vice versa; avoid “floating” documents.

Bibliography

Kotusev, S. (2023). Enterprise architecture artifacts as boundary objects: An empirical analysis. Information and Software Technology, 155, 107108.