How Solutions Architects Use iPhone Notes to Capture Client Requirements

Solutions architecture is client-facing technical work. You're conducting discovery sessions to understand business requirements, evaluating vendor capabilities against client needs, designing reference architectures, writing technical proposals, and presenting solutions to technical and non-technical stakeholders. The business constraint that surfaces in a client conversation, the integration complexity discovered during technical discovery, or the competing requirement that reshapes the entire architecture — these are most valuable when captured during or immediately after client interactions.

iPhone notes give solutions architects a capture layer for the high-value, time-sensitive information that emerges in client-facing work. Unlike internal engineering work where context can be reconstructed from code and tickets, client context lives in conversations — and it evaporates quickly.

Why Solutions Architects Need Mobile Notes

Solutions architecture involves managing context across multiple client engagements simultaneously. Each client has unique business requirements, technical constraints, organizational dynamics, and decision-making processes. Notes that capture this context enable seamless re-entry into any engagement after context-switching. The solutions architect who arrives at a client meeting fully briefed from their notes is far more effective than one reconstructing context from memory.

Proposals also involve a tight feedback loop between discovery and design. Requirements gathered in week one shape the architecture proposed in week two. Notes that accurately capture requirements — including ambiguities, unstated assumptions, and competing priorities — produce better proposals and fewer post-proposal revisions.

What Solutions Architects Capture in iPhone Notes

Client discovery notes: During technical discovery sessions, capture requirements with enough specificity to drive architectural decisions. "Client requires SOC 2 Type II compliance for all data storage — eliminates unmanaged cloud storage options, narrows to certified services." Include both stated requirements and implied constraints.

Stakeholder insight notes: Different stakeholders in a client organization have different priorities. Note who cares about what. "CTO prioritizes vendor lock-in avoidance. CISO prioritizes data residency. Business unit owner prioritizes time-to-value. Architecture proposal needs to address all three explicitly."

Technical constraint discovery: During architecture conversations, constraints surface that aren't in formal requirements. "Legacy ERP system uses SOAP API only — modern REST integration layer required regardless of other architecture choices." Note these constraints with the context in which they were discovered.

Competitive intelligence: Solutions architects often work in competitive sales contexts. Note observations about competitor positioning, client perceptions, and differentiation opportunities. Keep these at a level appropriate for mobile storage — general patterns, not confidential client communication.

Proposal design notes: When designing a solution architecture, note the alternatives considered and the reasoning. "Option A (managed service): faster delivery, higher long-term cost. Option B (self-hosted): more complex, lower cost at scale. Client prioritized speed — recommend Option A with cost review at 18 months."

Reference architecture patterns: Note architecture patterns that work well across client engagements. These become the building blocks of faster proposal development. "Multi-tenant SaaS with compliance requirements: separate data storage per tenant, shared compute with tenant context headers, centralized audit logging — validated across 3 similar clients."

The Solutions Architect Observation Note

For discovery findings: ``` Client context: [engagement type, not client name in mobile notes] Requirement: [what the client needs] Constraint: [what limits solution options] Priority: [must-have / should-have / nice-to-have] Stakeholder: [who owns this requirement] Implication: [how this shapes the architecture] ```

For proposal design: ``` Problem: [what the architecture must solve] Options considered: [2-3 alternatives] Evaluation criteria: [how you compared them] Recommended option: [and why] Trade-offs: [what the client is accepting] Risks: [what could go wrong] ```

For reference patterns: ``` Pattern: [architecture component or approach] Applicable context: [when this works well] Validated: [client type / engagement context] Components: [key technical elements] Considerations: [gotchas / conditions] ```

Connecting Notes to Proposal Quality

The solutions architect who captures discovery thoroughly produces proposals that feel tailored rather than templated. When proposal reviewers see their specific constraints, priorities, and stakeholder concerns reflected in the document, trust increases and revision cycles decrease. Notes from discovery sessions are the raw material for this tailoring.

A systematic note practice also builds a library of reference architectures and proposal patterns that accelerates future engagements. The architect who has captured 20 similar engagements has a much faster time-to-first-draft than one starting from scratch each time.

FAQ

Q: How do I handle confidential client information in mobile notes? A: Keep notes at a level of abstraction appropriate for mobile storage. Use engagement-type descriptors rather than client names when possible. Avoid specific financial figures, personnel information, or competitive pricing details in mobile notes. The architecture pattern and business requirement type are worth capturing; specific client identifiers belong in secure, approved systems.

Q: How do I organize notes across multiple simultaneous engagements? A: Separate notebooks per engagement type (not client-specific in mobile notes) with consistent phase labels: discovery, design, proposal, implementation, review. The phase structure makes it easy to find relevant notes when context-switching between engagements.

Q: What's the most valuable type of note to capture during a client discovery session? A: Unstated assumptions and implicit constraints — the things that are obvious to the client but not to you. These are the requirements that bite you in proposal review when the client says "but obviously we needed X." Capture them by asking probing questions and noting the answers.

Q: How do solutions architect notes differ from sales engineer notes? A: Solutions architects focus on technical design and requirements; sales engineers focus on product capability and competitive positioning. In practice, solutions architects in sales contexts capture both. Note which hat you're wearing when capturing — it affects how the note is used later.

Q: Should I capture notes about client satisfaction and relationship dynamics? A: Yes, at a professional level. "Client technical team is enthusiastic; legal team has concerns about vendor dependency — proposal needs explicit exit strategy section" is valuable context for the next interaction. Relationship dynamics shape how proposals are received and revised.

Related Reading

• /blog/cloud-architect-notes-iphone
• /blog/software-architect-notes-iphone
• /blog/cto-notes-iphone
• /blog/sales-engineer-notes-iphone

Sources

• The TOGAF Standard — The Open Group Architecture Framework
• AWS Well-Architected Framework — https://aws.amazon.com/architecture/well-architected/
• IASA Global Architecture Body of Knowledge — https://iasaglobal.org/