Skip to main content

Determinism vs Nondeterminism

Written by Robin Wilde on . Posted in Aktuellt, Tech blog, Uncategorised.

Determinism vs Nondeterminism

Determinism or nondeterminism, two concepts that shape everything from science to philosophy. But what do they mean for system integration?

Image description: Sudoku, easy to verify, hard to solve.

Determinism vs Nondeterminism

The P vs NP problem

There is a classic and important problem in computer science called the “P versus NP problem.” As an aspiring developer and former math teacher, I was intrigued by the problem and specifically the terminology. First, let me try to explain the problem.

  • P stands for a problem that can be solved in a reasonable time by a computer (Polynomial time).

  • NP stands for a problem that can be verified in a reasonable time but not solved in a reasonable time (Nondeterministic Polynomial time).

For example, a sudoku puzzle can be verified quickly and deterministically. That is, if you want to check if a solution is correct, you can follow a given algorithm that will always take the same amount of time and will always give you the same answer (for the same puzzle).

To solve the puzzle, though, you must either use a nondeterministic approach and try different methods depending on your own hunches and feelings, or be prepared to spend a very, very long time trying to come up with a deterministic algorithm, that is identical for all sudokus, and then following it.

Why this matters

The question of the problem is whether P = NP. That is, if we can find a quick way to verify a solution to the problem, does that then mean that there is a quick way to solve the problem? The question is, as of now, unanswered, and if it were to be answered and found that P = NP, global chaos would likely follow.

“Imagine that hackers could find your password as quickly as they could verify that it was correct. Not good.”

Most modern cryptography relies on the fact that it is harder to find a solution than to verify it.

Another interesting aspect of the problem is that if you solve one special case of the problem (for example, the sudoku problem), you solve all cases of the problem. So if you are an agent of chaos, and, like the Joker of Batman, would like to see the world burn; make sure to spend some time on trying to solve this!

Clarifying Determinism vs Nondeterminism

  • Determinism: If the starting conditions are the same, the outcome will always be the same.

  • Nondeterminism: The possibility of different outcomes even though starting conditions remain the same.

In computer science the cause is often randomness; in other contexts the cause may be ascribed to free will.

From philosophy to system integration

Determinism vs. Nondeterminism is (and has been) a hot topic in fields ranging from physics to philosophy, but the reason I am bringing it up is actually the field of System Integration.

It seems like a no-brainer that integration flows should always be deterministic; that is, if you input A and get output B, you should always get output B when you input A.

Where Nondeterminism fits in system integration

Well, believe it or not, there is room for nondeterminism even in integration, where you generally expect predictable results.

How, you ask? Join us at our Agent in a Day workshop at Contica on October 22 at 16:00 on Masthamnsgatan 1, and we will try to convince you that this is the case.

You might even find out that your current business processes might be more nondeterministic than you think. And that getting more control over that nondeterminism is a good thing.

Register here for the event – Only 50 slots available!

Footnote

The “P vs NP problem” is a complex and nuanced problem and I had to do some simplification to avoid being too verbose here. If you want to discuss the problem further or want to know more about the event, make sure to reach out!

Image description: Niels Bohr and Albert Einstein, two physicists with different views on determinism.

<>Reach out if you’d like to discuss determinism, nondeterminism or how AI can help you in your integration landscapeintegration challenges

Continue reading

Why Integration Specialists Are the Doctors Your Business Needs

Written by Robin Wilde on . Posted in Aktuellt, Insikter, Tech blog.

Why Integration Specialists Are the Doctors Your Business Needs

Integration specialists should be like doctors asking the right questions to diagnose business pain and then designing the correct technical prescription.

When I went to the doctor recently, she started by asking one simple question: “Why are you here?”
After I gave a short description of my symptoms, she asked me to tell her more about some of them. She didn’t begin by asking me what I wanted her to do, prescribing a pill or naming a diagnosis, she listened, probed a little, and then used what I’d said to form a plan.

As a patient at the doctor’s office, I feel comfortable that they know what’s best for me. I don’t arrive expecting to know exactly what the problem is or which medicine I need. Sometimes I have an idea, or I’ve seen similar symptoms online. Even then, I’m happy to let the doctor do their job. And I would never go to a cardiologist for a broken leg. Both are doctors, but they have different specialties.

This is exactly why you should think of integration specialists as doctors.

Think of Us as Your “Tech Physicians”

Integration specialists aren’t interested in proving you wrong or insisting on our favourite tool. We have a job: to make systems work together so your people can do their work more easily. To do that well, we need to understand what really hurts.

When you walk into the clinic (or, in our case, pick up the phone or open a ticket), we begin the same way a good physician does:

  • We ask why you’re there.
  • We listen to the symptoms you describe.
  • We dig a little deeper to understand the context and severity.
  • We propose a plan that fits your actual needs—not what looks cool or what someone else has used. Sometimes your needs demand that we’re a group of specialists concluding together, that doesn’t mean that we don’t know what we’re doing. Only that we are experts in different tools.

What we want to know (and why it matters)

You might have read a blog, had a tip from a friend, or seen a flashy demo at a conference. Those are useful inputs but they’re not a diagnosis. Good integration is about aligning technical choices with your business reality.

Just like medicine, the “best” treatment is the one that helps the patient get better, not the one that looks the most impressive on paper or the one that you are most aware of. A search result, a tip from a friend, or a flashy tool demo can point you in a direction, but it’s rarely the real cure. We bring expertise to sort through the noise and apply the right treatment for your situation.

Below are the kinds of questions an integration specialist will start asking and why each matter:

  • Where does it hurt most?
  • What is your solution (if you have one) unable to do today that you want to do?
  • What’s non-negational?
  • How and when should we have a follow-up call?

So, instead of bringing the image you have gotten from your friend who works with “computers”, come to us with a clear definition of what you have today and how you want it to work.

We don’t come in with a one-size-fits-all solution. We come with a listening ear, diagnostic questions, and the aim of making your life easier, just like a good doctor.

So, the next time you reach out, take a number, sit back, and tell us: why are you here?

<>Vill du ha hjälp med er verksamhets smärta? Prata med Amanda!

Continue reading

New branching strategy to improve working with multiple GoLives within the same project

Written by Robin Wilde on . Posted in Aktuellt, Insikter, Tech blog.

New branching strategy to improve working with multiple GoLives within the same project

Traditional branching strategies break down when real-world delivery gets messy. In this post, we introduce a flexible branching model designed to support parallel releases without compromising stability, clarity, or developer sanity.

Managing parallel releases can be one of the trickiest challenges in software development. Traditional branching strategies, such as GitFlow or GitHub Flow, often assume a linear journey toward production: one mainline branch, one release at a time.

But real-world projects are rarely this simple. Many organizations need to prepare multiple GoLives in parallel, sometimes for different customers, sometimes for different environments, and sometimes for staggered rollouts of the same product. Without the right strategy, this can lead to confusion, conflicts, and rushed hotfixes.

To address this challenge, I’ve together with a colleague designed a branching strategy that allows teams to work on multiple GoLives simultaneously, while keeping the development branch isolated as a true sandbox environment.

Why versioning matters

Versioning is more than just tagging a release number. It’s the backbone of a predictable and stable delivery process.

  • Confidence in environments: When every branch corresponds to a release or pre-production state, teams know exactly what is deployed and where.

  • Isolation of work: Developers can be confident their features or hotfixes are scoped to the correct release cycle.

  • Reduced risk: Each GoLive is versioned and tested independently, which prevents changes from leaking into the wrong environment.

By tying features and hotfixes directly to release and pre-production branches, versioning becomes not just a technical necessity but a central tool for project coordination.

What’s new

This approach introduces two important changes compared to traditional branching strategies:

  1. Release/Preprod as Anchors for New Work

    • Feature branches and hotfixes are not created from dev or main.

    • Instead, they branch directly from the release or preprod version they belong to.

    • This ensures that every change is tied explicitly to the GoLive it is meant for.

  2. DEV as a Pure Sandbox

    • The dev branch is no longer part of the release pipeline.

    • It exists solely for developer testing, experimentation, or prototyping.

    • Nothing merges back from dev into release branches, which prevents instability from creeping into production.

The result? Teams can work on multiple GoLives in parallel, finalizing one release for pre-production while already developing features for the next.

Where and how to apply this strategy

This branching strategy is especially valuable in projects where:

  • Multiple releases are planned to go live at different times.

  • Testing requires both a dedicated test environment and a pre-production environment that mirrors production.

  • Hotfixes need to be scoped to specific GoLives without disrupting other versions.

How it works in practice:

  1. A release branch (e.g., release/1.0.0) is created for an upcoming GoLive.

  2. Developers create feature branches (e.g., feature/1.0.0/feature-name) directly from that release branch.

  3. When a release is ready, it is promoted to pre-production (preprod/1.0.0) for validation.

  4. Once verified, it is merged into main (production).

  5. Meanwhile, a new release branch (e.g., release/2.0.0) can already be in progress, enabling two GoLives to be prepared in parallel.

  6. Hotfixes are branched directly from pre-production, ensuring that fixes apply only where needed.

This structure creates a clear separation of responsibilities: release branches for development, preprod branches for stabilization, and main for production.

Why I recommend this

I find this strategy valuable because it solves several pain points that traditional models often leave unresolved:

  • Clarity: Everyone knows which GoLive a feature or fix belongs to.

  • Parallelism: Multiple GoLives can be worked on simultaneously without overlap or confusion.

  • Cleaner development process: DEV becomes what it was always meant to be—a sandbox—without the burden of release preparation.

  • Reduced release risk: Hotfixes and features are scoped precisely to the versions that matter, reducing the chance of introducing unintended changes.

In short, this model embraces the complexity of real-world delivery schedules instead of forcing everything into a single linear flow. It provides structure without rigidity, and flexibility without chaos.

<>Har du frågor om hur du får ordning i din arkitektur i Azure?

Continue reading

New Capabilities to Prevent Misconfigurations in API Management

Written by Robin Wilde on . Posted in Aktuellt, Insikter, Tech blog.

New Capabilities to Prevent Misconfigurations in API Management

A single missing line in your API policy can silently disable critical security layers without you noticing. Microsoft just introduced a small but powerful update in Azure API Management that helps you catch and prevent exactly that. Here’s what it does and why it matters.

Microsoft just introduced a small but important feature in API Management that can prevent serious misconfigurations. It’s one that could prevent some of the most common security misconfigurations I’ve seen when working with customers.

In Azure API Management, policies can be applied at different scopes: global, product, API, or operation level. You can think of them as layers, and the glue that ties it all together is the <base /> tag. This tag is what allows policies defined at a higher level (like a product-level auth policy or a global logging policy) to be inherited by lower levels. Without it, the policy stops inheriting anything from above.

And that’s where things can go wrong. It means your API could go live without any of the controls you thought were in place.

Why inheritance matters

Policy inheritance in APIM is based on a simple principle: the <base /> tag tells the policy engine to apply everything defined at higher scopes before running the local policy. Without it, you’re effectively opting out of the shared rules.

I’ve seen this happen more than once, someone removes the base tag, maybe while testing something, or maybe because the docs didn’t make it clear, and suddenly the API is running wide open. From the outside, it looks fine. From a security perspective, it’s not.

It’s a small mistake with big consequences. And until now, there’s been no native way to detect or block it.

What’s new

Microsoft has now added a built-in Azure Policy that lets you enforce or audit this inheritance behavior. You can use it to:

  • Audit where <base /> is missing from your policy XML

  • Deny any changes that attempt to skip it

This applies to global, product, API, and even operation-level policies. And that’s the key, you can now be confident that your security rules are being enforced, not just assumed.

The policy is called: API Management policies should inherit parent scope policies using <base />

Where and how to apply this policy

You can assign this policy like any other Azure Policy, through the portal, CLI, Bicep, or ARM, but where you assign it makes a big difference.

My take? Assign it as high up in the hierarchy as possible, ideally at the management group or subscription level. That way, you ensure the policy covers every existing and future APIM instance, reducing the risk of misconfigurations if someone spins up a new environment without the right governance controls.

To get started:

  1. Go to Azure Policy in the Azure portal.

  2. In the left-hand menu, select Definitions and search for
    “API Management policies should inherit parent scope policies using <base />”.

  3. Open the policy and click Assign.

  4. Choose your assignment scope, select whether you want to Audit or Deny, and configure any other required settings.

Why I like this

This might seem like a small thing, but it solves a real issue in large-scale API environments. When your team grows, your APIs multiply, and your security controls are defined in layers, the last thing you want is a single policy missing a line of XML that silently breaks the chain of inheritance.

Security misconfigurations are rarely intentional. They often come from people trying to solve other problems, fixing a bug, changing a timeout, updating a policy quickly without understanding the full impact. The ability to audit or deny missing inheritance is one more tool to help make sure your architecture behaves the way it’s designed to.

It also helps bridge the gap between governance and development. Instead of relying on reviews or documentation to remind people what should happen, you can enforce it directly through code and policy.

This is a great addition to the toolbox if you’re serious about building secure, scalable API platforms in Azure.

In short: don’t just fix existing issues, prevent new ones from happening.

<>Vill du prata mer säkerhet? Kontakta mig!

Continue reading

The “Quick Task” Trap and How Logic Apps agent loop Kills It

Written by Atosa Majidi on . Posted in Aktuellt, Insikter, Tech blog.

The “Quick Task” Trap and How Logic Apps agent loop Kills It

A while ago i had a meeting with a new client in the cargo shipping business to map their integration landscape. Everything looked solid, most integrations had the usual needs, nothing out of the ordinary. Then they mentioned the “special bookings” that still land in an operator’s inbox. Yes, manual bookings still occur in the enterprise world. Each one seems tiny until you multiply it across a week, a month, and a year. Those interrupts also break the operations team’s focus. So why not build a Logic Apps agentic loop to take the ad‑hoc cases off people’s plates, while handing off the real edge cases to humans with full context? 


That’s about ten workweeks a year on a repetitive task. Perfect fit for a Logic Apps agentic loop.

First, let’s understand why an agentic loop works.

What is an “Logic apps agent loop” in a simple way

Unlike a fixed workflow, the agent plans, acts with tools, and verifies until the goal is reached or hands off.

plan → act → verify → stop/hand‑off Think of it as a smart, policy‑aware assistant inside your integration that:

  1. Understands the goal (create/update a booking).
  2. Plans the next best action (validate → decide → act → verify).
  3. Uses approved tools (APIs, email/Teams, ticketing).
  4. Checks itself (did we reach the goal?) and repeats if needed.
  5. Knows when to stop and hand over to a human, with all the details.

It’s autonomy with brakes, goal‑driven, tool‑powered, and safeguarded.

Now lets check this scenario Before and after logic apps agent loop

Before : manual path

  • Client chooses website form or email
  • Operator reads & interprets details
  • Operator types into the reservation system
  • Confirmation and change requests bounce via email

Now lets see how it look using Logic Apps agent loop: agentic loop path

  • HTTP trigger receives a booking payload (or parses a form/email)
  • Agent validates required fields and business rules
  • If standard → call Booking API → confirm → log
  • If special/uncertain → open a ticket & notify operator with full context

The flow (step‑by‑step, as configured)

  1. Receive & (if needed) repair JSON
    Trigger receives the BookingPayload → Default_Agent attempts parse; if parse fails → JSON Repair Tool → if still invalid → Jira ticket + Teams alert + customer email, then stop.
  2. Validate mandatory fields
    Check date, route, resource, registrationNumber, contact, company (+ extra per resource type). If missing → Teams alert listing the missing fields → stop.
  3. Decide by resource type
    If TRU → manual hand‑off: Teams post + client email + Jira ticket → stop.
    Else → proceed to Create Booking.
  4. Create booking
    Invoke Create Booking Tool persist tracked properties (ex. ordernr).
  5. Notify & trace
    Post summary to Teams and retain full run history; on exceptions, open Jira with context.

Why this changes how we build integrations, you can keep changes fast and painless by connecting  business process directly to your tools (code and connectors).

  • Process first, in plain English/prompt. Write the steps the way an operator would: receive → validate → decide → act → confirm/hand off.
  • Then build only the tools. Each capability becomes a tool (E.X. Create Booking, JSON Repair, Notify Teams, Raise tickts). The agent handles when and how to use them.

  • Change = edit instructions. When behavior needs to shift, you update the agent instructions (policy/guardrails), not the whole workflow. Adding/replacing a tool is low‑friction.
  • Keep tools simple & testable. Clear inputs/outputs, idempotent by design, with tracked properties for audit.

Apply this to any case: find the 5–30 minute tasks

The principle: You don’t need big projects, target the 5–30 minute tasks that quietly steal time, they compound into outsized impact!

Spot them quickly (signals)

Spot them quickly (signals)

  • Re‑keying or copy‑paste between systems (“swivel‑chair” work)
  • CSV/Excel exports followed by manual massaging
  • Status checks / “can you confirm…?” emails
  • Re‑sends / retries / duplicate checks
  • Manual validations (required fields, formats, cut‑offs)
  • Simple triage or routing (choose queue, project, team)
  • Repetitive notifications or summaries (Email/Teams)

Quantify the value in 2 minutes

  1. Estimate duration (5–30 min).
  2. Count frequency/week.
  3. Compute hours/year = duration (h) × frequency × 52.
  4. Convert to workweeks = hours/year ÷ 40.

Pick first targets (checklist)

  • Clear rules, low ambiguity (rare edge cases)
  • APIs or connectors exist (or can be built as tools)
  • Human fallback is acceptable (safe stop conditions)
  • Idempotent or easy to de‑duplicate
  • Measurable outcome (confirmation, ID, ticket)

Turn it into an agentic loop in one page

  • Write the process in plain English: receive → validate → decide → act → confirm/hand off.
  • List the tools you need (Create Booking, JSON Repair, Notify Teams, Raise tickets).
  • Write the agent instructions (goal, guardrails, stop rules, success checks).
  • Run shadow mode, compare outcomes, then switch to auto for the standard path.
  • Review weekly and adjust the instructions before touching tools.

Example micro‑candidates across domains

  • Logistics: ad‑hoc bookings, schedule lookups, booking confirmations.
  • Finance: invoice status checks, statement exports, simple approvals.
  • HR: candidate interview scheduling, document collection reminders.
  • IT: user provisioning tickets, routine alert triage, access reviews.
  • Sales/Ops: lead enrichment, quote follow‑ups, order status notifications.

Automation isn’t about replacing people; it’s about protecting their focus.
By turning a “quick manual task” into zero, the agentic loop gives that time and attention back to the team.

<>Ahmed Bayoumy – CTO

Continue reading

Tänk om morgondagens innovation finns i det du redan har?

Written by Robin Wilde on . Posted in Aktuellt, Insikter, Tech blog.

Tänk om morgondagens innovation redan finns i dina befintliga integrationer?

Många integrationslösningar har levererat stabilt i åratal och fått stå orörda. Ofta för att ingen riktigt vet hur de fungerar, eller för att det känns tryggare att bygga nytt än att röra vid det gamla. Men vad händer om det redan finns outnyttjade möjligheter i de integrationer du har idag?

Långlivade integrationerna kan vara en bortglömd tillgång

Integrationer är ofta de mest långlivade lösningarna i ett IT-landskap. De levererar data, de fungerar stabilt och i bästa fall märks de knappt. Vilket är ett tecken på att de gör sitt jobb. Men det gör också att de ofta lämnas orörda under lång tid. Dokumentationen blir föråldrad eller saknas helt, och kunskapen om hur de är uppbyggda försvinner när personer slutar eller byter roll.

När nya behov uppstår, som att bygga en dataplattform eller starta ett AI-projekt, blir det därför ofta enklare att bygga nytt. Kanske till och med på en helt ny teknik. Det är inget fel i det men det kan innebära att man missar värdefulla möjligheter i de befintliga integrationerna.

Innovation kan börja i det du redan har

Genom att analysera och dokumentera dina befintliga integrationer kan du upptäcka värden som inte var synliga från början:

  • Dataflöden som kan återanvändas för att stötta nya projekt inom AI och datainnovation

  • En tydligare helhetsbild som minskar risken för driftstopp och beroenden

  • Nya idéer på innovation som bygger på befintlig plattform istället för att starta om från noll

Många organisationer sitter med en dåligt dokumenterad integrationsplattform. Resultatet är outnyttjade möjligheter. Framtidens innovation skulle kunna finnas i det ni redan har.

Tänk om morgondagens innovation redan finns i dina befintliga integrationer?

På Contica hjälper vi er att kartlägga er integrationsplattform och upptäcka värden ni redan har. Tillsammans synkar vi nuläget med er långsiktiga strategi för datainnovation och skapar en tydlig väg framåt där ni kan frigöra den innovation som redan finns i era integrationer.

Kontakta oss på Contica så bokar vi ett samtal för att prata om er befintliga integrationsplattform och hur en kartläggning skulle kunna hjälpa er i att förverkliga er IT-strategi.

Continue reading

Vad kostar det att inte migrera från BizTalk?

Written by Robin Wilde on . Posted in Aktuellt, Insikter, Tech blog.

Vad blir kostnaden för att stanna för länge i BizTalk?

Vi vet att BizTalk är en fantastisk integrationsplattform. Är det endast end-of-support som gör det värt att agera? Är det licenskostnad för BizTalk som gör det värt att agera? Vi påstår att anledningarna är flera. En stark drivkraft borde vara vad kostnaden är att missa möjligheten att innovera.

BizTalk har tjänat väl men tiden går

Vi älskar BizTalk. Det har varit en trogen plattform för affärskritisk integration i över två decennier. Och låt oss vara tydliga, plattformen kommer fortsätta leverera länge för dem som väljer att stanna kvar.

Vår CTO Ahmed Bayoumy pratade nyligen om just detta tillsammans med Sandro Pereira, Head of Integration på DevScope, i ett gemensamt webinar om BizTalks framtid och vägen mot Azure.

De båda är tydliga: BizTalk är inte död ännu, men det är dags att börja förbereda sig.

Att stanna kvar i BizTalk kan kännas tryggt, men likt att parkera utan att betala så kan kostnaden bli orimlig i proportion i vad du hade fått om du agerade. Är det fler än jag som tycker att parkeringsböterna är oproptionerliga? Hur som helst.. Notan för att ligga kvar i BizTalk kommer i form av ökade driftkostnader, tekniska begränsningar och missade möjligheter till innovation. Framför allt kanske det sistnämnda, och vad är priset för missad innovation? Vi återkommer. Nu tillbaka till fakta.

Supporten för BizTalk Server 2020 upphör i april 2028, och efter det försvinner säkerhetsuppdateringar, bugfixar och officiellt stöd. Det är inte bara en kalenderfråga – det är en tydlig signal om att tiden är inne att agera.

Vad kostar det att inte agera?

Att avvakta migrering kan kännas tryggt på ytan, men innebär ofta dolda och växande kostnader. Här är några av dem:

1. Säkerhetsrisker
Utan officiellt stöd försvinner säkerhetsuppdateringar. Det innebär ökad sårbarhet mot intrång, dataläckor och compliance-problem.

2. Kostnader för legacy-infrastruktur
Drift av egna BizTalk-servrar, licenser, specialkompetens och beroende till äldre system ökar driftskostnaden och gör er mindre rörliga.

3. Missad innovation
Azure är inte bara ett alternativ till BizTalk. Det är en plattform där innovation sker. Att stå utanför innebär att missa möjligheten att dra nytta av nya tjänster inom AI, automatisering och avancerad analys.

4. Stagnerande integration
BizTalk är en robust plattform, men den bygger på ett äldre paradigm. I takt med att omvärlden blir mer händelsedriven, molnbaserad och distribuerad blir det svårare att bygga moderna integrationslösningar i BizTalk.

Azure är mer än en ny integrationsplattform

När ni migrerar till Azure handlar det inte bara om att ersätta något gammalt, det handlar om att öppna upp för framtiden.

Genom att flytta integrationsflöden till Azure får ni direkt tillgång till:

  • Serverless-arkitektur med Logic Apps, Functions och Event Grid

  • Automatiserade flöden och robust API-hantering

  • AI-agenter och kognitiva tjänster för smartare, självlärande integrationer

  • Azure Fabric och andra datatjänster för avancerad analys och realtidsinsikter

Integration är inte längre en isolerad ö, det är en grundförutsättning för att lyckas med data, analys, AI och digitalisering som helhet. Och det är just där Azure briljerar.

Microsofts väg framåt och vår

Microsoft är tydliga: framtiden ligger i en iterativ, stegvis migrering från BizTalk till Azure Integration Services. Inte genom att flytta allt på en gång, utan genom att börja där det gör mest nytta och bygga vidare därifrån.

Vi på Contica arbetar enligt samma princip. Vi hjälper våra kunder att kartlägga sin miljö, prioritera rätt och migrera i rätt takt. Målet är att skapa värde så fort och tryggt som möjligt, utan att riskera stabilitet eller affär.

Vi vågar påstå att vi är världsledande

Contica har jobbat med systemintegration sen 2010. Vi har hjälpt flertalet kunder att ta steget till Azure. Vår erfarenhet kombinerat med vårt partnerskap med DevScope – där BizTalk-gurun Sandro Pereira leder integrationsarbetet – har vi tillgång till en unik kombination av djup kompetens till våra kunders förfogande.

Tillsammans kan vi hjälpa er att migrera från BizTalk till Azure på ett tryggt sätt. Partnerskapet och vår egen kunskap inom AI och dataanlys kryddar även vad våra kunder får tillgång till. Vi kan även guida er genom transformationen, från traditionell integration till en modern, datadriven och AI-kapabel miljö i Azure.

När ni väl är i Azure kan vi, tack vare DevScopes spetskompetens inom Power BI och AI, även erbjuda er att omsätta data till beslutskraft. Med moderna analysverktyg får du bättre insikter, effektivare processer och ett smartare affärsstöd. Här kan du läsa mer om vårt partnerskap.

Dags att ta första steget?

Att inte göra någonting kan vara det dyraste beslutet.
Vi hjälper gärna till att identifiera vad som är rätt första steg för just er.

Kontakta oss på Contica så bokar vi ett samtal om era integrationsbehov och hur vi tillsammans kan planera er migreringsresa. Vi vill påstå att vår expertis är världsledande inom området. Men vi är inte bara tekniskt väldigt kunniga, vi är erfarna vägvisare.

Continue reading

BizTalk-migrering utan kaos? Börja med en tugga i taget.

Written by Robin Wilde on . Posted in Aktuellt, Insikter, Tech blog.

Hur äter man en elefant? En bit i taget. Samma är det när du ska göra en migrering från BizTalk.

Att migrera från BizTalk är ingen enkel uppgift. Vi vet. Vi har gjort det över 10 gånger. Vi vet vilka fallgropar du ska undvika. Med vår samlade expertis och vårt partnerskap med DevScope har vi världsledande kompetens i hur du migrerar från BizTalk. En bit i taget.

Contica rekommenderar att du beställer en BizTalk-migrering.

När jag går på restaurang frågar jag alltid om kökets rekommendation. Varför? Man vet att det finns kärlek, tanke och tid bakom valet. Man kan känna sig trygg i att det blir bra. Kocken har gjort detta förut. Jag är i goda händer.

Lite så känner vi för de bolag som har BizTalk. Låt oss rekommendera en migrering! Vi har hjälpt över 10 kunder att ta klivet från BizTalk till Azure. Varje projekt har lärt oss något nytt, och vi tar med oss den erfarenheten in i varje ny migrering.

“Hur äter man en elefant? En bit i taget.”

Det är ett gammalt talesätt som fortfarande är högaktuellt. När något känns för stort, för komplext eller nästan oöverstigligt, påminner det oss om att lösningen ofta ligger i att ta små men välriktade steg. Ett i taget.

Och just så tänker vi när det handlar om BizTalk-migrering.

BizTalk har ofta varit en lojal del av verksamhetens infrastruktur i många år. Den har knutit ihop system, människor och affärer. Att byta ut något så centralt är inte ett litet beslut. Det vet de flesta. Men frågan som många brottas med är hur man faktiskt går till väga om man inte har gjort det förut.

Vi tror inte på att göra allt på en gång

Det kan låta lockande att försöka flytta hela BizTalk-miljön i ett svep. En “Big Bang”-strategi. Men verkligheten är sällan så enkel. Integrationer är ofta hårt sammanflätade, systemberoenden är svåra att kartlägga och risken för driftstörningar är påtaglig. Vi håller med Microsoft Best Practice när du står inför en migrering. Hur menar vi?

Att börja i liten skala, med kontrollerade steg, ger bättre resultat både tekniskt och affärsmässigt. Precis som med elefanten – det fungerar bättre att ta en tugga i taget.

Därför fungerar det stegvisa angreppssättet

Genom att arbeta iterativt får både vi och kunden stora fördelar. Vi kan snabbt identifiera vad som fungerar och vad som behöver justeras. Varje steg ger oss mer kunskap om den specifika miljön och ökar tryggheten i nästa steg.

Det minskar risken, gör det enklare att anpassa arkitekturen längs vägen och ger bättre kontroll över både kostnader och tidplan.

Och viktigast av allt – det fungerar. Inte bara i teorin, utan i praktiken. Vi vet det eftersom vi redan har genomfört över tio lyckade migreringsprojekt från BizTalk till Azure.

Vi är inte bara trygga – vi har tillgång till den främsta expertisen

På Contica är vi stolta över vår erfarenhet, men vi vet också när det är rätt att stärka teamet med spetskompetens. Därför samarbetar vi med DevScope, där Sandro Pereira är en nyckelperson. Sandro är en av världens mest erkända experter inom BizTalk och Azure Integration, och det är ingen överdrift att säga att han har varit med och format hela området.

Många som arbetar med integration idag har lärt sig grunderna genom Sandros bloggar, föreläsningar eller verktyg. Genom vårt partnerskap med DevScope kan vi tillsammans erbjuda en nivå av expertis som vi vågar påstå är bland de absolut främsta globalt när det gäller just migrering från BizTalk till Azure.

Vår rekommendation?

Om du sitter med tankar kring en kommande migrering, eller om du bara vill få ett bollplank, hör av dig. Vi lyssnar gärna in din situation, hjälper dig att se var ni står i dag och ger konkreta förslag på vad ert nästa steg är.

Vi vet att migreringen från BizTalk till Azure är stor. Men vi vet också att den går att genomföra, med trygghet och kvalitet, om man tar det steg för steg. Och vi hjälper gärna till.

Kontakta oss på Contica så bokar vi ett samtal om era integrationsbehov och hur vi tillsammans kan planera er migreringsresa. Vi vill påstå att vår expertis är världsledande inom området. Men vi är inte bara tekniskt väldigt kunniga, vi är erfarna vägvisare.

Continue reading

Security isn’t something you sprinkle on later. It’s baked into the design

Written by Atosa Majidi on . Posted in Aktuellt, Insikter, Tech blog.

Security isn’t something you sprinkle on later. It’s baked into the design

At this year’s Integrate conference, a clear theme emerged for anyone working with Azure Integration Services: security needs to be part of the platform design and not an afterthought

API Management – your hidden security layer

Several sessions showed how API Management can do more than just route traffic. Used right, it becomes a central part of your detection and prevention strategy. By analyzing traffic patterns and integrating with tools like Microsoft Fabric, you can uncover anomalies and spot fraud attempts early. That’s a powerful capability hiding in plain sight. 

Key Points:

  • Monitoring traffic patterns

  • Integration with Microsoft Fabric

  • Early fraud detection

Enterprise-scale security patterns & the AI Gateway

We also saw how large organizations approach API security at scale, layering policies for access control, identity validation, and traffic protection. And as AI-powered workloads become more common, APIM’s new AI Gateway capabilities are stepping in to help control the chaos. 

Shortcuts, costs – and the real price of insecurity

One session reminded us just how complex integration solutions can become over time. With every design choice, especially around security, there’s a tradeoff. Strong isolation and advanced controls sound great – until they double your cost or cripple your agility. Finding the right balance between cost and security isn’t just smart, it’s essential if you want your platform to be both safe and sustainable.

And perhaps the most relatable point came from the discussion around real-world integration projects: as services multiply and deadlines loom, shortcuts happen. Those shortcuts, like shared keys, overly broad permissions, or “temporary” public endpoints tend to stick around and come back to bite you.

💬 Biggest takeaway?

Security isn’t something you sprinkle on later. It’s baked into the design, the automation, and the defaults.
Get it right early or spend a lot more fixing it later.

<>Vill du prata mer säkerhet? Kontakta mig!

Continue reading

Integrate 2025: What you really need to explore now

Written by Robin Wilde on . Posted in Aktuellt, Tech blog.

Integrate 2025: What You Really Need to Explore Now

Contica’s CTO and Microsoft Azure MVP, Ahmed Bayoumy, shares his reflections from Integrate 2025. AI agents aren’t the future—they’re the new normal. This is your essential checklist for what to explore now to stay ahead in an increasingly intelligent integration landscape.

Integrate 2025: Your Essential Exploration Checklist 

Yes, everything is AI and AI agents now. And yes, we can’t ignore it anymore. 

The Reality Check 

After  Integrate 2025, one thing became crystal clear: There’s no way back from this. 

I know, I know, another “AI will change everything” article. But hear me out. This isn’t about hype anymore. Microsoft just showed us a world where AI agents are handling loan approvals, fixing production issues at 3 AM, and making business decisions that used to require human judgment. 

The most surprising part? These aren’t prototypes or far-future concepts. They’re shipping today. Whether you’re ready or not, the AI agent revolution is already here. The question isn’t “if” you should explore this technology, but “what exactly” you need to explore to stay relevant. 

Looking at below, I can see that a lot of businesses are running a few steps behind, and we need to reshape our thinking to simply keep up. Instead of rigid, rule-based integrations, we’re moving toward intelligent workflows that can reason through complex scenarios. 

We in phase 8 → AI Agents represent the next evolutionary step 

In this article, I thought of sharing my plan navigating this new reality your essential exploration checklist for the post-Integrate 2025 world. From Agent Loop in Logic Apps to MCP, hybrid deployments, and more these are the technologies you need to understand now. 

The “Must Explore” List:

1. Start with Agent Loop in Logic Apps

Agent Loop stands as logic apps bold answer to embedding AI decision-making directly into Logic Apps workflows. After the demonstrations at Integrate 2025, I’ve seen firsthand how this technology transforms integration patterns by adding intelligence to existing processes. 

What it is: AI agents that can reason through business processes instead of just following rules.

Why Agent Loop should be your first exploration: Because it already sits at the heart of your integration strategy. The brilliant thing about Agent Loop is you don’t need to change much, you’re already using Logic Apps for your business processes. Now you just add intelligence to them. 

The beauty of starting here: 

✅ Leverage existing investments:  Your current Logic Apps workflows become smarter, not replaced 

✅ Use familiar tools:  Same Visual Studio Code, same connectors, same deployment process 

✅ Gradual transformation: Add Agent Loop to one step in an existing workflow, see the difference 

✅ Immediate impact : Turn rigid if-then logic into intelligent reasoning without rebuilding everything  

The Critical Mindset Shift 

Agent Loop requires thinking differently about integration: 

From: “How do I integrate every possible scenario?” 

To: “How do I teach AI to reason about my business domain?” 

From: “My workflow must be 100% predictable” 

To: “My workflow should be intelligent and adaptive” 

From: “I control every decision point” 

To: “I govern the decision-making process” 

This isn’t about losing control, it’s about upgrading from manual control to intelligent governance. 

New Patterns for a New Era 

What caught my attention at Integrate 2025 were the agent orchestration patterns being demonstrated. These represent entirely new design approaches we need to consider. 

These patterns signal that we’re entering an exciting new era of integration design where intelligence is distributed throughout our business processes. 

📚 Key Resources: 

2. Model Context Protocol (MCP) – The New Standard

MCP functions as an open standard enabling AI models to interact seamlessly with external data sources and tools. Based on JSON-RPC 2.0 for messaging, MCP utilizes a client-host-server architecture that supports two primary transport methods: 

Remote MCP servers: Uses HTTP and Server-Sent Events (SSE) for network communication 

Local MCP servers: Employs standard input/output for same-machine communication 

The protocol addresses the traditional challenge of creating custom connectors for each new integration by providing a unified approach for connecting agents to both local and remote data sources

The simple explanation: As you expose more APIs as MCP servers (AI tools), you need a way to manage them all. API Center becomes your enterprise catalog where teams can: 

  • Discover what AI tools are available (“Oh, we already have a customer lookup tool!”) 
  • Govern who can use which tools (“Only finance team can access the billing APIs”) 
  • Track versions and ownership (“Marketing owns the campaign API, IT owns the infrastructure APIs”) 
  • Control access and permissions (“Junior agents can read data, senior agents can modify it”) 

Why you need this: Without a registry, you’ll end up with chaos – duplicate AI tools, security gaps, and teams building the same thing twice. API Center prevents the “wild west” of AI agent development. 

Real scenario: Developer wants to build an AI agent that checks inventory. Instead of building a new tool, they search API Center, find the existing inventory MCP server, and use it immediately. 

Why This Matters 

Every REST API you’ve built over the past decade can now: 
✅ Be used by AI agents 
✅ Without changes to logic 
✅ Exposed securely via Azure API Management (APIM) 
✅ Governed with API Center 

So instead of rewriting your systems for AI, you just wrap them with MCP and plug into the AI ecosystem. No rebuilding required , just expose it through MCP and AI agents can use it in natural language. 

📚 Key Resources: 

Expose your REST APIs as MCP servers: 

MCP Client Auth with APIM as your AI gateway: 

  • .NET: https://aka.ms/mcp-remote-apim-auth-dotnet 

API Center – Enterprise MCP registry: 

3. Logic apps Hybrid Deployment – Your Door to the Future

Now generally available (GA)!  

What it is: Running the full power of Logic Apps on your own infrastructure – and guess what? You get ALL the benefits: AI agents, automated testing, codeful workflows, and all 1,400+ connectors! 

The game-changer: This isn’t “hybrid lite” or “on-premises with limitations.” This is the complete Logic Apps platform running in your data center with every single capability: 

✅ Agent Loop – AI agents making intelligent decisions on your infrastructure 

✅ Automated unit testing – Full testing framework for production reliability 

✅ Codeful workflows – Write code alongside visual design 

✅ All 1,400+ connectors – Every SaaS integration you need 

✅ Local data processing – Keep sensitive data on-premises 

✅ Cloud management – Still manage everything through Azure portal 

Why this is your door to the future: You get tomorrow’s AI-powered integration platform running on today’s compliance-friendly infrastructure. No compromises, no “choose between cloud power and local control” – you get both. 

Perfect for: Financial services, healthcare, manufacturing, government – anyone who needs the future but can’t compromise on where their data lives. 

📚 Key Resources: 

When to explore this: 

  • You have data residency requirements 
  • You need to process data locally (manufacturing, IoT) 
  • You’re migrating from BizTalk Server 
  • You have intermittent connectivity issues 
  • Compliance requires on-premises processing 

Your evaluation process: 

  • Assess your Kubernetes maturity (you’ll need Arc-enabled clusters) 
  • Identify pilot workloads (start with non-critical processes) 
  • Plan your local architecture  

Pro tip: Don’t go hybrid just because you can. Go hybrid because you have a specific business need that cloud-only can’t meet.

4. Rules Engine – AI with Guardrails

What it is: Deterministic business rules that constrain AI agent decisions.

📚 Key Resources: 

Critical for: 

  • Financial services (regulatory compliance) 
  • Healthcare (safety protocols) 
  • Manufacturing (quality standards) 
  • Any business with strict governance requirements 

Your implementation approach: 

  • Document existing business rules (the ones humans follow today) 
  • Identify rule conflicts (what happens when rules contradict?) 
  • Start with simple rules (approval limits, routing logic) 
  • Test with AI agents (ensure they respect the boundaries) 
  • Monitor rule effectiveness (are they too restrictive or too loose?) 

Remember: Rules aren’t about limiting AI they’re about ensuring AI operates within your business policies. 

5. Logic Apps Testing Framework – Making It Production-Ready

What it is: Proper unit testing for your Logic Apps and AI agent workflows – because if AI agents are making business decisions, you better test them thoroughly. 

Why this is absolutely critical: Before this framework, testing Logic Apps meant manually clicking through workflows and hoping for the best. Now you can write automated tests that verify your workflows work correctly every time. 

The features: 

  • Mock external systems – Test without hitting real Salesforce, SAP, or databases 
  • Test AI reasoning – Verify agents make correct decisions for specific scenarios 
  • Visual Studio Code integration – Write and run tests right in your development environment 
  • CI/CD pipeline support – Automatic testing before production deployment 
  • Simulate different scenarios – Test edge cases and error conditions safely 

Why you can’t skip this: AI agents will make thousands of decisions without human oversight. Would you deploy code that transfers money without testing? Then don’t deploy AI agents that approve loans, process returns, or handle customer data without proper testing. 

The bottom line: This framework is what separates experimental AI projects from production-ready business solutions. It’s the difference between “cool demo” and “trusted system.” 

📚 Key Resources: 

Your testing strategy: 

  • Start with simple workflows (test inputs and expected outputs) 
  • Mock external dependencies (don’t hit real systems during tests) 
  • Test AI agent decisions (verify reasoning and compliance) 
  • Automate testing in CI/CD (no manual testing for production deployments) 
  • Monitor in production (testing doesn’t end at deployment) 

Non-negotiable: If you’re putting AI agents in charge of business decisions, you need automated testing. Period.

The skills we need now

For Developers: 

  • Learn prompt engineering and AI reasoning patterns 
  • Understand Model Context Protocol implementation 
  • Master hybrid workflow design (visual + code) 
  • Practice AI agent testing and debugging 

For Architects: 

  • Design AI-first integration patterns 
  • Plan governance for autonomous systems 
  • Evaluate security implications of AI agents 
  • Create standards for MCP server development 

For Business Analysts: 

  • Identify processes suitable for AI decision-making 
  • Learn to design AI agent workflows 
  • Understand the boundaries between human and AI judgment 
  • Practice writing business rules for AI systems 

For Operations Teams: 

  • Monitor AI agent performance and decisions 
  • Understand when to override AI recommendations 
  • Design escalation paths for complex scenarios 
  • Learn to work alongside AI operational tools 

 

💡 The Mindset Shift Required 

From Programming to Training 

You’re not just writing code anymore, you’re teaching AI how to think about your business problems. 

From Deterministic to Probabilistic 

Your workflows won’t always do exactly the same thing with the same inputs, and that’s not a bug, it’s a feature. 

From Control to Governance 

You can’t control every AI decision, but you can set the boundaries and monitor the outcomes. 

From Reactive to Proactive 

AI agents don’t just respond to events, they anticipate needs and take preventive action. 

🎯 Your Next Steps (Start Tomorrow) 

  1. Pick ONE thing from this list (don’t try to do everything at once) 
  2. Set up a development environment (Logic Apps Standard + VS Code) 
  3. Find a simple business process to experiment with (something low-risk but real) 
  4. Document your learning (you’ll need to teach others) 
  5. Plan for organizational change (this affects more than just Integrations) 

The Truth About Where We Are 

Integrate 2025 wasn’t just a product announcement, it was a declaration that the age of “dumb” automation is over. Microsoft just showed us that AI agents can reason, decide, and act autonomously within business processes. 

You can resist this change, but you can’t stop it. Your competitors are already exploring these capabilities. Your customers are already expecting this level of intelligent automation. 

The choice isn’t whether to adopt AI agents, it’s whether you’ll lead the transformation or be forced to catch up later. 

The exploration list above isn’t optional. It’s your roadmap to staying relevant in a world where intelligence is becoming the default expectation for every business process. 

Start exploring. Start today. The future doesn’t wait for anyone to be ready. 

<>Want to know more? Contact me know!

Continue reading