Solutions Architect

I start by separating what the stakeholder is asking for from the problem they are actually trying to solve, because those two things diverge more often than people expect. I run discovery sessions with the actual users of the system, not just the sponsor, and I capture requirements against a simple template covering the business capability needed, the current pain point, and the measurable outcome that would prove success. Then I build these into a requirements traceability matrix that links each business need to a specific architectural component, so nothing gets built without a clear justification. For non-functional requirements I push stakeholders for numbers instead of adjectives: a defined response time under a defined load rather than 'fast', a named compliance standard rather than 'secure'. I write assumptions and constraints into an architecture decision record before I start drawing diagrams, because most disputes later in the project trace back to an assumption nobody wrote down. And I always review the draft architecture with the technical team and the original stakeholder before it is finalised, since a design only the engineers understand has already failed at the translation step.

Non-functional requirements are usually the first casualty of a tight deadline, so my job is to make that trade-off visible rather than let it happen by default. I score each one against business impact and the cost of retrofitting it later: a security control that is expensive to bolt on after launch stays protected even under time pressure, while a performance target with headroom to improve post-launch can reasonably be phased. I present this as a menu to stakeholders rather than a technical veto, laying out the full scope, what we can defer without materially increasing risk, and what cannot move without sign-off from someone with the authority to accept that risk. I have watched teams quietly drop encryption at rest or audit logging under deadline pressure because nobody framed it as a decision that needed sign-off, and it surfaces months later as a compliance finding that costs far more to fix retroactively than it would have to build properly the first time. I also run a short NFR checklist at every design review so these trade-offs get raised early, not discovered during the first security audit after go-live.

I treat this as a total cost of ownership question first and a technical preference second. Custom build earns its cost when the capability sits close to what actually differentiates the business, and an off-the-shelf option would force a compromise customers would notice. Buying makes sense for commodity capability where the market already has mature, well-supported options: building it internally usually just reinvents a solved problem, and worse than the vendor who does nothing else all day. Integrating what the organisation already owns is normally the right first move when existing licences or infrastructure cover most of the requirement and a new platform cannot be justified against the marginal gap. I run a weighted scoring model across cost, time to value, vendor lock-in risk, and maintenance burden, and I always fold in the people cost of running whatever we choose, because a cheap platform that needs a specialist team to operate isn't actually cheap. I present the trade-offs with numbers attached rather than a bare recommendation, since the final call usually sits with a budget owner, not with me.

I keep two versions of every architecture artefact: a detailed technical view for engineers, usually a C4-style diagram down to the container or component level, and a simplified narrative view for business stakeholders that shows data flow and system boundaries without implementation detail. For executive audiences I lead with the business outcome and the risk being managed, and only bring in a diagram if someone asks how, never as the opening. I have learned to catch jargon that sounds precise to me but means nothing outside engineering, so before an important presentation I test the explanation on a colleague from another function. I keep architecture decision records for every significant choice too, written in plain language with the context, the options considered, and the reasoning, so six months later nobody has to reconstruct a decision from a Slack thread. When I disagree with a stakeholder's preferred direction, I lay out the trade-offs in a comparison table rather than argue the point, which keeps the conversation on the decision instead of on who is right.

I was designing the integration layer for a retail client connecting a new order management platform to their existing warehouse system. Midway through implementation we discovered the warehouse system's API had an undocumented rate limit that made our planned synchronous integration pattern unworkable during peak order volume, something that had not shown up in the vendor's documentation or our initial technical discovery calls. Rather than trying to negotiate a rate limit increase the vendor could not commit to, I redesigned the integration to an event-driven pattern using a message queue, buffering orders during peak periods and processing them asynchronously with the warehouse system, with a status callback to keep the order management platform updated. This added roughly two weeks to the timeline, which I communicated immediately with the revised architecture and the reasoning, rather than trying to absorb the delay quietly. The client accepted the delay once they understood the alternative was an unreliable system during their highest-volume periods. The lesson I carry forward is to explicitly test rate limits and throughput assumptions during discovery rather than trusting vendor documentation at face value.

A sales director had already told a client our platform could support real-time bidirectional sync with their ERP inside a six-week implementation window, based on a conversation I was not part of. The client's ERP was a heavily customised on-premise system with no modern API, and real-time bidirectional sync would have meant either a custom connector with significant ongoing maintenance risk, or a middleware layer that had no realistic chance of being built and tested in six weeks. I put together a short technical brief for the sales director showing the actual integration options, the realistic timeline for each, and the maintenance burden of the fastest one, then proposed a phased alternative: batch synchronisation within the six-week window as a first release, with real-time sync as a defined second phase once we had proven the connector in production. I framed it around protecting the client relationship rather than blocking the sale, since an over-promised real-time integration that broke in production would have done far more damage than a realistic phased commitment. The sales director took the phased proposal to the client, who accepted it without pushback.

I designed an API gateway layer meant to let three business units share a common set of backend services instead of each maintaining its own duplicate integrations. Technically it worked exactly as specified, but eighteen months later adoption was low: two of the three business units had built their own point-to-point integrations anyway, because the shared gateway's change process ran through a review board that added, on average, three weeks more than teams were willing to wait. The architecture itself was sound, but I had not designed the governance around it, and the slow approval path pushed teams straight back toward the fragmented pattern I was trying to remove. I learned that a shared platform is only as good as the operating model wrapped around it: who can request a change, how fast, and who owns the backlog. On later projects I now design the governance and SLA for any shared platform alongside the technical architecture, and I treat a slow change process as a design flaw as serious as a scalability gap, because it produces the same outcome: teams routing around the system you built.

I start by profiling the legacy system: what interfaces it actually exposes, whether it has a usable API or only database-level or file-based access, and its realistic throughput and availability under load. If it only exposes a database, I avoid connecting directly to production tables from the cloud side and build an anti-corruption layer instead, typically a small service that owns the translation between the legacy data model and the SaaS platform's expected schema, so a change on either side does not ripple straight into the other. For the connectivity pattern I default to an iPaaS layer such as MuleSoft, Boomi, or Azure Integration Services rather than point-to-point custom code, since it gives centralised monitoring, retry logic, and error handling out of the box, and is far easier for a client's internal team to maintain after handover. I favour asynchronous, event-driven integration wherever the business process tolerates eventual consistency, using a message queue to decouple the systems and absorb an outage on either side without losing data. And I always include a reconciliation job that compares record counts and key fields between the two systems on a schedule, because integration bugs that lose or duplicate records are the hardest class of failure to catch from application logs alone.

I work through a standard checklist covering performance, availability, security, scalability, maintainability, and compliance, and for each one I insist on a measurable target rather than a qualitative statement. For performance that means a specific response time at a specific percentile under a specific concurrent load, not a promise that it 'should be fast'. For availability, an explicit uptime target tied to the business cost of downtime, which then decides whether the architecture needs active-active redundancy or a simpler single-region design with a documented recovery time. I document all of this in an NFR matrix alongside the source of the requirement, so a target that came from a regulatory obligation is clearly distinguished from one that is just an internal preference, because the two get very different treatment when trade-offs come up later. I also flag which NFRs are binding constraints and which are targets with negotiable headroom, since treating every requirement as equally fixed is what causes unnecessary over-engineering. I revisit the matrix at each major milestone, because requirements set at the start of a project on early assumptions about scale or usage usually need revising once real usage data exists.

I run vendor evaluation as a structured process rather than a preference exercise, starting with a weighted scoring matrix covering functional fit, integration effort, total cost over a three-year horizon including implementation and support, vendor stability, and the cost of exit if we ever need to migrate away. I always ask for a proof of concept against our actual integration requirements rather than relying on a vendor demo, because demos are built to hide exactly the friction points that matter to us. I check the vendor's API documentation and rate limits myself rather than taking a sales engineer's word for it, since that is where I have been burned before on timeline estimates. For any vendor holding sensitive data, I review their security certifications and data residency options against our compliance requirements before commercial terms are even discussed, because a vendor that fails on compliance is disqualified regardless of price. And I weight exit cost heavily: a platform that is cheap to adopt but expensive to leave, because of proprietary data formats or a lack of export tooling, carries a hidden long-term cost that rarely shows up in the initial business case but has burned every client I have worked with who ignored it.