My work sits at the intersection of business platforms, distributed systems, cloud architecture, identity, cybersecurity, AI, workflows, payments, and developer experience.

I like hard problems with long consequences. The kind where the architecture matters because five years later people still need to extend it, operate it, audit it, and trust it.

Most of that work currently converges on one platform.

Alliance Business Suite is the main platform I am building at Fenix Alliance.

ABS is not interesting because it has a lot of modules. Plenty of enterprise platforms have a lot of features.

The interesting part is how the system composes.

Instead of treating finance, commerce, customers, people, projects, documents, workflows, identity, payments, and intelligence as unrelated applications, ABS gives them a shared operating foundation.

A business is already connected in reality. Its software should work that way too.

flowchart TB
    ABS["Alliance Business Suite"]
    NUC["Nucleus"]
    POC["Pocket"]
    STD["Studio"]
    WFL["Workflows"]
    ENG["Platform engines"]
    CAP["Governed business capabilities"]

    ABS --> NUC
    ABS --> POC
    ABS --> STD
    ABS --> WFL
    ABS --> ENG

    NUC --> CAP
    POC --> CAP
    STD --> CAP
    WFL --> CAP
    ENG --> CAP

One Business OS. Many ways to operate it.

The platform is built around durable business concepts instead of letting every feature invent its own version of the company.

That means customers, identities, documents, transactions, money, events, workflows, permissions, and business relationships can participate in the same operating model.

The result is less duplication, fewer contradictory rules, and a much better foundation for cross-domain automation.

A business capability can be deliberately exposed through:

• 🧠 Nucleus, the intelligent web interface
• 📱 Pocket, the MAUI Blazor Hybrid experience for Windows, iOS, and Android
• 🛠️ Studio, the professional workbench for deep deterministic control, administration, authoring, and intelligent operation
• 🔁 Workflows, for durable business automation
• 🤖 Agents, for specialized reasoning
• 🌐 REST, GraphQL, gRPC, and MCP
• 🧩 Modules, SDKs, and custom portals

The interface changes. The business operation does not.

I am not interested in putting a chatbot beside the business and calling that transformation.

The model we are building is explicit:

flowchart LR
    PEOPLE["People decide"] --> AI["AI reasons"]
    AI --> WF["Workflows coordinate"]
    WF --> APPROVAL["Approvals authorize"]
    APPROVAL --> CAPABILITY["Capabilities execute"]
    CAPABILITY --> EVIDENCE["Evidence proves"]

    POLICY["Policy governs"] -.-> AI
    POLICY -.-> WF
    POLICY -.-> APPROVAL
    POLICY -.-> CAPABILITY

That means AI can participate in real business operations without becoming a second, uncontrolled execution system.

Current work includes exact invocation binding, durable approval, original-actor authority, authorization re-evaluation, leases, fencing, idempotency, recovery, and execution evidence.

ABS is designed so the Business OS does not become a different product every time the operating model changes.

The platform supports shared SaaS and self-hosted deployment models, with Alliance Business Cloud providing infrastructure and hosting services around the platform.

On the resource side, the architecture is moving toward platform-managed, tenant-managed, BYO, dedicated, partner-sponsored, and customer-managed runtime models for capabilities such as AI, storage, search, and agent execution.

InfinityComex is one example of what becomes possible when tenancy, commerce, orders, payments, and settlement share the same underlying system.

The architecture supports patterns such as multi-supplier carts, tenant-scoped order splitting, supplier payment paths, internal clearing, wallets, and future multi-party settlement models.

ABS is not designed around one "real" interface and a set of reduced companions.

All three operate through the same platform rules, identities, permissions, workflows, and business capabilities.

Nucleus and Pocket are where the next-decade interaction model becomes visible. Studio remains the deep professional workbench.

• Microsoft Agent Framework
• AG-UI
• MCP
• Generative UI
• specialized agents and skills
• governed tool execution
• execution identity and provenance
• provider abstraction and BYO credentials
• customer-managed agent runtimes

Approval is a shared platform capability, not an AI feature and not a workflow feature.

The goal is simple to say even if the implementation is not:

The action you approve is the action that runs.

That requires exact invocation identity, immutable approval evidence, separation of duties, expiry, fresh authorization, and safe resume semantics.

Workflows own durable coordination across people, systems, agents, events, schedules, approvals, and time.

A process should be able to wait, resume, retry, recover, and continue without depending on someone remembering what happens next.

I am designing a resource-neutral control plane so ABS modules can request governed capabilities without coupling themselves directly to a specific AI, storage, search, messaging, or runtime provider.

The intent is provider replaceability without rewriting customer modules.

I am also working on the financial infrastructure required for:

• tenant-scoped payments
• wallets and internal clearing
• settlement and reconciliation
• refunds and chargebacks
• disputes
• multi-party commerce
• future open-banking integrations

Financial infrastructure gets a higher bar. Correctness, evidence, reconciliation, and recoverability matter more than clever abstractions.

A few rules I come back to often:

Frameworks change. Business concepts usually outlive them.

If the same business operation exists in UI, API, workflow, and AI paths, it should still be the same business operation.

I prefer explicit Result, UnitResult, and SmartError flows over exceptions used as normal control logic.

Identity, authorization, tenant scope, approval, policy, and evidence should travel with the operation.

If the system cannot explain what happened, operating it becomes guesswork.

Different infrastructure responsibilities should not create different Business Operating Systems.

Complexity is justified only when it removes a harder, recurring problem.

I am especially interested in work involving:

• 🏗️ large .NET platform modernization
• 🌐 multi-tenant SaaS architecture
• 🤖 AI that can be trusted with real business operations
• 🔐 identity, federation, authorization, and policy
• 💳 financial and payment infrastructure
• 🧩 developer platforms and extensibility
• ☁️ cloud architecture and deployment independence
• 🛡️ cybersecurity and secure software design
• 🧠 turning complex domains into clear software models

I enjoy working with people who care about both technical depth and business outcomes.

Motorcycles. Formula 1. Running. Boxing. Tennis. Aviation. History. Leadership. Strategy.

I have a tendency to get interested in systems, whether they are software platforms, companies, engines, aircraft, or civilizations.

• 🌐 dlozanonavas.com
• 💼 LinkedIn
• 🐦 X / Twitter
• 🔥 Fenix Alliance
• 🧠 Alliance Business Suite
• 🛠️ ComputeWorks