Service support overview
Technology decisions are not made simply by lining up product features side by side. Data volumes, compliance requirements, retention periods, and the team that will run the system—an architecture drawn while these premises remain vague falls apart at implementation.
We pin down the premises before we answer. Then we verify by running it on real systems.
By holding firmly to both, we support technology decisions whose rationale you can explain later.
From design reviews and independent architecture assessments to technical validation at the proposal stage and evaluation of modernization approaches,
we step in at whatever phase your project is in, at exactly the depth you need.
Defining
Premises
Requirements & constraints:
data volume / compliance / retention /
assumed vs. confirmed values
Hands-on
Validation
PoC & technical validation:
measuring and comparing approaches /
identifying what cannot be done
Where both overlap = verify first, then answer
Premises before answers
We don't sketch an architecture the moment we receive a question. We first confirm the premises that shape the design—data volume, compliance requirements, retention periods, the state of the existing environment—and separate assumed values from confirmed ones before we begin. When the premises shift, so does the answer.
Costs built up element by element
We never present a total alone. We break costs down into billing elements—ingestion, storage, reads, transfer, key management—and mark anything we cannot fill in as "unconfirmed." For architectures that scale in stages, we also estimate at the post-expansion scale.
Implementation with specialist teams
When implementation is required in modernization, cloud, SaaS / identity platforms, AI, or security, we work with our in-house technical teams to support you seamlessly from evaluation through execution.
Establishing premises × verifying on real systems
= technology decisions
you can explain
Areas we support
Technical questions never arrive in the same form. "Is this architecture sound?" "Which of these two should we choose?" "Will this approach really work?"
How we verify depends on the shape of the question.
We combine the following six areas at the depth you need. We cover everything from short-term technical assessments to engagements spanning several quarters.
-
Technical consultation & design review
— It starts with aligning the premises
We answer specific technical questions. For focused consultations—on whether an architecture is sound, how to choose a service, or the basis for configuration values—we begin by confirming the premises. Because cloud service specifications keep changing, this includes examining what newly added features in the services you use mean for your organization, and advising whether any action is needed. Our answers come with their rationale, and anything not yet confirmed is clearly marked as unconfirmed.
- A premise checklist, separating assumed values from confirmed ones
- Review of architecture and configuration soundness, with improvement proposals
- Assessment of how new features and specification changes in your services affect you
- Answers delivered with unconfirmed items clearly separated
-
Independent architecture assessment
— Checking the design with outside eyes
We assess existing designs and vendor-proposed architectures from an independent, third-party perspective. We identify gaps in non-functional aspects such as scalability, availability, and maintainability, and present each finding together with its scope of impact. The subject of assessment is the system's architecture (its technical structure).
- Identifying how well non-functional requirements are met, and where gaps remain
- Assessing the technical feasibility of vendor proposals and the validity of their assumptions
- Organizing findings by scope of impact and response priority
-
Option comparison & technology selection
— Spelling out even what it can't do
We compare multiple approaches and products against the same evaluation criteria. Our comparisons make clear not only what each option covers, but also what it cannot cover. Where gaps are to be filled by dividing roles, we show the combination that does so. The scope goes beyond infrastructure to company-wide SaaS, identity platforms, business tools, and how functions are divided with existing applications. We treat the major options side by side, without favoring any particular cloud or product.
- Defining evaluation criteria and comparing approaches, products, and SaaS side by side
- What each option cannot cover, and the combinations that fill those gaps
- Dividing functions with existing applications and setting a usage policy
- The recommended option and its rationale, plus why the others were not chosen
-
PoC & technical validation
— Run it, verify it, then answer
We verify on real systems the questions that specifications on paper cannot settle. Because validation runs in our own environment, we can start without waiting for you to prepare yours. Before we begin, we lay out the objectives, items to verify, costs, and how the environment will be cleaned up afterward. In the results, what did not work is recorded with the same weight as what did.
- Designing validation objectives, items to verify, and completion criteria
- Hands-on verification in our own environment (with cost estimates and cleanup steps provided up front)
- Reporting measured results (both successes and failures, and what they tell us)
-
Evaluation of modernization approaches
— Will that approach really work?
We evaluate approaches for renewing existing systems. We verify which of rehosting, refactoring, or rebuilding is technically viable—including whether conversion tools can be applied. Our role is not to decide whether to modernize, but to determine whether the chosen approach will hold up.
- Understanding the state of current assets and judging the applicability of each approach
- Separating what automated conversion tools can cover from what remains manual work
- Phased migration scenarios and the risks that remain at each stage
-
Validation of cloud architecture & cost design
— Verified by element, not by total
We verify that your cloud architecture is neither excessive nor insufficient for your requirements. We evaluate the major clouds against the same criteria, build up costs by breaking them into billing elements, and identify early which elements will dominate as scale grows.
- Validating architecture soundness (whether availability, performance, and operability are balanced against requirements)
- Evaluation starting from a minimal configuration (confirming whether existing features meet requirements before adding more)
- Cost estimates broken down by billing element, re-estimated at expanded scale
- Identifying easily overlooked billing elements and opportunities to reduce costs
These six areas are not sequential steps.
You can start from a design review or from validating an approach.
We set the starting point according to the shape of your question, and provide only the depth you need.
How we divide roles with other services:
Where to invest is handled by IT / Digital Strategy, and the business and system concept for a given theme by System Planning & Concept Design.
This service steps in when you need to confirm whether it can actually be achieved with the technology.
Methodology & evaluation framework
Technical questions can easily be answered on rules of thumb in the moment. That is exactly why we have fixed the way we answer as a defined procedure.
Pin down the premises, break things down into elements, verify on real systems, and check from a different perspective.
By following these four steps every time, we deliver answers of the same quality no matter who is in charge.
Premise
Answer only after fixing the premises
We first confirm the premises that shape the design—data volume, compliance requirements, retention periods, the existing environment. When we proceed on assumed values, we state clearly that they are assumptions.
Breakdown
Build up from the elements
Costs and effort alike are built up from their elements rather than given as totals. Elements we cannot fill in are not left blank, but recorded as "unconfirmed."
Evidence
Verify on real systems
Questions that specifications cannot settle are verified by actually running them. What could not be done is also recorded and treated as input for the decision.
Cross-check
Check from a different perspective
We don't stop at the author's own review; every deliverable passes through a review from an independent perspective before submission. A second look from the same perspective leaves the same oversights in place.
Certainty of premises
We distinguish how far premises on volume, requirements, and timeframes are actually confirmed. Never treating the unconfirmed as confirmed is the foundation of any technology decision.
Freshness and accuracy of facts
We check for renamed services and the versions of standards and frameworks. Outdated names, or claims of "compliance" without a version, do not stand as evidence.
Handling the unconfirmed
We never mix items awaiting confirmation with answered content. We deliver in a form that makes clear what has not yet been decided.
Deliverables
We structure the results of our technical review so that everyone from executives to the front line can share the same understanding.
Each deliverable makes clear "what to choose and why," and carries implications that lead to your next decision.
Premise checklist
A list of the premises that shape the design, distinguishing assumed values, confirmed values, and items still unconfirmed.
Option comparison and rationale for the recommendation
Multiple options laid out against the same criteria, including what each cannot cover—along with the rationale for the recommendation and why the others were not adopted.
Element-based cost estimate
An estimate built up by billing element. For architectures that scale in stages, figures at the post-expansion scale are shown alongside.
PoC validation report
Results of hands-on verification. What worked, what did not, and the conclusions they support—all given equal weight.
Support style
We don't answer right away—
we verify first, then answer
In technology, there is no right answer that fits every company. That is why Dirbato supports your technology decisions with a commitment to pinning down the premises before answering and verifying on real systems before advising, and a co-creative, hands-on partnership that stands on the buyer's side and steps in at the right phase, at the right depth.
Evidence
Verified by premises and real systems
We don't answer right away.
Fix the premises, then design
Rather than sketching an architecture right away, we start by confirming the premises that shape the design.
Validate on real systems, then answer
Questions that specifications cannot settle are answered with the results of actually running them.
State what can't be done, too
We write down what each option cannot cover, and show the combinations that fill the gaps.
Major clouds, one standard
Without favoring any particular cloud or product, we compare them side by side on the same criteria.
Partnership
Co-creative, hands-on partnership
When you need it, at the depth you need.
From quick assessments to long-term support
We design the depth and duration of our involvement to match the size of the question.
Evaluating from the buyer's side
Using your requirements as the yardstick, we candidly assess the feasibility of proposals and architectures.
Start from any phase
Whether you are still planning, in design, or already in operation, we start from the question in front of you.
Implementation with specialist teams
For implementation in modernization, cloud, SaaS / identity platforms, AI, and security, we support you in collaboration with our specialist teams.
Why clients choose Dirbato
We don't stop at handing over a technology comparison table. We pin down the premises, verify on real systems, and leave a rationale you can explain later.
And we support you as a co-creative, hands-on partner until you can make technology decisions on your own.
Advice from engineers who implement
Consultants who shape the concept and engineers who actually build systems work under the same roof. Our advice is based not on catalog comparisons but on our own experience building and operating systems. Another strength is our ability to evaluate across the major platforms without favoring any particular cloud.
Verified in our own environment before we answer
For questions where judgments diverge, we stand up a validation setup in our own environment and actually run it—no need to wait for you to prepare an environment. We present the costs and cleanup steps before we begin, and answer with measured results.
We state what can't be done
We never omit inconvenient facts to get a proposal approved. We present our recommendation only after writing down what each option cannot cover, the risks that remain, and what is still unconfirmed. Even for architectures we proposed ourselves, if validation reveals problems, we report them as points to correct.
Independent assessment from the buyer's side
Using only your requirements as the yardstick, we assess the feasibility of existing designs and vendor proposals. Each finding comes with its scope of impact and response priority, delivered in a form you can use to make decisions.