Admitel · system architecture & technology advisory
I help teams evaluate architecture options, reduce technical risk, and make decisions around reliability, security, cost, and long-term maintainability.
Grzegorz Kalwig — System Architect & Technology Advisor
The work is organized around architecture situations and decisions, not around selling a particular platform or technology stack.
When it makes sense: the system is becoming harder to change, reliability or cost is creating concern, or you need an architecture review before a larger decision.
What I do: examine system boundaries, dependencies, infrastructure, operational behavior, constraints, and the decisions that are creating risk.
What you get: prioritized findings, explicit risks and trade-offs, and practical recommendations with clear next steps.
When it makes sense: a team has several credible options, the consequences are hard to reverse, and the decision spans technology, cost, delivery, and organizational capability.
What I do: frame the decision, test assumptions, compare options, and make trade-offs explicit instead of reducing the problem to a tooling preference.
What you get: a clear recommendation, decision rationale, known risks, rejected alternatives, and practical next steps.
When it makes sense: an existing platform needs significant evolution, migration, modernization, or a clearer target state.
What I do: connect the current architecture, business constraints, technical debt, operating model, and transition constraints to realistic target options.
What you get: a target architecture, key decisions, transition principles, major risks, and a path that can be implemented incrementally.
When it makes sense: availability, recovery, security, identity, or failure behavior need to be designed as system properties rather than handled reactively.
What I do: analyze failure modes, dependencies, redundancy and recovery paths, identity boundaries, data flows, controls, and architecture assumptions.
What you get: architecture gaps, prioritized resilience and security recommendations, and a concrete validation plan.
Architecture work starts with the system context and constraints, then makes trade-offs visible before converging on a decision.
I have worked in IT for more than 15 years. My background developed from networking, telecommunications, infrastructure, and security into technical leadership and CTO responsibilities, then DevOps and cloud-native platforms, and ultimately system architecture.
That progression gives me a broad systems perspective backed by deep infrastructure and cloud experience. I have worked across startups, enterprise environments, and public-sector systems, including environments where reliability, security, and long-term operability are part of the architecture rather than afterthoughts.
Today my work is centered on architecture decisions: understanding constraints, making trade-offs explicit, reducing risk, and choosing structures that can evolve without making future change unnecessarily expensive. My technical depth includes AWS, Kubernetes, serverless, and DevOps, while my work increasingly spans the broader system and the decisions around it.
Public material provides a way to evaluate how I reason about architecture, operational constraints, reliability, and cloud systems before working together.
Why a service can continue meeting its SLO while architectural assumptions have already changed, and why redundancy, recovery to nominal state, monitoring, and resilience testing need separate attention.
Read the article on LinkedInAn architecture-focused look at hidden capacity assumptions, Availability Zone identity, instance constraints, and how abstraction can conceal operational risk.
Read the article on LinkedInA workload-based comparison of Aurora configurations that separates architectural and performance implications from the pricing model.
Read the benchmark on LinkedInSession history covering system architecture, cloud architecture, security, Kubernetes, serverless, and production engineering topics.
View Sessionize profileCommunity activity, speaking, and certifications support the technical track record behind the advisory work; they are not the primary offer.