To SCRUM team utvikler separate deler av et system, inkludert et API for kommunikasjon mellom dem. De jobber smidig, så de ønsker å kunne gjøre raske endringer - "omfavn forandring" - men hva med endringer i APIet når dette først er definert?
Det vil naturlig være en høyere terskel for å endre APIet enn for å gjøre interne endringer i hvert av subsystemene. APIet representerer det eneste synlige av den "svarte boksen" som det andre systemet forholder seg til, så forandringer i APIet griper inn i det andre teamets arbeid. Et APIs natur er å i stor grad å være en stabil protokoll.
Siden dette er et "dobbelt" SCRUM-prosjekt, ville den åpenbare løsningen være å opprette et minimalistsik SCRUM-team for å håndtere selve APIet, med representanter fra begge teamene i produkteierrollen. Et begrenset SCRUM av SCRUM'er, kan en si. Hvis en gjør det på denne måten, trenger ikke APIet å utgjøre noen stor utfordring. I dette tilfelle er APIet definert som ikke-statisk.
Det kan være forhold som kompliserer endringer i APIet når det er satt i produksjon; Endringer i API vil kreve synkrone publiseringer av de to subsystemene. Nå kan det være forskjeller i publiseringsprosessene: En ny versjon av backend-siden av APIet kan kreve nedetid på systemet og mye administrasjon av f.eks. pågående transaksjoner, mens klientoppdatering kan være så lett som helst.
For at begge team skal kunne dra nytte av det å faktisk ha et API som et fornuftig grensesnitt mellom subsystemene blir det viktig å administrere APIet.
Ulike mulige strategier:
- Krev at APIet er staisk og komplett i første omgang: En endringsforespørsel ville bli håndtert omtrent på samme måte som de ville bli i et tradisjonelt fossefallsprosjekt - regnet som en feil i spesifikasjon eller design, eller i det minste som et nytt krav og kostnaden ville bli fakturert (bokstavelig eller billedlig talt).
- Introduser et versjonert API for å tillate fleksibel oppgradering av funksjonalitet. Med mindre dette er lanlagt inn fra starten ville det ikke være fungere ulikt alternativ 1).
- Bygg fleksibilitet inn i APIet. Et SQL-basert databasegrensesnitt kan anses som et fleksibelt grensesnitt, siden en kolonne kan bli lagt til uten at noen applikasjon nødvendigvis må endres og til og med uten at databaseserveren som tilbyr dette APIet må omstartes.
Publiserte APIer kan utvides, men ideelt sett ikke endret. Hvis du brukte MS Office COM-grensesnitt for å fjernstyre Word eller Excel på 1990- og 2000-tallet, kunne du stole på at applikasjonen din fortsatt ville virke med en ny versjon av MS Office. For å ta i bruk ny funksjonalitet måtte du nødvendigvis tilpasse applikasjonen, men du ville ikke trenge å endre det eksisterende. MS Project - applikasjonen, derimot, ble drastisk endret fra versjon 95 til 98 - noe som indikerte minst to ting: 1) Det var ikke en stor brukerbase, og 2) produktet var umodent ("...og er 98-versjonen moden?") Det samme var tilfellet med MS InfoPath, som ble drastisk endret i 2007. Etter å ha erfart disse endringene var min konklusjon å unngå bruken av dem - av både grunn 1) og grunn 2).
Når man snakker om APIer i dag, ville man normalt tenke WebAPI. Er det forskjeller mellom disse og de nevnte MS-APIene ? "Ja og nei", ville jeg si. Webapplikasjoner endres raskt, levetiden kan være kort. Å være i front er viktigere enn det vil være for et in-house administrativt system, så livssyklusen kan være vesentlig kortere. På den andre siden ville kunder til et Web API normalt ha ulike alternativer slik at utgiveren av APIet ville være proporsjonalt redd for å lage snublesteiner for dem. API-klienter har ikke nødvendigvis store ressurser til rådighet for å håndtere hyppige endringer. Og husk - den gamle Word 2000 kan fortsatt kjøre som del av et system den dag i dag...
Det kreves tillit for å inkludere en ekstern kilde som del av din webapplikasjon, mye som når du velger et produkt; Du vurderer kvalitet, og du vil trolig gjøre en vurdering av hvorvidt produktet vil supporteres og finnes tilgjengelig i det relevante tidsperspektivet. I tillegg krever det investering i kunnskap og muligens verktøy for å ta i bruk et produkt. Relevansen til et API er avhengig av både brukbarhet og tillit.
Konklusjon: APIer er i sin natur statiske og jo mer statisk jo bedre. Ikke veldig kompatibelt med smidig metodikk ? Kan se slik ut, men om du kontrollerer begge sidene av APIet trenger det ikke å være et problem. Også, å utvide et API er fremdeles mulig uten å bryte noen kontrakter.