Software Architecture Unveiled: A Series by Igor Fraga

Hi everyone, Igor Fraga here. This is the second article of these series to unveil the challenges and the role of what we do as a Software Architect. We are going to understand more about one of the key aspects of this role that is translating business into technical solutions. Here is where we start to draw from ideas, goals into a plan to build a concrete system that accomplishes it’s goal.

Business leaders speak in goals. Developers think in systems and constraints. A software architect stands in the middle, turning goals into a clear, realistic plan the team can build. This work is not about fancy words—it’s about questions, choices, and shared understanding, and keep this word, UNDERSTANDING.

This work unfolds over a focused week with questions, experiments, and decisions. Here, I’m bringing how this process looks like, sometimes even more than a week depending on time responses and availability from the parts in my experience with these processes.

Let’s explore this process with the story of the development of a real-time tracking feature:

Monday — Framing the Goal

9:00 AM. A product manager, Laura, brings a request:
“We need a new mobile feature: instant order tracking. Customers should see the courier on a map in real time. This will help retention and reduce support calls.”

This is a goal with a suggested solution. As an architect, the first step is to separate the goal from the implementation.

  • Business goal: improve retention and reduce support.
  • Hypothesis: real-time tracking will help.
  • Initial solution idea: show courier location on a live map.

I respond with curiosity, not with code:

  • What metrics will define success? (Retention + fewer support calls)
  • What is the deadline and why? (Marketing campaign next month)
  • Which user segments need this first? (Returning customers? All?)
  • What are the legal or security constraints? (Location data handling)

Defining success early avoids building the wrong thing fast.

By the end of the day, we agreed on success metrics:

  • Reduce delivery-status support tickets by 30% in 60 days.
  • Increase repeat purchase rate by 10% among users who use tracking in 90 days.

We aligned on a realistic plan: discovery and design this week; delivery planning next.

Tuesday — From Wish List to Requirements

We run a discovery session with product, design, support, and engineering leads. I guide the conversation to transform the “wish list” into actionable requirements.

We write the first version of the requirements as simple statements:

  • Must-have
    • Show order status updates within 10s of change.
    • Provide a map pin for courier location updated every 15–30s.
    • Work on iOS and Android with the same API.
    • Respect user privacy and allow opt-out of location sharing.
    • Provide helpful fallback when courier location is unavailable.
  • Nice-to-have
    • Precise route line on the map.
    • Push notifications for major status changes.
    • ETA predictions.
  • Out of scope (for now)
    • Live chat with courier.
    • Historical route playback.

Now we have clarity. Not perfect, but enough to start technical exploration.

The Right Questions

Before picking technologies, the architect validates constraints:

  • Data source: Do we get courier GPS from partners or our own app?
  • Frequency vs. cost: How often do we really need updates?
  • Scale: Peak concurrent tracked orders? Expected QPS (queries per second)?
  • Offline behavior: What happens when the app loses connectivity?
  • Privacy: How long do we store location data? Who can access it?
  • Failure modes: What do users see if couriers’ apps stop sending updates?

These questions prevent hidden risks from appearing late.

By the end of Tuesday, we had a refined requirement set and a risk list to guide the architecture.

Wednesday — Options and Trade-offs

I sketch three approaches and discuss trade-offs with the team.

Option A: Pure Pull (Client Polling)

  • Mobile app fetches tracking data every 15–30s.
  • Pros: Simple, easy to cache, lower server complexity.
  • Cons: Less “instant,” wasted requests when nothing changes.

Option B: Server Push (WebSockets or SSE)

  • Persistent connection for pushing updates in near real time.
  • Pros: Responsive, fewer unnecessary requests.
  • Cons: More complex infra, connection management, scaling challenges.

Option C: Hybrid (Push for status changes, Pull for location)

  • Push major status changes; poll for location at a steady cadence.
  • Pros: Good balance of cost and responsiveness; simpler than full push.
  • Cons: Slightly more moving parts; needs clear client logic.

Given the deadline and the need for predictable costs, we choose the Hybrid approach for version 1. It gives a “live” feel without building the most complex system first.

Thursday — The Concrete Design

We convert the chosen approach into a concrete, testable design.

  • Mobile App
    • Poll location every 20s when the tracking screen is open.
    • Receive push notifications for major status changes (picked up, near destination, delivered).
    • Cache last known location for 2 minutes to handle brief drops.
    • Show clear states: “Waiting for courier data,” “Last updated Xs ago.”
  • Backend Services
    • Tracking API: GET /orders/{id}/tracking returns location, status, ETA.
    • Event Service: publishes status-change events to push notification service.
    • Integrations: adapters for courier partners; standardized internal model.
    • Rate limiting and caching to protect core systems.
  • Data
    • Store current location and last N updates (e.g., last 15 minutes) for troubleshooting.
    • Anonymize or delete precise location after retention window.
    • Audit logging for access to location data.
  • Security & Privacy
    • Auth: only the authenticated buyer (or support with permission) can access tracking.
    • Opt-out and consent flow for sharing location.
    • Clear privacy policy and retention period.
  • Observability
    • Metrics: update latency, API p95 latency, error rates, connection failures.
    • Logging: anonymized tracing across adapters.
    • Alerts: spikes in failures from any courier partner.
  • Fallbacks
    • If live location is missing, show last known point with timestamp and a helpful message.
    • If partner API is down, degrade gracefully: show status without map and notify support.

Friday — Delivery Plan, Risks, and Alignment

In the morning, along with the development team, we’ve turned the design into a delivery plan we could trust.

Milestone 1 (1–2 weeks):

  • Tracking API with mock data.
  • Mobile UI skeleton with polling and fallback states.
  • Push notification path for status changes.

Milestone 2 (2–3 weeks):

  • Integration with one courier partner.
  • Caching, rate limiting, and basic observability.
  • Privacy and consent flows in the app.

Milestone 3 (2 weeks):

  • Add a second courier partner and resilience handling.
  • Performance tests at expected peak.
  • Feature flag rollout to 10% of users.

We reviewed the risks and how we mitigate them:

  • Partner instability: contract tests, synthetic monitoring, circuit breakers.
  • Mobile background limits: adaptive polling; clear UX when the app is backgrounded.
  • Cost creep: usage caps, alarms, and tuning the polling cadence based on real usage.

In the afternoon, we ran an alignment session. I present a one-page architecture brief and two diagrams:

  • Context diagram: users, mobile apps, backend, partners, notifications.
  • Sequence diagram: user opens tracking screen → app polls → backend fetches → returns → status change triggers push.

I close with a simple story: “Maria orders dinner on the way home. She opens the app and sees ‘Picked up 3 minutes ago’ and a map pin moving every 20s. If the courier app pauses, Maria sees ‘Waiting for live data—last update 45s ago.’ She still feels informed. Support calls drop. Marketing has a solid feature to promote.”

The team nods. We have clarity, boundaries, and a path to value.

Reusable Toolkit: Questions and Templates

Keep these handy for future translation work:

  • Business Questions
    • What specific outcome do we want? How will we measure it?
    • What is the real deadline and why?
    • Which user group gets this first?
  • Technical Questions
    • What are the data sources and their reliability?
    • What are the scale and cost targets?
    • What privacy/security requirements apply?
  • Definition of Done
    • Functionality meets must-haves.
    • Observability in place (metrics, logs, alerts).
    • Privacy and security checks complete.
    • Rollout plan with feature flags and fallback.
  • Lightweight Artifacts
    • One-page architecture brief.
    • Context and sequence diagrams.
    • Risk list with mitigations.
    • Success metrics and tracking plan.

Final Thought

An architect’s value is not just in knowing frameworks or patterns. It is in making the path from idea to impact clear, safe, and achievable. By asking the right questions, shaping scope, and choosing balanced designs, architects turn big business goals into technical steps that teams can deliver with confidence.

We have seen a happy path of an architectural process to translate business into technical solutions. Most of the times, there are more back and forward on the definitions than explained here but the overall well established process looks much like this.

From my personal experience, many times I’ve been the architect and the development team, specially in startups, and other times, on bigger companies, I’ve worked with teams dealing with well defined roles as presented in this article, that is the ideal.

Both of these can happen to you, specially in the AI era where businesses believe that this tool is the holy grail and will solve everything magically (and that is not true at all) but you must need to know how to use it at your favor without any doubt of it.

Being a Software or a Solutions Architect is also to make business understand and participate of this process as much as possible, speaking on their own language.

That’s why my next article is about “The Communication Challenge: Speaking Multiple Languages“ and how you communicate with the Project Manager, the CEO, CTO and the development team is completely different and that is KEY to your success as a Software Architect.

See you on the next article!