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

Organise around domains, not around initiatives

Teams are no longer formed 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 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 linked 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 stabilising framework that maintains coherence without blocking innovation.

Treat technical debt as a structural item on the balance sheet

Technical debt should not be a residual category within projects. It must be made visible, measurable, and manageable. This implies structural budget for refactoring, transparency over 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 organisation. Roadmaps are then determined by technical limitations rather than strategic ambitions.

Actively rationalise the application portfolio

Organising software as a core competency also means being willing to actively eliminate. Overlapping functionality must be eliminated, legacy systems should not be extended indefinitely, and build versus buy decisions must be made consciously based on strategic differentiation.

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

Link organisational design to architecture

The way teams are organised determines the form 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, organisational 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 competency is not assessed on what goes live today, but on how easily it can change tomorrow without structural redesign.