Systemutvecklare har alltid tampats med att mjukvara blir mer och mer komplex. Det har alltid funnits ett behov av att återanvända programkod för att slippa uppfinna hjulet om och om igen. SOA försöker lösa det problemet på ett så bra sätt som möjligt.
Själva grundkonceptet med en SOA är att en verksamhet ska kunna bygga en applikation eller ett system av en samling oberoende, men ändå samarbetande, tjänster eller subsystem. Dessa delar kan vara skrivna i vilket som helst programmeringsspråk och köras på olika plattformar. Oasis Reference Model for Service Oriented Architecture 1.0 beskriver SOA på följande sätt: ”Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains.”
En av anledningarna till att koncept som SOA växt fram är att det inom organisationer ofta funnits, och till väldigt stor del fortfarande finns, många olika system utan kontakt med varandra där samma data finns på flera ställen. En växande anledning till att det finns flera system utspridda över världen är såklart globaliseringen idag. Om ett företag i Indien kan leverera en komponent till halva priset, så beslutar sig ofta företagsledningen för att köpa den därifrån trots att resten av systemet kanske befinner sig i t.ex. Sverige. Detta leder självklart till flera svårigheter, bland annat att hålla all data som är utspridd uppdaterad och konsistent.
Det finns givetvis även några nackdelar och svårigheter med att använda SOA. Det som oftast lyfts fram är avsaknaden av ett gemensamt vokabulär, termer heter olika beroende på vem som är leverantör eller författare.
Då SOA trots allt är relativt nytt och obeprövat så finns det dessutom en viss avsaknad av praktisk erfarenhet bland utövare, men dess popularitet ändrar på situationen dagligen. Avsaknaden av praktisk erfarenhet bland kunniga kan även vara anledningen till varför SOA inte blivit kritiserat i någon större omfattning. Det är lätt att hitta fördelar med SOA, men svårt att hitta kritik och nackdelar.
I en övergång till en SOA så behövs ändringar inte bara inom IT utan också inom verksamheten själv. Det behövs organisations- och styrningsmodeller som tillåter en vidare flexibilitet i verksamheten. SOA kan inte ses som någon förbestämd handlingsplan utan betyder ofta olika saker beroende på vem som ska utföra en förändring. För chefer kan en SOA innebära en ändrad syn på hur dessa ska styra verksamheten och hur relationerna till andra företag ser ut, och inte minst framför allt kostnaden för övergången till SOA. En IT-utvecklare däremot kanske bara ser vilka system som denne ska koppla ihop och få att fungera tillfredsställande.
