Workflow: Macroscope Intake (Conditional)

Owner: Camille (Client Intake Manager) Frequency: Per engagement (when triggered by decision rule) Type: Sub-process of Stage 1 (Client Intake) in the digital talent production line

Overview

Macroscope is created for enterprise/complex engagements to establish a shared vision and context before design begins. This lightweight workflow sits inside Stage 1 (Client Intake) and outputs a macroscope document that Elena (Enterprise Architect) consumes during Stage 2 (Requirements & Solution Design).

Discovery Call → Decide: Macroscope Needed? → YES → Capture Macroscope → Validate → Elena Consumes
                                           → NO  → Continue Normal Intake

Decision Rule: Is Macroscope Needed?

Apply this rule during the Discovery Call (Camille's Stage 1 intake conversation with client).

Create a Macroscope When ANY of These Conditions Apply

Enterprise-wide scope
- 50+ end users, OR
- Affects multiple departments/business units, OR
- Organization-wide transformation initiative
Regulated environment
- ISO 27001, SOC 2, HIPAA, GDPR, or other compliance framework
- Financial services, healthcare, government sectors
Complex integrations
- 3 or more systems/APIs to integrate with, OR
- Custom data pipeline, OR
- Real-time synchronization requirements
Strategic/transformational use case
- Not a tactical tool or quick automation
- Intended to change how the organization operates
- Long-term strategic initiative
Client operates with EA/architecture governance
- Client has an enterprise architecture team or CTO
- Client follows a formal methodology (TOGAF, Zachman, etc.)
- Client requires architecture alignment/approval

Skip Macroscope When

Pilot or proof-of-concept (scope is intentionally limited)
Single user or small team tool (<10 users)
Well-defined narrow scope with no architectural implications
Tactical automation or simple process optimization
Client doesn't have architectural governance structure

Steps

1. Discovery Call — Apply Decision Rule

When: Early in the conversation (first 10 minutes of discovery call)

Action:

Listen for scope clues: org size, user count, integrations, regulatory mentions
Ask the decision-rule questions if signals suggest macroscope might be needed
Document the decision in the intake record: "Macroscope: YES / NO"

If NO: Continue with normal intake process (skip to Step 4)

If YES: Proceed to Step 2

2. Capture Macroscope

When: During requirements gathering (Stage 1, after discovery call)

Action:

Walk through the macroscope template (macroscope-template.md) with the client
Fill in all sections — mark items as TBD if the client needs time, but track them
Spend time on Vision, Operating Context, and Success Metrics (these shape everything)
For Methodology & Frameworks, note what the client uses (ask directly)
Capture Open Questions — don't assume you know the answers

Artifact: Draft macroscope (stored temporarily in intake record)

Duration: 30-60 minutes of client time, spread across discovery + requirements conversations

3. Elena Validates (Draft)

When: After macroscope draft is complete, before approval

Owner: Elena (Enterprise Architect)

Action:

Elena reviews the draft macroscope for clarity and completeness
Flags gaps: missing integrations, unclear vision, vague operating context, etc.
Asks Camille to clarify or fill gaps with client
Does NOT design yet — validation only

Output: Comments/feedback to Camille

Turnaround: 1-2 business days

4. IT Architecture Team Validates (Final)

When: After Elena's feedback is incorporated

Owner: Elena + Ada (IT Architecture Team, if needed)

Action:

Final review of the macroscope for architectural soundness
Ensure all sections are populated and unambiguous
Confirm framework choice is appropriate for the context
Sign off: "Approved for Elena to design from"

Output: Approved/rejected status

Gate: Macroscope must be approved before Elena begins design

5. Macroscope Moves to Order Folder

When: After approval

Action:

Move/copy the macroscope to production-lines/orders/{order-slug}/macroscope.md
Reference the template: # [Client] Macroscope (based on macroscope-template.md)
Link it in the order's README or index

6. Elena Consumes in Stage 2

When: Elena begins Stage 2 (Requirements & Solution Design)

Owner: Elena (Enterprise Architect)

Action:

Elena reads the approved macroscope
Produces architecture documentation FROM the macroscope:
- System design and boundaries
- Integration architecture
- Data flow diagrams
- Technology stack recommendations (aligned with framework)
- Architecture decision records (TFD)
IT Architecture Team validates Elena's design against the macroscope

Output: Architecture documentation stored at production-lines/orders/{order-slug}/design/

Quality Gate

The macroscope is complete when:

Decision rule applied (Macroscope: YES or NO recorded)
If YES: All template sections populated (no unresolved TBDs)
Client understands and has implicitly signed off on the macroscope
Elena has reviewed and flagged no critical gaps
IT Architecture Team has approved
Moved to order folder and linked in intake record

Time & Effort

Step	Owner	Time	Notes
Decision rule	Camille	5 min	Part of discovery call
Capture	Camille + Client	45 min	Spread across conversations
Elena validation	Elena	2 hours	1-2 day turnaround
IT Arch validation	Elena + Ada	1 hour	Overlaps with Elena validation
Move to order folder	Camille	5 min	Housekeeping

Total factory effort: ~3-4 hours per engagement (mostly Elena)

Examples

When Macroscope Was Created

STM Enterprise Architect — Enterprise-wide scope (multiple teams), architecture governance model, strategic transformation

When Macroscope Was NOT Needed

[TBD — first pilot/POC engagement] — limited scope, proof of concept, minimal integration

This workflow is intentionally lightweight. It's a decision gate + template, not a separate production line. Macroscope is a shaping artifact, not a deliverable.