Skip to main content

Author: Robin Wilde

Determinism vs Nondeterminism

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

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

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

Integration Love Story med Tom Canter

Följ med när vi välkomnar Harold Campos, erfaren Principal Program Manager på Microsofts AST-team.

Alla aktuellt

Integration love story

I det här avsnittet möter vi Tom Canter – som efter 25 år i integrationsvärlden fortfarande lär sig nya saker varje dag

Om videon inte spelas. klicka här:
Youtube: Integration Love Story med Tom Canter
Spotify: Integration Love Story med Tom Canter

I det senaste avsnittet av Integration Love Story gästas vi av Tom Canter, en legendar inom integrationsvärlden som delar med sig av en karriär fylld av nyfikenhet, misstag, lärdomar och experimentlust.

Vi pratar om varför integration handlar om att få system som aldrig var tänkta att prata med varandra att faktiskt göra det och varför detta arbete kräver både teknisk kompetens och mänsklig nyfikenhet.

Tom berättar om sin passion för pianospel och dykning, och hur båda aktiviteterna gett honom perspektiv på sitt arbete som integratör. Han delar också med sig av hur han tillsammans med vänner i sitt grannskap i Seattle byggt upp ett AI-baserat verktyg – SwiftMate – som med hjälp av agentisk AI lyckas korta ner en veckas arbete till bara några minuter.

Vi pratar om vikten av att börja smått när man experimenterar med AI, varför Logic Apps Agent Loop är ett verktyg som gör skillnad, och hur communityn inom integration gång på gång visar sin styrka. Det här är ett avsnitt där teknik möter mänsklighet och där kärleken till integration syns i varje mening.

Feel free to contact me. Let’s discuss these exciting developments together!

Continue reading

New Capabilities to Prevent Misconfigurations in API Management

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

När verksamhetsförståelse avgör integrationspartner

“Det är skillnad på dom som vill och dom som kan.”

“Det är skillnad på dom som vill och dom som kan.”

Orden yttrades av vd:n för ett svenskt rederi när han, tillsammans med sin projektansvarige, besökte oss på Contica. De hade redan pratat med flera leverantörer, tagit in offerter och jämfört förslag. Men det som avgjorde var inte bara det tekniska lösningsförslaget, det var vår förståelse för deras verksamhet.

Vi är både glada och stolta över att ha blivit valda som partner i ett projekt som kommer att spela en nyckelroll i deras digitala resa. Särskilt eftersom det handlar om en bransch vi känner väl. Under åren har vi arbetat med flera bolag inom rederi, transport och sjöfart vilket har gett oss en djup förståelse i hur logistikkedjan fungerar på riktigt. Vi vet hur affären hänger ihop, var flaskhalsarna uppstår, och vad som krävs för att teknik faktiskt ska skapa nytta. Ofta handlar nytta om att eliminera manuell handpåläggning. Ibland handlar det om datainsamling för att skapa möjligheter som inte tidigare fanns.

Detta projekt handlar i nuläget om att eliminera onödigt manuellt arbete. Bokningsflödet hos rederiet hanteras idag till stor manuellt och är väldigt tidskrävande. Tid som riskerar att fördubblas med att verksamheten växer.

Vårt uppdrag är att digitalisera bokningsprocessen och målet är tydligt:
Automatisera upp till 90 % av alla bokningar och samtidigt lägga en digital grund för fortsatt tillväxt.

Är du verksam i sjöfarts- eller logistikbranschen och upplever att ni har för mycket manuella processer?

Vi pratar gärna med fler bolag som ser potentialen i att digitalisera bokningsflöden, koppla ihop system och frigöra tid från repetitivt arbete.

Kontakta oss på Contica. Vi kan rederibranschen och sjöfartslogistik, och vi vet hur man skapar lösningar som faktiskt fungerar i vardagen.

<>Kontakta Robin Wilde om du är nyfiken

Continue reading

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

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

Integration Love Story med Andrew Wilson

Följ med när vi välkomnar Harold Campos, erfaren Principal Program Manager på Microsofts AST-team.

Alla aktuellt

Integration love story

I det här avsnittet möter vi Andrew Wilson – Microsoft MVP – som delar sin resa från Excel-magi till enterprise-integration med Logic Apps och varför nyfikenhet är nyckeln i tech.

Om videon inte spelas. klicka här:
Youtube: Integration Love Story med Andrew Wilson
Spotify: Integration Love Story med Andrew Wilson

I det här specialavsnittet av Integration Love Story, inspelat på konferensen Integrate 2025 i London, träffar vi Andrew Wilson – nybliven Microsoft MVP.

Andrew berättar hur hans kärlek till teknik började redan som barn, när Excel och VBA kändes som ren magi, och hur den nyfikenheten så småningom ledde till att han idag bygger integrationslösningar med Logic Apps för verksamhetskritiska system.

Vi pratar om varför integration är kraftpaketet bakom varje digital upplevelse, vad som gör Logic Apps så unikt och varför Andrews främsta råd till nya utvecklare är att alltid förbli nyfiken. Han delar också med sig av sina viktigaste lärdomar från Integrate 2025 – där både Logic Apps Agent Loop och kodfokuserade arbetsflöden pekar mot en ny integrations-era.

Ett kort men inspirerande samtal om community, nyfikenhet och varför integration i grunden handlar om att förbättra andras sätt att arbeta.

Feel free to contact me. Let’s discuss these exciting developments together!

Continue reading

Vad kostar det att inte migrera från BizTalk?

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

Integration Love Story med Divya Swarnkar

Följ med när vi välkomnar Harold Campos, erfaren Principal Program Manager på Microsofts AST-team.

Alla aktuellt

Integration love story

Varför Agent Loop är beroendeframkallande och hur feedback är nyckeln till utveckling – Ett samtal med Divya Swarnkar från Microsoft

Om videon inte spelas. klicka här:
Youtube: Integration Love Story med Divya Swarnkar
Spotify: Integration Love Story med Divya Swarnkar

I det här specialavsnittet av Integration Love Story, inspelat live på konferensen Integrate i London, pratar vi med Divya Swarnkar – Product Manager på Microsoft och en av nyckelpersonerna bakom Logic Apps och dess växande AI-funktioner.

Divya beskriver Agent Loop med ett ord: “beroendeframkallande.” När du har byggt din första AI-drivna agent vill du bara fortsätta. Det var precis vad som hände henne – och den entusiasmen sprider sig nu över hela Logic Apps-teamet och vidare ut i integrations-communityn.

Vi pratar om hur Logic Apps utvecklas till en naturlig plattform för AI-agenter, varför integration står i centrum för framtidens affärsprocesser, och varför det här kan vara det mest spännande ögonblicket hittills att jobba med integration.

Divya berättar också hur hon började sin resa i Logic Apps-teamet – som kund – och hur användarnas feedback fortfarande är helt avgörande för produktens utveckling.

Ett kort avsnitt, men fullt av insikter, energi och smittande passion. Men ett varningens ord: Agent Loop kan vara beroendeframkallande.

Feel free to contact me. Let’s discuss these exciting developments together!

Continue reading