Systems, Architecture and Systems Architecture

Most architecture conversations still drift toward a technical default: choose a pattern, pick a cloud service, optimize a quality attribute, and proceed. That framing is incomplete. Architecting is fundamentally decision-making in a coupled socio-technical environment, where organizational arrangements and technical choices continuously shape one another.

The socio-technical premise

Architecture practice (architecting) and the decisions it produces can be framed as socio-technical work because it involves decisions spanning organization and people as well as technology and processes, and because socio-technical approaches emphasize that social and technical aspects of digital transformation must not be analyzed separately (Rebentisch et al., 2022, pp. 86, 89). The implication is simple: “good architecture” is not just correctness of a design, but the ability to make decisions that remain viable given organizational realities.

What “context” means in architecting

Two complementary lenses help formalize what architects must hold together:

• Governance lens (organizational coordination): enterprise architecture governance is framed around aligning an organization on the basis of strategy, encompassing coordinated domains such as governance and compliance, finance and risk, roles and processes, and IT (Hillmann et al., 2024, p. 603).
• Architecture description lens (environment and concerns): architecture description standards emphasize that the “environment” includes technological, business, operational, organizational, and social influences. They also define “concerns” (including expected quality attributes) and allow architecture descriptions to capture dependencies and constraints explicitly (ISO/IEC/IEEE, 2020, pp. 3–4).

In practice, this means architects are not merely selecting a technical structure; they are translating stakeholder concerns into a representation that makes trade-offs explicit and governable.

What to do in practice

For each decision, explicitly record both:

• organizational/social considerations (roles, approvals, risk, accountability), and
• technical/process considerations (constraints, dependencies, operational behavior).

Add a “non-separable STS check” to your decision review: “What social change is implied by this technical choice?”

Ensure every decision produces a representation that captures: constraints, dependencies, and quality attributes (not just a diagram).

Bibliography

Hillmann, P., Kesseler, M., Schnell, D., Mihelcic, G., & Karcher, A. (2024). Enterprise Architecture Governance of Excellence. In Proceedings of the 26th International Conference on Enterprise Information Systems (ICEIS 2024) (Vol. 2, pp. 603–613). SCITEPRESS.

International Organization for Standardization, International Electrotechnical Commission, & Institute of Electrical and Electronics Engineers. (2020). ISO/IEC/IEEE DIS 42010:2020(E): Software, systems and enterprise—Architecture description (Draft International Standard).

Rebentisch, E. S., et al. (2022). On the use of sociotechnical systems design in industry. In CEUR Workshop Proceedings (Vol. 3239).