OUR DISCIPLINES
Enterprise and Solution Architecture in
South Africa.
Architecture is the one discipline in technology where the work is finished long before anyone can tell whether it was right or not. The decisions get made early, but the cost of them lands two or three years later, and the person who made them is usually judged on a document written long before the system even existed.
This is how enterprise, solution and integration architecture really works in South Africa: the businesses joining old, acquired, half-migrated and vendor-locked systems into something that actually runs. The roles, the market, and what it takes to get the hire right, whether you’re building the team or building your own career.
A LOOK AT THE MARKET
The enterprise architecture
market in South Africa.
Very little enterprise architecture work in this country is greenfield. Almost all of it exists because something old has to keep working while something new is attached to it, and because a decision taken in 2011 is now standing between the business and where it wants to go. That is the defining characteristic of this market, and it shapes who succeeds in it.
There are two forces setting the demand right now, and both of them come with deadlines.
The first is ERP. South Africa is a deep SAP market, far deeper than its economy would suggest, because mining, manufacturing, retail, utilities and the large industrial groups standardised on it decades ago and built around it ever since. Mainstream maintenance for SAP ECC ends at the end of 2027, with extended maintenance available to 2030 at a premium, which means a large share of the country’s biggest businesses are inside an ERP programme, about to start one, or quietly hoping they can defer one. Those programmes do not fail on the ERP, they do on everything the ERP touches, which is where the integration and solution architects earn their money.
The second is payments and financial services. The Payments Ecosystem Modernisation programme the Reserve Bank launched in September 2025 has ownership and money behind it. The SARB has taken half-ownership of BankservAfrica to turn it into a national payment utility, the high-value systems are being rebuilt to international standards, and activity-based licensing is on the way, opening direct participation to non-banks. Add real-time payments through PayShap, now sitting inside ordinary customer expectations, and every bank, insurer and payment business in the country is holding a multi-year architecture problem: how to expose a modern, real-time, standards-based interface to the market when the system of record behind it was written to batch overnight.
Underneath both, the estates themselves are the work. South African corporates are group structures, with holding companies sitting over operating businesses acquired over decades, each arriving with its own ERP, its own CRM, its own payroll and its own view of what a customer is. That is an integration architecture problem in its purest form, and it is why this discipline is better paid here relative to engineering than a lot of people expect.
Cloud changed the conversation more than it changed the estates. All three hyperscalers now run local regions, so POPIA and data residency stopped being a reason not to move and became a design question about what sits where.
What most businesses actually have is hybrid and will stay hybrid: a mainframe or an AS/400 that still holds the truth, a couple of SaaS platforms nobody can configure their way out of, an on-premise data centre with five years left on the lease, and a cloud estate assembled by three different teams under three different standards. Designing well inside that is its own skill, and it is learned on estates like these.
There is a local habit worth naming too, a decade of unreliable power and patchy connectivity taught South African architects to design for an environment that fails, and it shows. Queueing, retry, store-and-forward, graceful degradation and offline tolerance are ordinary instincts here, built in over a decade of designing for an environment that could disappear at 18h00. That is an export-grade strength of the local population, and it is worth screening for directly, because an architect whose experience sits entirely on clean, well-funded cloud-native platforms has rarely had to develop it.
Then there is cost, which architects in this country carry personally. Cloud consumption, software licences and most platform tooling are priced in dollars while the revenue is in rands, so a design decision that looks marginal in a reference architecture turns into a real number on a South African P&L. The architects who are valued here are the ones who can put a rand run-cost against a design and defend it, and that conversation now happens early in the design.
Supply is the constraint, as always. The senior architecture population here is small and it is priced internationally. A good integration or cloud architect in Johannesburg is likely working for a business in London, Amsterdam or Dubai. While a large share of the remaining capability sits inside consultancies, system integrators and vendor pre-sales teams. Those people have seen a lot of environments, which is experience you want to see. Fewer of them have had to live inside a design for three years, or explain to an exec why the thing they designed cost more than they said it would.
One last thing before you start reading CVs. Almost nobody in this country arrived here through a formal architecture route, because that route hardly exists. They came out of software engineering, integration and middleware, infrastructure or ERP, and picked the discipline up on the job. That is usually a strength, because they know what it takes to build the thing they are designing. It does mean the CV will tell you where somebody came from and very little about whether they made the step.
THE TITLE
What 'Enterprise Architecture' and 'Solution Architecture' in a job title actually means.
No title in technology has inflated faster. “Solution Architect” is used for a senior developer who designs the service they are about to build, for a vendor pre-sales consultant who designs a proposal they will never implement, for a programme-level designer accountable across eight systems, and for someone who maintains a set of diagrams that nobody has opened since the last audit. Four separate jobs, one title, and a shortlist that looks uniform until you start asking questions.
The first question to ask is scope: what is the largest thing this person has been accountable for the design of? A system, programme, domain, or the estate. Scope is the axis this discipline runs on, and it is the one thing a title always leaves out.
The second question is simpler and it separates the good from the great: what did this person design that is now running?
Most architecture CVs offer the diagram, the principles, the target state and the roadmap. The documents are usually good, often better than good, because producing them is the part of the job that gets practised daily. The evidence worth looking for sits a layer behind them, in what happened when a delivery team, a vendor, a budget cut and an immovable go-live date all got hold of the design.
The candidates you want can walk you through a system in production, explain which parts of the original design they gave up and why, name the compromise they most regret, and tell you what it cost. That is the judgement you are paying for, and it is only earned one way.
TOGAF, the cloud architecture certifications, the vendor platform credentials and the rest are worth having, and somebody who has invested in them is usually serious about the discipline. TOGAF in particular is close to a screening requirement in South African corporates and public sector work, so candidates get it. What it tells you is that a person has been taught a method and passed an exam on it. It tells you nothing about whether they can hold a design together when the programme is three months late and the vendor has just said no.
If you are hiring, write the spec around the scope the person will own and the decisions they will be trusted to make on their own.
THE ROLES
The roles, and what each one involves.
Every role here is defined by the blast radius of its decisions and by how far ahead of delivery it sits. Platforms and tooling matter. What travels between businesses is the ability to reason about systems that were never designed together.
Application or domain architect
Owns the design inside a single application, product or business domain, and is usually the most technically hands-on architect in the business. The natural first architecture role for a strong engineer, and the level where you find out whether somebody can design for other people to build.
Common tools: domain-driven design, service and API design, application patterns, non-functional requirement definition, technical debt assessment, and enough current engineering practice to keep the respect of the team.
Business architect
Works on the capability map: what the business does, what it needs to be able to do, and where the gaps sit before anyone chooses a system. Rare as a standalone hire in South Africa outside large financial services and the public sector, and easily mistaken for a business analyst by people who have not worked with one.
Common tools: business capability modelling, value stream mapping, operating model design, process architecture, and the ability to hold a conversation with an executive that does not mention technology once.
Chief Architect, Head or Architecture
Owns the shape of the estate and answers for the technology strategy to the executive and, in regulated businesses, sometimes to the board. Roughly a third technical judgement, a third commercial argument and a third organisational politics. Candidates who are strong only at the first tend to struggle, because at this level the job is mostly persuading people who do not report to you.
Common tools: technology strategy and roadmap, architecture governance and standards, buy, build and retire decisions, vendor and licensing strategy, portfolio-level cost management, and executive engagement.
Cloud or ininfrastructure
Designs how the business runs: landing zones, networking, identity boundaries, resilience, and the hybrid reality of a cloud estate that has to keep talking to a data centre for the next five years. Overlaps with DevOps and cloud engineering and the two are often confused in job specs, which costs businesses time.
Common tools: AWS or Azure architecture at scale, landing zone and network design, hybrid connectivity, resilience and disaster recovery design, infrastructure and policy as code, and FinOps and cost modelling.
Data architect
Designs how data is structured, stored, moved and governed across the business, which in a group structure means deciding whose version of a customer or a product is the real one. Sits close to data and analytics and is increasingly the role that decides whether an AI programme has anything usable to work with.
Common tools: data modelling, master and reference data design, lakehouse and warehouse architecture, data lineage and governance, streaming and CDC patterns, and POPIA-aware data classification and residency design.
Enterprise architect
Works at the level of the estate: what the business runs, what it should run, what gets invested in, and what finally gets switched off. The job lives or dies on standing. Give it real decision rights and it pays for itself several times over; leave it as a documentation function and the good ones are gone within eighteen months.
Common tools: current and target state architecture, capability and application portfolio management, roadmap and investment planning, standards and reference architecture, architecture governance forums, and TOGAF or an equivalent method applied with judgement.
ERP or SAP architect
Designs how an ERP fits the business and how the business fits around the ERP, including the decisions about where to configure, where to extend and where to leave the standard alone. A scarce and well-paid profile in South Africa given the concentration of SAP in mining, manufacturing, retail and utilities, and the number of businesses now inside an S/4HANA move.
Common tools: S/4HANA and ECC landscape design, clean core principles, extension and BTP strategy, master data design, ERP integration patterns, and migration and cutover architecture.
Integration architect
Designs how systems talk to each other, which in most South African businesses is the single hardest and least glamorous problem in the estate. Underrated relative to its impact, because the work only becomes visible when it is done badly. This is the profile most often missing from a programme that is quietly slipping.
Common tools: API design and management, event-driven architecture, message brokers and streaming platforms such as Kafka, integration platforms including MuleSoft, Boomi, Azure Integration Services or webMethods, ISO 20022 and other message standards, and legacy interface and file-based integration patterns.
Pre-sales or vendor solution architect
Designs the solution that is being sold, working alongside the sales team at a system integrator, software vendor or cloud provider. Genuinely skilled work, and a large share of South African architecture capability sits here. Worth understanding as a distinct profile with its own incentive, which is the signature on the contract, and worth testing carefully on the move in-house, because that transition asks for a different kind of patience.
Common tools: solution design and estimation, proposal and RFP response, proof of concept design, commercial modelling, vendor product depth, and client-facing presentation.
Security architect
Designs how security works across the whole estate. Covered in full in our cybersecurity guide, and mentioned here because the two disciplines increasingly hire from each other, and because a solution architect who cannot hold a credible security conversation now slows every design review down.
Common tools: reference architecture and security patterns, zero trust and segmentation design, identity architecture, threat modelling at system level, and technical standards ownership.
Solution architect
Owns the design across the set of systems a programme touches, from the requirement through to what actually goes live. The most common architecture hire in this market and the one most likely to be mis-specified, because the same title is used for a one-system design role and for a programme-wide accountability that reaches across six vendors.
Common tools: full solution design across systems, non-functional requirements, integration and data flow design, architecture decision records and trade-off documentation, vendor and package evaluation, and delivery-side involvement through to go-live.
Technical architect
Sits closest to the build, translating a solution design into something a delivery team can execute against, and staying involved while they do. Frequently the difference between a design that got built and a design that got quietly worked around, and the role that hands-on engineers move into most naturally.
Common tools: detailed technical design, platform and framework selection, performance and scalability design, proof of concept and spike work, code-level review, and mentoring of senior engineers.
Other disciplines we recruit in
AI & Machine Learning · Software engineering · DevOps and cloud engineering · Fintech · Project and programme management and more
IF YOU'RE HIRING
Hiring for judgement you can only see in hindsight.
The instinct in this discipline is to hire against the artefacts: the diagrams, the frameworks, the certifications, the years. It produces a shortlist that looks unarguable. What you are buying is judgement under constraint, which shows up in the decisions behind the artefacts.
What makes this hire genuinely difficult is that the work is slow to prove. A bad engineer is visible in a sprint, but a bad architect is visible in eighteen months, usually in the form of a programme that can’t land, an integration layer nobody will touch, or a licence commitment the business is stuck with. By then the decision is expensive and the person who made it has often moved on.
So the interview should go straight at the decisions. Here are some thought starters:
- Ask them to walk you through something that got built and is still running today. What did they design, what changed on the way, and what did they concede.
- Ask what they got wrong. An architect with ten years behind them and no regrets is telling you something either about their accountability or about their candour, and both matter.
- Ask what they have switched off. Estates here are almost entirely additive, and decommissioning something is harder politically than building something new. Very few people have done it on purpose.
- Ask about a time a delivery team went around them. Then ask why, and listen for whether the answer is about the team’s discipline or about their own design being unbuildable.
- Ask how they priced a design. The run cost in rands, who they had to convince of it, and what the number changed about the design.
- Ask them to explain a time when they went against their own preference, and what convinced them.
Listen for systems, people, money and consequences in the answers. Then look for the two defining capabilities that help to identify an exceptional hire in this market.
Constraint fluency. The ability to design for the estate that exists, with its acquired systems, deferred upgrades and undocumented dependencies. The skill is designing the step between here and the target state that the business can afford, deliver and operate, without painting itself into a corner two steps later. In this market, that is most of the job.
The ability to carry people. An architecture that delivery teams do not believe in gets approximated, and the approximation is what you live with. The architects worth paying for are the ones engineers seek out, and they get there on credibility. Where a candidate’s answers keep returning to governance forums and sign-off gates, you are looking at someone who has been given a mandate and never had to earn one.
One practical tip ahead of writing your job spec.
A large share of South African architecture vacancies are written as a list of frameworks, platforms and certifications, which reliably attracts people who have collected frameworks, platforms and certifications.
If the role exists because an S/4HANA programme is slipping, because three acquisitions are still running three finance systems, or because you have been asked to expose real-time services off a core that batches overnight, say so. The architects you want will read that and recognise a problem they have already solved.
WHY LEVELS MATTER
Understanding seniority.
Scope is the axis here. Here is a top line view of what each level looks like in practice, whether you are writing a brief or working out where you sit.
-
A technical or application architect owns the design of one system or product, and stays close enough to the build to be held to it. The thing to hire for at this level is whether they can design for other people to implement, which asks for a different kind of discipline. The good ones are still writing or reading code, and they are visibly uncomfortable handing over a design they could not build themselves.
-
A solution architect owns the design across everything a programme touches, including the parts owned by other teams and vendors. Usually the level at which somebody discovers that the hard part is the six people who each have to agree to a piece of it. Look for evidence of a live system, an honest account of what changed between design and delivery, and the ability to write a decision down in a way a non-technical sponsor can weigh.
-
A senior or lead solution architect is trusted with the work nobody can fully specify: the migration with no clean cutover, the integration layer four teams built differently, the platform decision that will be irreversible for a decade. Seniors here are measured by what they designed that held, and by whether delivery teams treat them as help or as a gate.
-
An enterprise or domain architect works above any single programme, on the shape of the estate: what the business invests in, what it standardises, what it buys, and what it finally retires. This is the level where the job becomes commercial and political, and where technical brilliance without organisational credibility stops being enough.
-
A Chief Architect or Head of Architecture owns the standard and answers for the technology strategy to the executive. The technical grounding still has to be real, because a chief architect who cannot interrogate their own team's advice is dependent on it. What changes is that the job becomes making technology decisions legible to people who will judge them on cost, risk and time to market, and holding a position when it is commercially inconvenient.
Where the money is
What lifts pay in this discipline is scope and consequence. Designing a system and designing an estate are separate jobs, and the market prices the second one properly because far fewer people have done it, and fewer still have done it in a mess.
Four kinds of experience move it most
- Integration at real complexity. A genuine estate problem, with legacy systems, vendor packages, batch dependencies and a business that cannot go offline. This is the scarcest profile in the local market and the one that unblocks programmes.
- ERP, specifically S/4HANA. A hard-dated wave of work in a market with a deep SAP install base and a thin population of people who have actually taken a business through it.
- A migration that landed. A cutover they designed that went live, the fallback they built behind it, and an honest account of whether they had to use it.
- Cost accountability. Architects who have owned a run-cost number, defended it and been measured against it command a clear premium, and it is the fastest-moving one in the discipline right now.
Underneath all of that, the fundamentals still carry. Recent enough engineering ability to hold credibility with a delivery team, enough data understanding to know where the truth lives, and enough security literacy to design something that passes review the first time.
The ‘unicorn’ hire in this market is the architect who can simplify. Estates accumulate systems, integrations, licences and patterns, and almost nobody has the combination of technical confidence and organisational standing to remove something and be right about it. That person saves a business more money over five years than any platform decision will.
What the package is really worth
Architecture salaries in South Africa are set by a wider market than the local one, and a benchmark that ignores that will be wrong every time. The strongest integration, cloud and ERP architects are visible to employers in the UK, Europe and the Middle East, and can often be employed by them without relocating. That is the real competitor to a senior offer, and businesses that benchmark only against local peers will always lose people.
Beyond the number, three things shape what the package is worth.
- The estate. An architect’s future earning power depends heavily on what they got to work on, so access to a large, complicated, genuinely difficult environment is part of the offer, and candidates who understand this negotiate for it.
- Mandate. Whether architecture decisions are binding or advisory changes the job entirely. An architect with no mandate spends their time producing documents to be overruled, and their market value stops moving within two years. Candidates should ask, and businesses should have an honest answer ready.
- Proximity to delivery. The market pays for designs that got built, so a role that keeps the architect involved through implementation compounds their value every year. Candidates should establish where the role ends, because a title carries less weight here than the accountability behind it.
THE COST
Contract vs Permanent.
The contract market for technology architects in South Africa is strong and has been for years, because most architecture demand is programme-shaped. A migration, a platform replacement, an integration layer, a regulatory build: real scope, a real deadline, and a depth of experience a business cannot justify carrying permanently once the programme closes.
The work that suits contract is clear enough. An S/4HANA design authority, the integration workstream on a core platform replacement, a cloud landing zone build, a post-acquisition systems consolidation, a payments modernisation programme, or an interim design lead while a permanent search runs. Paying a day rate for somebody who has taken three businesses through the same migration usually costs less than a permanent hire learning it on yours, and it costs a great deal less than a design that has to be undone.
Where we would draw the line is continuity. Architecture decisions are long-lived, and the reasoning behind them carries the real value. A contractor can design the target state, write the decision records and hand over a complete pack. The argument tends to leave with them: why the obvious option was rejected, which constraint forced the compromise, and what the design assumed about a business that has since changed. Two years later somebody is looking at a decision with no idea why it was made, and the safest assumption becomes leaving it alone.
There is a practical consideration too. Architecture carries authority, and authority in most organisations is partly a function of permanence. A contractor can win the technical argument. Holding a position against a determined executive or a vendor with a relationship at board level is harder when everyone knows the contract ends in March.
So it is usually a mix. Contract the programme, keep the ownership permanent, and make sure a permanent architect is close enough to the work to inherit the reasoning behind the design. Where you need a permanent architecture leader and cannot afford to wait, an interim while the search runs holds the standard in place and protects the quality of the eventual appointment.
Enterprise and solution architecture salaries
in South Africa.
FOR CONTRACTOR ROLES
Seniority
Indicative hourly rate
> Technical or application architect
R1000 – R1200
> Solution architect
R1100 – R1400
> Senior or lead solution architect
R1300 – R1500
> Enterprise or domain architect
R1400 – R1600
> Interim Chief Architect or Head of Architecture
R1400 – R1600
FOR PERMANENT ROLES
Seniority
Annual cost to company
> Technical or application architect
R1.4M – R1.6M
> Solution architect
R1.6M – R1.7M
> Senior or lead solution architect
R1.7M – R1.9M
> Enterprise or domain architect
R1.6M – R1.7M
> Chief Architect or Head of Architecture
R1.8M – R2.1M
Figures are drawn from Acuity’s own placements across the South African market and are indicative ranges, not quotes. Actual pay and rates vary with specific skills, sector, location and how in-demand a role is at the time. Contractor rates are excluding VAT. Last reviewed: September 2026
IF YOU'RE BUILDING A CAREER
Your career is built on what got built.
The move into architecture is usually presented as a promotion out of engineering. Treat it as a change of trade. What matters from here is getting a design built well by people who do not report to you and who are entitled to disagree with you, and that is a craft of its own.
Two engineers can make the same move in the same year and come out worth very different money, because one of them stayed close to delivery and the other drifted into governance. The market reads that difference immediately. The question in an interview is always some version of “what happened when it got built,” and it can only be answered well by someone who was there.
So the useful question about a role is what you would be accountable for and whether that accountability is real. Ask whether architecture decisions are binding or advisory. Ask who can overrule you and how often it happens. Ask whether you would stay involved through delivery or hand over at design sign-off, because that single answer determines what your CV looks like in three years.
Two things are worth building deliberately. Go deep in one area first, integration, cloud, data or ERP, because the scarce, well-paid roles in this market are asking for depth, and the breadth arrives on its own as your scope grows. Get yourself attached to something that goes live. A migration, a cutover, a platform replacement, anything with a date and a consequence. Nothing in this discipline compounds faster, and it is the one part of an architecture CV that has to be earned in production.
COMMON QUESTIONS
Enterprise architecture questions, answered.
FOR BUSINESSES LOOKING TO LEAD, BUILD & SCALE
Do we need an enterprise architect or a solution architect?
Start with the problem in front of you. A solution architect designs across the systems a specific programme touches and stays with it through to go-live, so that is the hire when something needs to be delivered. An enterprise architect works above any single programme on what the business runs, standardises, buys and retires, so that is the hire when the estate itself has become the constraint. Businesses that appoint an enterprise architect while three programmes are slipping usually find the role gets pulled into delivery within a month.
How do I tell a real architect from a senior engineer with a new title?
Ask what they designed that is now running, and who built it. A senior engineer with a new title will describe systems they built themselves. An architect will describe a design other people implemented, the parts of it that changed during delivery, and how they handled the team that disagreed with them. Both are valuable. The question is which one your role needs, because designing for other people to build is a distinct craft and it takes a few years to develop.
Should architecture report into IT or sit closer to the executive?
Ask what they designed that is now running, and who built it. A senior engineer with a new title will describe systems they built themselves. An architect will describe a design other people implemented, the parts of it that changed during delivery, and how they handled the team that disagreed with them. Both are valuable. The question is which one your role needs, because designing for other people to build is a distinct craft and it takes a few years to develop.
Our S/4HANA programme is slipping. Is that an architecture problem?
Often, and the tell is where the slippage sits. ERP programmes rarely slip on the ERP itself. They slip on the systems around it: the interfaces, the master data, the bespoke extensions built over a decade, and the cutover nobody has fully designed. If your delays are clustering there, the gap is usually integration architecture rather than ERP configuration, and those are different hires. We can help you work out which one you are short of before you commit to a search.
Can we use our system integrator's architects instead of hiring our own?
For the programme, frequently yes, and good integrator architects bring pattern experience your team will not have. What an integrator’s architect cannot do is hold a position against their own employer’s commercial interest, or carry the reasoning behind a decision into year three. The arrangement that works is a mix: use their depth for the build, keep design ownership permanent, and make sure someone who stays inherits the argument behind each decision.
Is TOGAF worth screening for?
Screen with it, decide without it. TOGAF is close to a default expectation in South African corporates and public sector work, so most serious candidates hold it, which makes it useful for narrowing a longlist and almost useless for choosing between the final three. It tells you somebody has been taught a method and passed an exam. What you are hiring for is judgement under constraint, and that shows up in what they designed, what they conceded and what it cost.
Should we hire an integration architect or a enterprise architect to support our recent acquisition?
An integration architect, ahead of an enterprise architect in most cases. Acquisition-heavy groups accumulate duplicate ERPs, CRMs and payrolls, and the immediate cost sits in the interfaces between them and in the absence of one agreed view of a customer or a product. Someone has to design that layer before a target-state roadmap means anything. This is also a strong case for contract capability, because the heaviest work is programme-shaped and has an end date
How long should we expect a senior architecture search to take?
Longer than an engineering search, because the population is small and the strongest people are employed and busy. The pace is set by how clearly the scope is defined: searches that specify the estate, the mandate and the decisions the person will own move materially faster than searches built around a list of frameworks. Where you need cover while a permanent search runs, an interim design lead protects the programme and the standard of the eventual appointment.
FOR PROFESSIONALS EXPLORING
I'm a senior engineer. How do I actually move into architecture?
Start designing things other people build, while you are still building. Volunteer for the design work on a programme that crosses more than one team, write the decisions down with the trade-offs visible, and stay attached through delivery so you see what your design did under pressure. The engineers who make this move well are the ones who learned to be persuasive before they had any authority. Talk to us about roles that carry design scope at your current level.
Is TOGAF still worth doing?
In South Africa, yes, for access. A meaningful share of corporate and public sector specs list it, so it clears a filter you would otherwise be caught in. Treat it as the entry ticket rather than the differentiator. What moves your rate is depth in one area and a record of designs that went live, and the interview will get there within a few questions regardless of what your certifications say.
Should I specialise in integration, cloud, data or ERP?
Pick the one you find genuinely interesting, because depth takes years and it is hard to fake enthusiasm for that long. On market dynamics: integration is the scarcest profile locally and unblocks the most programmes, ERP carries a dated wave of demand through the S/4HANA cycle, cloud is the broadest, and data is increasingly where AI programmes succeed or stall. Depth in any of them beats surface familiarity across all four, and breadth arrives on its own as your scope grows.
Is it better to work in-house or for a consultancy or vendor?
They build different things. Consultancy and vendor work exposes you to many environments quickly and sharpens how you present and estimate, which compounds fast early on. In-house work lets you live inside a design long enough to find out whether it was right, which is the only real feedback loop in this discipline. Many strong South African architects do a spell of each on purpose. We can talk you through how each route reads to the market at your level.
Does architecture still matter as AI takes on more of the build?
More, on current evidence. As the cost of producing code falls, the expensive decisions move upstream into what gets built, what it connects to, what data it depends on and what it commits the business to. AI tooling also accelerates the accumulation of systems, which makes the ability to simplify an estate scarcer and more valuable. The part of the job worth investing in is judgement about consequence, which is the part least affected