Middleware (oprogramowanie pośredniczące) to warstwa oprogramowania między systemami lub aplikacjami, która umożliwia im komunikację mimo różnic w technologiach, formatach i protokołach. Typowe formy: szyny integracyjne (ESB), brokery komunikatów (np. RabbitMQ, Kafka), API gateway, serwery integracyjne.
Analityk biznesowy middleware'u nie projektuje - ale musi rozumieć, że istnieje i co robi, bo to przez tę warstwę przechodzą wszystkie wymagania integracyjne. Zdanie „system A wyśle dane do systemu B" brzmi w dokumencie niewinnie; w rzeczywistości między A i B siedzi pośrednik, który tłumaczy formaty, kolejkuje komunikaty, ponawia nieudane wysyłki i decyduje, co się dzieje, gdy B nie odpowiada. Każda z tych rzeczy to potencjalne wymaganie.
W MediFlow portal pacjenta nie rozmawia ze starym HIS-em bezpośrednio - pośredniczy szyna integracyjna. Powody są praktyczne: HIS mówi w HL7, portal w REST/JSON - ktoś musi tłumaczyć. HIS pada co noc na 40 minut podczas backupu - szyna kolejkuje wtedy rezerwacje i dosyła je po wznowieniu, dzięki czemu pacjent o 2:30 w nocy normalnie umawia wizytę, nieświadomy, że system po drugiej stronie śpi. Bez middleware'u portal musiałby wyświetlać „spróbuj później" - i właśnie tę różnicę analityk zapisał jako wymaganie, zanim architekci wybrali rozwiązanie.
Częsta pomyłka: pomijanie warstwy pośredniej w wymaganiach niefunkcjonalnych. Opóźnienia, gwarancje dostarczenia, kolejność komunikatów, obsługa duplikatów - to wszystko rozstrzyga się w middleware. Jeśli analityk tego nie opisze, zdecydują deweloperzy w trakcie implementacji; czasem trafnie, czasem dowiesz się przy pierwszej awarii.