How I Approach IT Architecture and Project Design

I often get asked how to properly plan and structure an IT project. This is, surprisingly to many, relatively easy in principle, but much more challenging in practice. An IT system does not create value just by existing (okay, maybe Bitcoin :-)), but it usually serves a purpose, at least in B2B business applications.

1. Understand the context#

View this step in the illustration ↗

A solid start is to fully understand the core processes of the organization using the tool. It is important not to be too narrow at this point. Try to understand the big picture and get to the drawing board. Align this with the organization and get it into some form of artifact, like a Mermaid chart, BPMN 2.0 (if you are no longer in your 20s, like me :-)), Draw.io or whatever you like.

Align this with key stakeholders to ensure it is clear what the tool is doing and in which procedural context it will be embedded. This sounds easy but is already hard for many organizations.

Already at this point, you should check and discuss legal and compliance restrictions the organization must follow to ensure the design is legally compliant and secure from the ground up. Check for GDPR, NIS2, the AI Act, CRA and all other relevant legislation, where applicable, and speak to the legal department or a lawyer if needed.

2. Define the requirements#

View this step in the illustration ↗

After this step is done, we should have a solid understanding of what the organization needs. Now we can translate this into a set of requirements. This includes functional requirements, meaning what the system should do, but also non-functional requirements such as performance, availability, security, scalability and maintainability.

Try to make these requirements as concrete and measurable as possible. For example, a requirement like “the system should be fast” is not helpful. What does fast mean? 100 milliseconds? 2 seconds? And under which circumstances?

Also, do not forget that requirements can contradict each other. The business might want a highly available system with real-time processing, but at the same time have almost no budget for infrastructure.

These are discussions you need to have early, not when the system is already half implemented.

The outcome should be a clear set of requirements, constraints and expected results that the organization agrees on.

3. Choose design patterns#

View this step in the illustration ↗

Problems arise. This is the part where we need solutions!

The best way is to solve problems with proven, time-tested solutions: design patterns, for example the Cloud Design Patterns (ideally from Microsoft :-)). You should work with established design patterns where they make sense. Read them, understand them, apply them and build your design based on these patterns. There is usually no reason to reinvent the wheel.

For example, if you need to build a system that processes events, stores historical changes and provides different views of the same data, you might want to look into Event Sourcing and CQRS. If you have external services that can temporarily fail, look into Retry and Circuit Breaker patterns.

Of course, not every system needs a complicated architecture. Sometimes a simple application with a relational database is perfectly fine. The point is to understand the problem first and then evaluate which existing solutions are suitable. Also, document why you selected a particular pattern and why you rejected alternatives. This is very important in case another architect takes over. Then this person knows your design choices were deliberate and can understand your reasoning.

4. Select the technology#

View this step in the illustration ↗

After this is clear, we know which design patterns we need to implement to address the concrete problems and challenges. Now we can evaluate which technology is suitable and which might not be suitable. This is an important distinction because I have seen projects where the technology was already decided before anyone properly understood the requirements.

“We want Kubernetes.”

“We want microservices.”

“We want everything in Azure.”

Okay, but why?

Technology should follow the requirements and architecture, not the other way around. For example, if we decided to implement Event Sourcing with CQRS, we could use Azure Cosmos DB as an event store, Azure Functions for event processing and Azure SQL for read projections.

This is just one possible implementation, of course. We also need to consider costs, existing infrastructure, available skills in the organization, vendor lock-in and long-term maintenance. There is little value in building a technically beautiful system if nobody in the organization can maintain it afterwards.

At the end of this step, we should have a feasible technology selection that supports our design.

5. Engineer the guardrails#

View this step in the illustration ↗

Now we know what we want to build and which technologies we intend to use.

But before we start implementing everything, we need to ensure the system will be secure, reliable and compliant with the applicable requirements. Remember the legal and compliance restrictions we identified in the first step? Now we need to translate them into actual technical controls, taking into account what we have already defined during the earlier design steps.

For example, GDPR requirements might affect how we store personal data, who can access it, how long it is retained and how it can be deleted. NIS2-related requirements, where applicable, might influence our security controls, incident handling and operational procedures. For AI systems, the EU AI Act might introduce additional requirements depending on the system’s classification and intended purpose.

This is also where we define things like authentication, authorization, logging, monitoring, encryption, backup and recovery. And please, do not confuse writing a security policy with implementing security. A document saying that access is restricted does not restrict access. The controls need to exist in the system, and ideally we should be able to demonstrate that they work. How individual regulations translate into architecture decisions is covered in more depth under Compliance & Governance.

6. Agree the architecture#

View this step in the illustration ↗

Now we have the business context, requirements, design patterns, technology selection and technical guardrails.

Time to bring everything together. And by everything, I mean everything relevant to the design.

Create a proper architecture design document (ADD) and discuss it with the relevant stakeholders. This does not mean writing a 200-page Word document that nobody will ever read. Keep it brief, but include everything that is needed.

Use architecture diagrams, data-flow diagrams, interface definitions and Architecture Decision Records (ADRs) where they add value. I personally prefer visual representations because they make it much easier to discuss complex systems with people from different backgrounds. Also, challenge the architecture or speak with friends or other architects. You might have missed something. Work with AI to double-check and challenge your reasoning, but verify its conclusions. You still have time to make corrections, and there is no shame in this.

What happens if a service is unavailable? What happens if the database fails? How do we restore the system? What happens if the amount of data increases tenfold? And who is actually going to maintain all of this?

These questions might sound obvious, but they are often overlooked. The objective is to agree on a design that is realistic, maintainable and aligned with the requirements.

7. Guide the delivery#

View this step in the illustration ↗

Now we can finally start building the system.

But the architect’s job does not end here. A good architecture on paper is relatively useless if the actual implementation looks completely different.

Stay involved during implementation, work with the development teams and review important technical decisions.

Make sure the agreed patterns and security controls are actually implemented. I would not recommend babysitting the implementation team, but as an architect, you still need to double-check whether what is being implemented follows the agreed plan.

Use automated testing, CI/CD pipelines, code reviews and infrastructure as code where appropriate.

At the same time, do not turn architecture into a bureaucratic nightmare where developers need approval for every small change.

Developers should have enough freedom to make technical decisions within the agreed architectural boundaries. And if something does not work as expected, change it! An ADD can and should be a living document (within limits).

There is no reason to defend an architectural decision just because it was made six months ago.

8. Operate, learn and adapt#

View this step in the illustration ↗

The system is now in production.

Great, but we are not finished.

In fact, this is where we find out whether many of our assumptions were actually correct.

Maybe the system is slower than expected. Maybe operational costs are higher. Maybe users work with the application in a completely different way than originally anticipated.

This is why monitoring, logging and operational feedback are so important. Compare the actual behavior of the system with the requirements we defined earlier. If something does not work, investigate why. Challenge your assumptions along the way.

Maybe we need to optimize a database, change an integration, improve a business process or even reconsider an architectural decision. Also, requirements do not remain static. Organizations change, legislation changes and technology changes.

The architecture needs to be able to adapt.

Keep the loop open#

One final point: These eight steps are not meant to be a strict waterfall process. I know the term is unpopular these days, but try to work in an agile way.

You do not finish step one, never look at it again and blindly continue until step eight.

In practice, you will go back and forth. Take a whiteboard or an iPad and start drawing an architecture with pen and “paper”. This helps a ton.

During implementation, you might discover that a requirement was wrong. During testing, you might find that a design pattern is not suitable. During operations, you might discover that the business process itself needs to change.

That is perfectly normal. And frankly speaking, if nobody ever challenges an assumption or questions an architectural decision during a project, I would start wondering whether we are looking critically enough at what we are building.

The important part is to keep the loop open and validate assumptions early.

Feed what you learn during development and operations back into the requirements and architecture. In the end, planning and structuring an IT project is not particularly complicated in principle.

Understand the business, define the requirements, use proven design patterns, select suitable technologies, implement the necessary controls and make sure the system actually works.

The difficult part is doing all of this consistently while dealing with budgets, deadlines, different stakeholders and changing requirements.

And that is where the real work begins. :-)