DigitableCourses
Portal settings
Show me around

Local and account-free. No account, no sign-up: whatever you type into the tools stays in this browser's localStorage and never reaches a server.

Our own counter records page opens and finishes: the address leaves, plus one tenth-of-the-text figure. No cookies, no outside trackers, your IP is not stored, Do Not Track is honoured. How to check that

The portal's own repository is not published, so we do not call it open source. What is open:

The portal lives on donations, paid consultations and requested write-ups, and on Workbench sales.

There are no plans to make the courses paid.

Career

Architect

Owns the decisions where the price of a mistake is years, not a sprint.

  1. Software architect
  2. Solution architect
  3. Enterprise architect

Software architect

Straight to the self-check

The horizon changes: you answer not for your own module but for the system as a whole and for whether it can still be changed long after it was designed.

Do now

  • I write the choice of architectural style down together with its priceI can explain why a modular monolith belongs here rather than microservices.
  • I draw the boundaries along the domain and test them against the language of the businessMy modules line up with the way the customer talks about their own work.
  • I name the places where consistency is not immediate and what the user sees at that momentI know where the data diverges, and it is written down rather than assumed.
  • I come back into the code of my own system regularlyI read and change what I designed instead of only drawing diagrams.

Where next

Solution architect

Sideways out of the role

What this step asks of you

  • I choose an architectural style to fit the problem and know its priceI can explain why a modular monolith belongs here rather than microservices.
  • I record decisions so that they can be revisitedEvery major choice has an ADR with the context and the conditions for revisiting it.
  • I draw the boundaries along the domain, not along the layers of codeMy modules line up with the way the business thinks about its own work.
  • I understand what being distributed does to dataI know where we have eventual consistency and what the user sees at that moment.

Common mistakes

  • Designing by fashion: microservices adopted without need come to the team along with distributed failures.
  • Drifting away from the code: the diagrams stop matching the system, and that comes out during an incident.
  • Leaving a decision with no conditions for revisiting it: it gets overturned silently and nobody remembers why.

What to learn

  1. Software architect
  2. Solution architect
  3. Enterprise architect

Solution architect

Straight to the self-check

The systems become somebody else's: beyond the edge of your influence there are people who will change their part without asking you.

Do now

  • I write a contract that survives a change on the other sideThe integration does not break when a neighbour adds a field.
  • I turn reliable and fast into requirements that can be checked, and I check them with a runThe solution has a load calculation, not only a diagram on a slide.
  • I bring the threat model in before implementationSecurity affected the choice of solution rather than a report afterwards.
  • I break the migration into states in each of which the system worksThe transition can be stopped halfway and life goes on.

Where next

Enterprise architect

Sideways out of the role

What this step asks of you

  • I design integrations between systems that have different ownersThe contract survives the other side changing its system without warning.
  • I turn reliable and fast into concrete numbers and then check themThe solution has a load calculation, not only a diagram on a slide.
  • I build security into the architecture instead of hanging it on afterwardsThe threat model is discussed before implementation and affects which solution is chosen.
  • I plan a migration that can be stopped halfwayThe transition has intermediate states, and the system works in every one of them.

Common mistakes

  • Agreeing with a contractor verbally: the mismatch surfaces at acceptance and there is nobody to blame.
  • Planning a migration as one jump: a failure halfway leaves two systems and not one that works.
  • Treating non-functional requirements as a formality: they are exactly what the system gets blamed for later.

What to learn

  1. Software architect
  2. Solution architect
  3. Enterprise architect

Enterprise architect

Straight to the self-check

The way you get things done changes: nothing here is settled by a technical argument — it is settled by money, risk and other people's interests.

Do now

  • I keep the map of links between systems and know who falls over together with this oneI can name the consequences of switching any of them off.
  • I make the standard more convenient than breaking itNobody works around it, because going by it is faster.
  • I justify a decision with money and risk for people who do not read diagramsI talk to the finance director in their own language.
  • I find out what the regulator requires before designingI know where our personal data is and what we are allowed to do with it.

Where next

Not another step — a fork

Sideways out of the role

What this step asks of you

  • I see the landscape of the company's systems and know what is connected to whatI can say which systems will fall over if this one is switched off.
  • I introduce rules that teams follow without a supervisorThe standard is more convenient than breaking it, so nobody works around it.
  • I justify architectural decisions with money and riskI talk to the finance director in their own language instead of showing diagrams.
  • I account for the requirements of regulators before designing, not after an auditI know where our personal data is and what the law allows us to do with it.

Common mistakes

  • Introducing a rule with no owner: it is followed until the first urgent release.
  • Running the landscape from presentations: the real links are known by the teams, and they will not invite you.
  • Drifting away from engineering altogether: the decisions are made beautifully and never carried out.

What to learn