Organising software as a core competence: from project structure to product architecture

Organise around domains, not around initiatives

Teams are no longer composed per project, but around stable business domains with a clear responsibility. Each domain has its own roadmap and a fixed team that remains the long-term owner of the software within that domain. This prevents domain knowledge from disappearing after delivery and makes responsibility explicit rather than shared and diffuse.

Domain structure determines the team structure. Not the other way around.

Make product responsibility persistent

Each core application gets a product owner with ongoing budget responsibility. Budgets are not tied to one-off deliveries, but to continuous value creation and maintenance. A product has an ongoing roadmap, a structural budget, a clear set of KPIs and a transparent cost profile.

Without permanent ownership, software automatically reverts to project thinking, where responsibility ends at go-live.

Give architecture a mandate

Architecture cannot remain an advisory role when software is strategic. Architectural principles must be enforceable. Domain boundaries are formally established, integration principles are not optional, and deviations are explicit, temporary, and substantiated.

Technical standards are monitored across teams to limit variation. Architecture thus serves as a stabilizing framework that maintains coherence without blocking innovation.

Treat technical debt as a structural balance item

Technical debt should not be a leftover category within projects. It must be made visible, measurable, and manageable. This implies structural budget for refactoring, transparency about dependencies and legacy components, and periodic evaluation of the application portfolio.

When technical debt is not explicitly managed, it invisibly affects the strategic space of the organization. Roadmaps are then determined by technical constraints rather than strategic ambitions.

Actively rationalise the application portfolio

Organising software as a core competence also means daring to cut actively. Overlapping functionality must be eliminated, legacy systems should not be endlessly extended, and build versus buy decisions must be consciously made based on strategic differentiation.

Core logic that is distinctive for the organization requires internal control. Standard functionality can be outsourced externally. Without explicit portfolio governance, integration complexity grows exponentially.

Link organizational design to architecture

The way teams are organised determines the shape of the system. When teams are structured around technical layers, the architecture reflects those technical layers. When teams are organised around domains, domain autonomy arises in the software.

Therefore, organizational design must be consciously aligned with the desired architecture. Conway’s Law is not an abstract theory but a structural reality in large software environments.

Measure for evolvability

Project models measure delivery. Product models measure evolution. Success criteria shift from the number of features or time to go-live to the lead time of changes, impact radius of adjustments, and degree of dependencies between systems.

Software as a core competence is not judged on what goes live today but on how easily it can change tomorrow without structural redesign.