By David Bartas · Updated
What this work helps you decide.
Technology architecture consulting helps a team understand how its systems should connect and which design choices fit its constraints. I review system boundaries, APIs, data flows and integration options, then record a direction that the delivery team can inspect and challenge.
Which architecture fits the workflow, constraints and team that will have to run it?
What to bring.
- The business workflow and the systems it crosses
- Current diagrams, API contracts and important data flows
- Access, reliability and operating constraints
- Known dependencies, migration plans and delivery ownership
Typical deliverables.
- A system and integration map tied to the business workflow
- An option comparison with constraints, assumptions and trade-offs
- Architecture decisions and a sequence for validating and delivering them
The scope depends on your question and available context. A consultation frames the decision; a complete review, workshop or delivery engagement is scoped and quoted separately.
How I approach the work.
01
Map the current flow
Connect the customer journey to the systems behind it. Identify data ownership, interfaces, dependencies and places where a failure would affect the workflow.
02
Compare options
Review realistic integration and architecture choices against the same constraints. Record trade-offs in complexity, operating effort, delivery sequence and future change.
03
Define the contracts
Clarify responsibilities at system boundaries: inputs, outputs, permissions, errors and the information needed for support. Keep unresolved questions visible.
04
Record the decision
Leave a system map, an option comparison and a decision record. Identify the next validation step before a major implementation or migration commitment.
Related project evidence.
These cases describe project scope and personal contributions. Each links to a public product, profile or source record.
TradingAgents × Investboard
Sep 2026
An open-source connector that supplies portfolio context and records completed analysis.
Read the case study →George Business
Aug 2022 – Jun 2025
Payment lifecycle, transaction history and card reservations for Česká spořitelna’s corporate banking.
Read the case study →BankID onboarding
Jun 2021 – Feb 2022
Solution architecture and integration of BankID into MONETA’s web and mobile onboarding.
Read the case study →David Bartas is the founder of Investboard and creator of InvestingStack. His own products and ecosystem work are identified in the case studies.
Common questions.
What should an architecture decision record contain?
An architecture decision record should explain the problem, relevant constraints, options considered, chosen direction and consequences. It should also record unresolved assumptions and the evidence or review that could justify changing the decision later.
Can the review focus on one API or integration?
Yes. A focused review can cover one integration or customer journey. Bring the system context, current contracts, failure cases and the decision you need to make. Wider architecture work can be scoped separately if the review reveals dependencies beyond that boundary.