Lars Barkman

A coherent metamodel for a Digital Enterprise Operating Model—connecting context, products, organization, capabilities, processes, information, digital solutions, assets, and governance without reducing the enterprise to a hierarchy of boxes.

The enterprise-service taxonomy divides first by delivery mechanism, then by primary consumer and promised capability across Digital and Human-Delivered Services.

Human involvement in a digital service can mean three different things — restoring a broken promise, extending it for one customer, or building capability outside it entirely — each with different economics and management responsibilities.

Four recurring digital-service types — Customer-Facing, Business-Enabling, Platform, and Infrastructure — classified by primary consumer and promised capability, and how the DSLC Model varies its approach according to service purpose.

A seven-layer model — Offering, Interface, Application, Platform, Virtualization, Hardware, Data Center — for understanding what a digital service offers, how it is consumed, why its boundary can stop at any layer, and how commercial labels like SaaS, Paa…

A file-first architecture for market analysis: Parquet as the authoritative data layer, DuckDB for SQL queries, and versioned JSON and YAML for application state — plus the consistency boundaries that determine when a catalog like DuckLake becomes worthwh…

Choosing the Python web framework for the RST Platform's human interface: server-rendered HTML, HTMX for server interaction, and Alpine.js for browser-local state, with HTMX and Alpine kept independent of whichever framework is chosen.

A principle from I Took Self-Hosting Too Far turns out to generalize well beyond infrastructure: own what needs to be durable, control what needs to be portable, rent what is genuinely replaceable.

A follow-up to Self-Hosting My Repositories and Sites: the repositories and pipelines stay self-hosted, but serving the static output myself added a server to maintain without a matching sovereignty benefit.

After building documentation for the Digital Solution Lifecycle Model on Astro Starlight, I realized I wanted to own the presentation layer rather than configure around a theme.

Garrul's maintainer corrected three things in my comment system evaluation — a feature I marked as missing that was there all along, a gap since closed, and an operating cost I overstated.

The TLD and availability decision for dehsomodel — the DEHSO Model's domain name, decided from the outset on the same logic as the DSLC Model's.

The follow-up to choosing a host: what it actually takes to run Forgejo per area, wire it to Cloudflare through Wrangler, and serve self-hosted sites behind a CDN using the RAD Stack's ingress layer.

Hands-on development on the DEO Platform — adapting the tooling to the way your organization is actually structured and governed.

Tooling that makes the DEO Model practical to run — turning operating design from a document into something an organization can actually operate.

Teaching a management team the DEO Model and getting them exercising it on real decisions — applied to your actual organization, not generic leadership development.

For organizations where the DEO Model does not quite fit — reshaping the model to your specific organizational context without losing the discipline that makes it work.

A model for engineering the operation of digital enterprises of human scale.

Stepping in as solution architect — designing the architecture, leading the technical decisions, and staying hands-on through delivery.

For traders already running the RST Platform who need to go further than the foundation reaches — hands-on development on your deployment.

A self-hosted systematic trading platform for retail traders, just starting development — data, strategy, execution, and risk as one coherent system you own and control, with no vendor lock-in.

The knowledge that defines how retail systematic trading should be done — treating trading as a disciplined, repeatable process rather than a series of discretionary decisions.

Stepping in as enterprise architect — clarifying ownership, shaping the operating model, and making the structural decisions that unblock delivery.

Hands-on development on the DSLC Platform — adapting and extending the tooling to fit how your organization actually delivers.

Unix-philosophy tooling that makes the DSLC Model practical to run, progressively automating the work machines can own.

Teaching a delivery team the DSLC Model and getting them running it on their own portfolio — classification, ownership, and process applied to real work, not generic capability building.

For organizations where the DSLC Model does not quite fit — adapting its classification tiers, capability sets, and processes to your specific delivery context.

An opinionated engineering model for digital service life cycle management — how the work should be done, from first design through the day-to-day practice of running it reliably.

Hands-on development on the DEHSO Platform — adapting the tooling to the way your organization is actually structured and governed.

Tooling that makes the DEHSO Model practical to run — turning operating design from a document into something an organization can actually operate.

Teaching a management team the DEHSO Model and getting them exercising it on real decisions — applied to your actual organization, not generic leadership development.

For organizations where the DEHSO Model does not quite fit — reshaping the model to your specific organizational context without losing the discipline that makes it work.

A model for engineering the operation of digital enterprises of human scale.

Where should the public parts of my work live — on Codeberg, on GitHub, or on my own infrastructure?

A structured look at how releases get numbered — SemVer, CalVer, ZeroVer, rolling integers, marketing names, and commit hashes — what each one actually promises its reader, and why my pre-1.0 ventures are moving to date-based releases with SemVer held back

Two weeks after choosing dslmodel.eu I reversed it — what a dependency on a squatter, a revocable TLD, and an overweighted penalty taught me about deciding under constraints.

A structured, audience-first domain decision for a self-hosted retail trading platform — from ideal customer and TLD assessment through name candidates and availability to the final pick.

I rebuilt this site's Makefile in Task to judge the two properly.

Why I added comments, what I evaluated, and why I went with Hyvor Talk — on a static Astro site, DevOps overhead and vendor tracking are both non-starters.

The opinionated stack I've formalized after building the same kind of application too many times ad-hoc — the philosophy, principles, technology choices, the roads not taken, and why.

How availability reshaped a structured domain name decision — from ideal customer profile and TLD assessment through name candidates to a final choice of dslmodel.eu.

A structured evaluation of domain registrars for a solopreneur with a modest portfolio of domains.

A structured evaluation of ten documentation platforms — Docusaurus, VitePress, Starlight, Doks, Material for MkDocs, Antora, and more — against requirements for versioned, long-running documentation projects.

Most open source projects inherit a contribution policy they never chose.

The previous post laid out why licensing matters for a solopreneur working in the open.

Can you give everything away and still build something financially sustainable?

Position, role, and capability are not synonyms — each belongs to a different owner and fails in a different way when misread.

Each of the Ten Views of a digital solution has a natural diagram type and a tool that produces it well.

Every team has that diagram — the one that was accurate once, then quietly fell behind as the system moved on.

Most digital solutions are documented partially — the technical parts get captured, the rest is assumed.