I came at this from a similar place a few years ago and want to offer a counter to the default "TOGAF first" answer, because the sequencing actually matters. The advice I'd give my earlier self: start with business architecture before enterprise architecture. Three reasons.

• First, business architecture forces you to anchor every conversation to capability, value stream, and stakeholder — which is the language the business actually speaks.
• Second, TOGAF taught in isolation produces architects who can render an ArchiMate diagram but can't translate it into a board-level conversation.
• Third, once business architecture is in your bones, TOGAF makes far more sense because you understand what the layers are for.
  

What worked for me, in order: The BIZBOK Guide (Business Architecture Body of Knowledge, from the Business Architecture Guild). This is the substrate. Read it slowly; it rewards multiple passes. Strategy to Reality by Whynde Kuehn. Operationalizes BIZBOK and bridges strategy execution to architecture practice. Probably the single most useful book I've read for early-career EA work. Joining a Business Architecture Guild reference model team. I'm on the Government Reference Model Team. The team format forces you to argue capability definitions and structure with practitioners who do this for a living. You learn more in three months of team participation than in a year of solo reading. TOGAF after that, not before. Foundation is fine as an introduction; the real value is in TOGAF Enterprise Architecture: Foundation and TOGAF Business Architecture: Foundation, which build on the BIZBOK substrate. On certifications specifically — TOGAF is table stakes for many roles, so get it. But don't let cert-collection substitute for the practitioner muscle you build by doing capability work in a real environment.

One more thing that's worked for me, and I'd recommend to anyone learning while doing the job: use a structured framework to learn through your real work, not in parallel to it. I use a Delegate / Describe / Discern / Diligence pattern (the "4 Ds") with Claude as a thinking partner — describe the artifact I'm building, discern where my reasoning is weak, delegate the parts a model can accelerate, and apply diligence on what the model produces before anything goes to a stakeholder. The point isn't the AI tool specifically; the point is having a structured way to practice while you perform, because early-career EA work moves too fast for "study now, apply later" to be realistic.

Good luck. The field rewards people who lead with business and let the architecture follow.