4 bÀsta praxis för Tech Stack-integrationer

0 Shares

Koppla in i en vÀgg av uttag.

“Dina forskare var sĂ„ upptagna av huruvida de kunde eller inte, att de inte stannade upp och funderade pĂ„ om de skulle”, sĂ€ger Dr. Ian Malcolm i filmen Jurassic Park.

Även om vi inte klonar dinosaurier, kan en liknande försiktighet tillĂ€mpas pĂ„ programvaruintegrationer.

Nuförtiden lever vi i en sÄ sammankopplad vÀrld att allt frÄn vÄra hushÄllsapparater till vÄr affÀrsprogramvara har förmÄgan att prata med varandra, och det Àr enklare Àn nÄgonsin för anvÀndare att integrera dessa verktyg med mÄnga webbappar som tillhandahÄller förkonfigurerade integrationer och öppna API:er.

Men innan du tÀnker pÄ vilken information som kan skickas mellan system mÄste du tÀnka pÄ din integrations mÄl, underhÄll och konsekvenser för andra verktyg eller intressenter.

HÀr Àr fyra bÀsta praxis att tÀnka pÄ nÀr du implementerar tekniska stackintegrationer:

1. HÄll anvÀndarnas behov i Ätanke

Varje integration bör börja med en vĂ€ldesignad anvĂ€ndarhistoria och förutsĂ€ttningar för tillfredsstĂ€llelse. En anvĂ€ndarberĂ€ttelse förklarar i en eller tvĂ„ meningar hur och varför en funktion kommer att ge vĂ€rde för en kund. Det sĂ€kerstĂ€ller ocksĂ„ att integratören förstĂ„r det verkliga anvĂ€ndningsfallet för integrationen. Till exempel, “Som sĂ€ljanvĂ€ndare vill jag att kundfĂ€lten i Salesforce ska uppdateras frĂ„n HubSpot i realtid sĂ„ att jag kan lita pĂ„ att bĂ„da verktygen har korrekt kundinformation.”

NÀr det gÀller integrationer, ger din integratör en anvÀndarberÀttelse snarare Àn förutbestÀmda, krÀvande kriterier som gör det möjligt för dem att bygga en anvÀndarfokuserad lösning med hjÀlp av kunskap som samlats in under hela skapelseprocessen.

Oavsett vilka verktyg du ansluter, Ă€r integrationen i sig aldrig slutmĂ„let – det Ă€r den praktiska tillĂ€mpningen av den integrationen för anvĂ€ndaren.

2. Utse en ansvarig part

Även om det kan verka som att en integration Ă€r statisk nĂ€r den skapas, Ă€r det bara en tidsfrĂ„ga innan en slutpunkt Ă€ndras, en sĂ€kerhetsnyckel uppdateras eller integrationen bara slutar fungera av ett antal anledningar. Kombinera det med flera administratörer som gör uppdateringar och du stĂ€ller in dig pĂ„ att fĂ„ problem som dyker upp till vĂ€nster och höger utan klarhet om vem som Ă€r ansvarig för att lösa dem.

Oundvikligen kommer integrationer att krĂ€va underhĂ„ll, och nĂ€r de gör det vill du att en individ som redan Ă€r bekant med input, output och potentiella fallgropar och som kĂ€nner till sin roll som ansvarig för integrationen ska vara beredd att ta steget – Ă€ven om flera personer kan göra uppdateringar.

För att hjÀlpa till att hantera detta pÄ New Breed skapade vi en ansvarsmatris som dokumenterar vem som Àr ansvarig för att övervaka varje verktyg i vÄr teknikstack och deras olika integrationer. NÀr det Àr oklart vem som Àr ansvarig för att göra förÀndringar kan du förvÀnta dig vad som alltid hÀnder i dessa situationer: nedprioriterade beslut och för mÄnga, eller för fÄ, kockar i köket.

3. Skapa omfattande dokumentation

Grundlig dokumentation av din integration frÄn början kommer att ge utdelning under dess livstid. Oavsett om det gÄr Ät tid till att förklara dess krÄngligheter, dechiffrera tvetydiga felkoder eller avkoda jargong, Àr bra dokumentation avgörande för att minska tiden och anstrÀngningen som lÀggs ner pÄ underhÄll pÄ vÀgen.

Att dokumentera ur ett utvecklingsperspektiv och ett slutanvĂ€ndarfelsökningsperspektiv Ă€r bĂ„da lika viktiga. Medan frĂ„gor som “Vad betyder den hĂ€r felkoden?” och “Varför har min data inte formaterats som jag förvĂ€ntar mig att den ska göra?” kan ha olika lĂ€sargrupper, de ger bĂ„da nödvĂ€ndiga sammanhang till personer som ska arbeta med integrationen.

Ett sĂ€tt vi dokumenterar integrationer pĂ„ New Breed Ă€r genom att anvĂ€nda flödesdiagramverktyg som kartlĂ€gger informationsflödet frĂ„n verktyg till verktyg, de olika “sanningarnas kĂ€llor” för datafĂ€lt och objektberoenden.

En annan vanlig form av dokumentation Àr kunskapsbaser fulla av skriftliga resurser som kan ge anvÀndarna vÀgledning om felsökning och anvÀndning av funktioner.

4. TÀnk pÄ integrationer nÀr du bygger ut din tekniska stack

NÀr du utvÀrderar nya verktyg för din tekniska stack, övervÀg de tillgÀngliga integrationsalternativen och hur du tÀnker att dina system ska prata med varandra.

Finns det förbyggda, inbyggda integrationer du kan anvÀnda? Behöver du en utvecklare för att bygga en anpassad integration? Behöver du anvÀnda middleware för att ansluta den plattformen till din andra programvara?

Plattformar med inbyggda integrationer till varandra Àr lÀttare att underhÄlla Àn de som inte gör det.

TÀnk ocksÄ pÄ vilken typ av automatisk testning och felloggning som redan finns. Kommer du att meddelas om en integration avbryts? Hur kommer denna integration att fungera nÀr ditt företag fördubblas i storlek?

Takeaway

Det finns en uppsjö av integrationer tillgÀngliga för dig, men behöver du dem alla?

För mÄnga integrationer eller alltför komplexa integrationer kan vara svÄra att hantera, sÀrskilt med en stor teknisk stack med flera plattformar.

Vissa integrationer ger inte mycket vÀrde, och om du bara stÀller in dem för att de var tillgÀngliga kanske de inte Àr vÀrda att underhÄlla. Det Àr viktigt att vara medveten om varför du kopplar ihop olika verktyg i din tekniska stack och sÀkerstÀlla att integrationen levererar vÀrde till slutanvÀndaren.

0 Shares