Dieser Artikel ist auch auf Deutsch verfügbar
This article is part of a series
- Part 1: Common Approaches in the Field of Socio-Technical Architectures
- Part 2: Platforms, Teams, and APIs: How Do They Fit Together?
- Part 3: Socio-Technical Architecture as a Competitive Advantage
- Part 4: Don’t Forget the People (this article)
- Part 5: How Much Thinking Can a Team Handle?
- Part 6: Internal Development Platforms
- Part 7: Enabling Stakeholders as a Success Factor
- Part 8: Socio-Technical Architectures: Informality from Mining to Today[1]
New Architecture, New Skills
A major aspect of architectural transformation is that introducing new architectures often requires new skills and expertise. Suddenly, technologies, frameworks, integration patterns, or runtime environments become relevant—many of which are completely unfamiliar to team members. This learning curve should not be underestimated, and the resulting uncertainty can quickly become a burden. Simply offering a few training sessions is not enough—organizations need a sustainable learning culture that allows room for trial and error while ensuring support from experienced colleagues.
Breaking Down Silos – Easier Said Than Done
One of the major promises of modern software architectures is the elimination of old silos. Teams are expected to work cross-functionally and take ownership of their domain. However, this cultural shift does not happen automatically.
Someone who has worked exclusively on backend development may struggle when suddenly required to dive into frontend technologies—and vice versa. Similarly, taking on more responsibility can feel overwhelming for some. It is crucial to actively engage employees in this transition and to take their concerns seriously.
Communication Barriers in Focus
Aligning software architecture with organizational structures means that developers will need to collaborate more closely with business teams—often more than ever before. For example, defining subdomains within a company requires constant interaction between developers and domain experts.
This process frequently exposes communication barriers that may have previously gone unnoticed. Differences in terminology, expectations, and priorities can lead to misunderstandings. Roles that evolve significantly—such as business analysts—can create uncertainty or even feelings of status loss. At the same time, not all engineers are naturally inclined to immerse themselves deeply in business processes and objectives.
To address these challenges, organizations must proactively create spaces for constructive dialogue—whether through workshops, joint retrospectives, or mediators who help bridge the gap between technical and business teams.
Incrementalism Preferred – But Not Without Risks
In most cases, I advise clients to approach modernization incrementally rather than pursuing a massive “Big Bang” overhaul. From an architectural and business perspective, this approach makes a lot of sense:
Instead of committing large amounts of capital and capacity to a high-risk transformation, an incremental strategy allows for quick wins and course corrections when plans inevitably collide with reality.
However, the human factor must also be considered. Incremental modernization often involves creating small “Architecture Modernization Teams” that get early access to new technologies and approaches or work on a greenfield project.
For longstanding teams, this can fuel resentment or resistance toward new technologies and approaches. A strong modernization strategy should include mechanisms to actively counteract these effects and ensure broad team engagement.
The Challenge of Reorganization
Perhaps you have already achieved some early successes with the new architecture, and your modernization team is growing alongside the new software. A temporary matrix organization might suffice for initial experiments, but long-term success requires structural clarity.
If new architectural principles are taken seriously, they will sooner or later raise questions about organizational team structures. Ideally, the building blocks of a business-aligned software architecture should match team responsibilities—which often necessitates restructuring.
These deep organizational changes are rarely conflict-free. Successfully implementing them requires courage and sensitivity to ensure that employees are actively involved and that resistance is minimized.