Enterprise Architect interview questions

The solutions architect owns the checkout design, while the enterprise architect sets direction across the wider organization.

• The solutions architect defines the checkout components, APIs, data flows, deployment shape, and NFRs for that bounded solution.
• The enterprise architect maps checkout to business capabilities and checks its fit with shared identity, payments, data, and cloud direction.
• A decision such as using PostgreSQL for this service can stay local, but introducing a second customer master affects several systems and needs enterprise review.
• At junior level, I would own the solution artifacts and raise cross-domain impacts rather than claim authority over the whole portfolio.

I would keep ownership of the portal design but escalate the shared customer identity problem as an enterprise concern.

• I would document the three ID formats, synchronization paths, data owners, and the portal failure caused by mismatched records.
• For the portal, I could design an adapter behind a stable customer lookup API so delivery is not blocked.
• I would not declare the portal database the new customer master because that changes ownership for three existing applications.
• I would take the evidence and options to the enterprise or data architect, with the temporary adapter recorded as a risk and an ADR.

I would turn the outcome into a small capability chain before choosing applications.

• The needed capabilities are customer identification, product configuration, pricing, discount approval, quote generation, and quote delivery.
• I would mark pricing and approval as weak if sales currently waits for spreadsheets and manager email, then confirm this with two sales users.
• The two-hour target becomes a measurable outcome for the full chain, not a claim that every step needs a new system.
• Only after the map is agreed would I link capabilities to CRM, pricing, document, and notification applications.

I would replace the adjectives with measurable scenarios that the team can test.

• Performance could mean p95 page API latency below 800 ms at 200 concurrent users during the 9 AM peak.
• Availability could mean 99.9% per calendar month, with planned maintenance explicitly included or excluded.
• Reliability could include fewer than 1 failed document upload per 10,000 attempts and safe retry without duplicate files.
• I would confirm the numbers with product and operations because 99.99% availability costs more than 99.9% and may not match the portal's value.

I would maintain a short trace from the business outcome to design and verification artifacts.

• Link the four-hour outcome to requirements such as online document submission, automated tax validation, and one-step approval below $10,000.
• Map those requirements to supplier onboarding, compliance checking, and approval capabilities.
• Link each capability to the portal container, validation API, workflow service, and system of record that implements it.
• Add acceptance measures, such as 90% of complete applications finishing within four hours, so a design element can be challenged if it supports no requirement.

I would produce a verified baseline focused on decisions, not an exhaustive model.

• Interview the order clerk, support engineer, and one application owner, then observe one normal order and one failed order.
• Create an application inventory with owner, purpose, lifecycle, data, hosting, criticality, and support status for all four systems.
• Draw a C4 context or container view showing users, applications, protocols, and the nightly CSV plus two synchronous API dependencies.
• Record baseline facts such as 1,200 orders per day, a 24-hour stock delay, and 3% manual rework, with unknowns clearly marked.

The target state should show the intended behavior, responsibilities, and measurable outcome without pretending every implementation detail is settled.

• Show the inventory system as the stock system of record and the storefront as a consumer, with ownership named for both.
• Select an event or incremental API flow that can deliver accepted changes within five minutes and define retry and reconciliation behavior.
• Include target NFRs such as 99.9% update-path availability and an RPO of 15 minutes for the integration state.
• Mark transition constraints, for example keeping the nightly file for 30 days as a reconciliation control before removal.

I would compare the current and target onboarding across process, data, ownership, and automation, then turn each gap into a transition action.

• Process: map sequential handoffs and wait times from approved hire to ready employee, then compare them with a target where HR triggers identity and facilities work in parallel.
• Data: compare repeated entry of name, start date, location, role, and equipment needs with one approved onboarding record, identifying missing sources, field rules, and transfers.
• Ownership: replace fragmented queue responsibility with an HR case owner and named identity and facilities owners working to 1-day internal deadlines, with a RACI and escalation path.
• Automation and transition: replace email and manual status chasing with workflow triggers, shared status, and overdue alerts, then pilot 20 hires and expand only when at least 90% finish within 2 days with under 2% data rework.

I would use the ADM as an iterative path from scope to controlled change, tailoring the artifacts to the small platform.

• Preliminary and Phase A establish the method, stakeholders, scope, constraints, Architecture Vision, and approval to proceed.
• Phases B, C, and D describe baseline and target business, data, application, and technology architectures with gaps.
• Phases E and F group work packages, compare transition options, and produce an implementation and migration plan.
• Phases G and H govern delivery and later change, while Requirements Management keeps decisions linked to requirements throughout.

Preliminary sets how architecture work will run, and Phase A agrees what this specific effort will achieve.

• Preliminary can define the lightweight method, modeling notation, repository, decision roles, and principles such as API-first integration.
• Phase A identifies warehouse, customer service, finance, security, and product stakeholders plus their concerns.
• The Architecture Vision shows the high-level current problem, target concept, expected reduction from five days to two, scope, and exclusions.
• A statement of architecture work records deliverables, dates, assumptions, constraints, and approval for the next phases.

Phase B should describe the baseline and target business architecture and expose the business gaps.

• Baseline artifacts can show a value stream from offer accepted to productive employee, with seven manual handoffs and a five-day lead time.
• A capability map can highlight identity provisioning and equipment fulfillment as weak capabilities.
• The target process can assign HR as case owner and trigger IT and facilities work in parallel, aiming for completion before day one.
• The gap list should name missing workflow ownership, inconsistent approval rules, and absent status visibility without choosing cloud products yet.

Phase C should define the target data and application architecture needed to stop the copying.

• The data view names customer, contact, and ticket entities, with CRM as customer system of record and a business data owner.
• The application view assigns CRM to customer management and the ticketing tool to case management rather than duplicating both roles.
• A target integration exposes a customer lookup contract and passes customer_id into tickets instead of copying 18 profile fields.
• Baseline-to-target gaps include duplicate data, no stable identifier, missing API capability, and a required cleanup before cutover.

Phase D defines the technology architecture that supports the application and its quality targets.

• The baseline might be one virtual machine and one database in a single zone, creating two single points of failure.
• The target can place stateless web instances behind a load balancer across two AZs and use a multi-AZ managed database.
• Technology standards specify supported runtime, network segmentation, encryption, monitoring, backup, and Terraform modules.
• The gap output identifies the second-zone resources, health checks, database failover, and recovery test needed to meet the target.

Phase E shapes viable transition options, while Phase F turns the selected option into a sequenced migration plan.

• Phase E groups work into API contract, producer change, consumer change, monitoring, and file retirement work packages.
• It can compare direct cutover with 30 days of parallel API and file operation, including cost, risk, and business value.
• Phase F sequences dependencies, assigns owners and dates, and places contract testing before consumer cutover.
• The migration plan includes milestones such as 95% API parity by week 6, rollback criteria, and file shutdown after two clean reconciliations.

Phase G checks implementation conformance, Phase H manages later architecture change, and Requirements Management maintains traceability across both.

• In Phase G, review the deployed API against the approved contract, security controls, 500 ms latency target, and recorded ADRs.
• Record a material deviation, such as unencrypted file fallback, with an owner, remediation date, and accepted risk rather than silently changing the target.
• In Phase H, assess a new partner-volume forecast to decide whether it is a small architecture update or a new ADM cycle.
• Requirements Management links the forecast and NFR changes to affected designs, work packages, tests, and approvals.

The layers separate business behavior, software support, and infrastructure while preserving links between them.

• The business layer can show the Customer actor, Handle Return process, and Return Management business service.
• The application layer can show Returns Portal and Order Service components plus the Return Eligibility application service.
• The technology layer can show Kubernetes nodes, PostgreSQL system software, and a messaging technology service.
• Linking the layers lets a reviewer trace a customer-facing return service down to the applications and runtime it depends on.

I would choose relationships by the exact semantic statement the model needs to make.

• Use serving from the Return Eligibility application service to the Handle Return business process because the service supports that behavior.
• Use realization from the Return Eligibility application function to the application service because the behavior implements the exposed service.
• Use access from the application behavior to the Order data object, marked read-only if the viewpoint needs that detail.
• Use assignment from the Returns Application component to that function to show which active structure performs the behavior.

I would create two focused views from one model because the stakeholders have different concerns.

• The product view shows customer actors, the returns value stream, business services, key capabilities, and the applications that support them.
• The platform view shows application components, technology services, nodes, networks, and deployment dependencies across two AZs.
• Both views retain shared element identifiers, so Returns Portal means the same component in each view.
• I would omit low-level infrastructure from the product view and business motivation detail from the platform view to keep each discussion readable.

I would trace the measurable goal through business behavior to application and technology support.

• Connect the ten-minute goal and its requirement to the Refund Approval business process and Refund Management business service.
• Show the Customer Service Agent assigned to the process and the Refund Approval capability associated with the required ability.
• Model a Refund Workflow application service serving the business process, with an application function realizing that service and the Refund Workflow component assigned to the function.
• Show the function accessing Refund Case data and trace the component through its artifact and deployment node so the operational dependency remains visible.

I choose the lowest level needed to answer the review question and avoid showing all levels by default.

• Use a context diagram to agree the system boundary, users, and external systems with business and security stakeholders.
• Use a container diagram to discuss deployable or runnable units, data stores, protocols, and ownership with delivery teams.
• Use a component diagram only when the internal responsibilities of one container are unclear or risky.
• For a 30-minute kickoff, I would start with context and one container view, then add a component view for the complex integration service if needed.