career bridge
Read the estate
Map what exists before you draw anything, including the constraints that are about people rather than systems.
You have designed systems, or led delivery, or been the person who could explain how the whole thing fits together. You may well have drawn an AI architecture on a whiteboard. What you have not done is design one for a department carrying twenty years of systems, opinions and constraints you did not choose.
What you do
Map what exists before you draw anything, because an architecture that ignores the estate gets ignored by the estate. Take a real department, yours or a public body with published documentation, and produce three things. First the system map: what runs, what talks to what, and where the data people care about actually lives, which is rarely where the documentation claims. Second the constraint list: what cannot change, and why. Some constraints are technical, a mainframe, a data residency rule, a vendor contract with four years left on it. Most are not. A team that will not adopt anything, a budget that renews in March, a director who was burned by the last platform. Write the human ones down too, plainly, because they decide more outcomes than the technical ones do. Third the people map: who has to agree before anything ships, and what each of them is measured on. Then for each of the three or four AI use cases the department actually wants, write one line on what it needs from the estate. Not a solution. Just the demand. You are hunting for what repeats, because what repeats is what you build once.
Done when
- A system map exists showing what runs, what connects, and where the data actually lives.
- A constraint list separates technical from human constraints, and does not omit the human ones.
- A people map names who must agree, and what each of them is measured on.
- Three or four real use cases are each reduced to one line on what they need from the estate.
- The requirements that repeat across use cases are identified and marked.
What you end up with
A one-page estate map for a real department: what runs, what cannot change and why, who must agree, and what the use cases repeatedly need.
If you get stuck
The common failure is drawing the target architecture in week one, which produces something correct and unadoptable. You cannot design for an estate you have not read. The second failure is listing only technical constraints because the human ones feel unprofessional to write down. Those are the ones that kill designs. Record them in neutral language, and keep the document somewhere you would be comfortable having it read.