Dużo się mówi od pew­ne­go cza­su o archi­tek­tu­rze sys­te­mów infor­ma­tycz­nych zorien­to­wa­nej na usłu­gi (SOA, ang. Service Oriented Architecture) . Jest to trend zmie­rza­ją­cy w stro­nę budo­wy tych sys­te­mów pod kątem spe­cja­li­zo­wa­nych potrzeb biz­ne­so­wych. Opisane wcze­śniej pro­ce­sy biz­ne­so­we to nasze potrze­by zaś sys­tem to świad­czą­ca nam pew­ne usłu­gi infra­struk­tu­ra. Jeżeli jed­nym z pro­ce­sów biz­ne­so­wych jest w fir­mie fak­tu­ro­wa­nie to nasz sys­tem infor­ma­tycz­ny powi­nien świad­czyć usłu­gę wspie­ra­ją­cą ten pro­ces w posta­ci np. pro­gra­mu lub jego modu­łu dedy­ko­wa­ne­go do pro­ce­su fak­tu­ro­wa­nia. Program taki lub jego moduł powi­nien ope­ro­wać taki­mi dany­mi jakie my w fir­mie wyko­rzy­stu­je­my. To jest ten moment, w któ­rym to my okre­śla­my wyma­ga­nia na pro­gram a nie dostaw­ca narzu­ca nam moż­li­wo­ści swo­je­go sys­te­mu. Zawsze moż­li­we jest to, że dany pro­dukt nie speł­nia naszych wyma­gań i nie powin­no się z nie­go po pro­stu zrezygnować.