Building Enterprise Architecture Where There Was None

Context

A large Nordic IT services provider ran a banking-services account spanning Finland, Sweden and Norway, with delivery teams in the Czech Republic. Architects were assigned project by project. They wrote the technical sections of commercial offers and, occasionally, some basic architecture documentation – usually describing only the final result, without the options considered or the reasoning behind the choice.

Every later extension or change therefore started almost from zero: nobody could easily find out why a solution looked the way it did, or what had been ruled out and for what reason.

The challenge

The difficult part was not technical. It was convincing people that architecture structure was worth having at all – and that it would help the engineers themselves, not just management.

• Fear of losing know-how. Some specialists worried that documenting their systems would make them replaceable.
• Four different cultures. A Finnish headquarters, a Swedish branch closely tied to it, a Norwegian business that joined through an acquisition with its own tooling (CMDB, monitoring, processes), and a Czech delivery centre with mostly operational roles.
• No precedent. An enterprise architect embedded in delivery was a new kind of role for most of the teams.

The approach

I was appointed by the client executive and the delivery executive as their architecture counterpart towards both the delivery teams and the customer, with a mandate at their level: I could engage any subject-matter expert, project manager or engineer directly. I worked through the domain and product architects rather than around them, and introduced structure step by step – each piece useful on its own:

1. An architecture overview of the account – the shared map everyone was missing.
2. HLD and LLD templates, then real HLD/LLD documents for every new project as it arrived, so the standard was proven in practice, not just announced.
3. Release and lifecycle management for hardware and operating systems, with end-of-support dates tracked in one place.
4. High-level diagrams and a clearer service catalogue, so people understood which company services existed and how they fit together.
5. A quarterly governance board – client executive, delivery executive, project lead and me – reviewing architecture decisions and their consequences, for example turning release-management findings into lifecycle projects.

The outcome

• Faster preparation of customer offers, because the technical baseline and templates already existed.
• A coherent, searchable body of documentation instead of scattered project files.
• Traceable decisions: anyone can now see why something was built, and what was excluded for technical reasons or at the customer’s request.
• The same governance foundations were extended across five business areas of the organization.

My role

• Defined the enterprise architect role, responsibilities and its place in existing processes.
• Authored the architecture overview, the templates and the first HLD/LLD documents.
• Set up and ran the governance board and the release/lifecycle management process.
• Coordinated domain architects across infrastructure, virtualization, operating systems, storage, backup and security.