Dit model beschrijft de bedrijfsprocessen en de entiteiten die daarin een rol spelen. Ook los van de IT zou elke organisatie zo'n model op orde moeten hebben, maar in de praktijk valt dit nog wel eens tegen. Als er gekozen is voor UML als standaard modelleringstaal, dan kunnen de bedrijfsprocessen met activity diagrams beschreven worden en de bedrijfsentiteiten met class diagrams en zonodig state machine diagrams. Voor een goed begrip moeten de elementen die in deze schema's voorkomen goed tekstueel worden toegelicht.
Het is raadzaam om de bedrijfsgegevens vrij gedetailleerd te specificeren in wat wel een 'domeinmodel' genoemd wordt. Eventueel kan dit als een apart model beschouwd worden, met verwijzingen naar het minder gedetailleerde business model. In het domeinmodel worden de attributen van de entiteiten benoemd en alle gegevensgerelateerde bedrijfsregels vastgelegd. Van bijvoorbeeld de entiteit 'Adres' wordt nauwkeurig vastgelegd uit welke onderdelen het bestaat, onder welke voorwaarden het adres volledig is, of buitenlandse postcodes worden ondersteund etc. Een dergelijk model vormt een goede gemeenschappelijk basis voor het functioneel model en het service model.

Bij elke applicatie hoort een functioneel model. Dit beschrijft, zoals het woord al zegt, de functionaliteit van de applicatie. Voor een webapplicatie kan dit bijvoorbeeld een combinatie van een HTML prototype plus een verzameling user stories of use cases zijn. Het is vaak ook handig om een overzicht van alle paginaovergangen in een schema weer te geven. Een UML state machine diagram is hiervoor geschikt. Voor de gegevens en de business rules kan verwezen worden naar het business model.

Het service model is het geheel aan informatie over alle software services in de organisatie, zowel de grote lijnen als de details. Een service ondersteunt een bepaald bedrijfsproces of beheert de gegevens van een bepaalde bedrijfsentiteit; vandaar dat het service model refereert aan het business model. Als het business model is opgedeeld in meerdere domeinen, dan kunnen we die opdeling in het service model ook toepassen.
Een overzicht van services en hun onderlinge connecties kun je het beste weergeven in een UML composite structure diagram. De interfaces kun je tekstueel vastleggen en de messages in class diagrams. Eventueel kun je protocollen definiëren m.b.v. state machine diagrams en in interaction diagrams kun je weergeven hoe services met elkaar samenwerken.

Dit is het technisch ontwerp van een service, een applicatie of een generieke component (een component die in meerdere applicaties en/of services wordt gebruikt). Het beschrijft uit welke (sub)componenten de service/applicatie/component is opgebouwd en hoe die componenten met elkaar samenwerken. Het design model geeft inzicht in de structuur en werking van de software, althans voldoende om vervolgens, wanneer je meer details wilt weten, deze gemakkelijk te kunnen vinden in de source code.
Ik adviseer om vooral sequence diagrams te maken, die de voornaamste scenario's inzichtelijk maken. Als er groepen componenten, bijvoorbeeld "lagen", te onderkennen zijn, dan kunnen deze in een package diagram afgebeeld worden. Niet-triviale datastructuren kunnen in class diagrams worden weergegeven en soms zijn ook andere diagramsoorten, zoals state machine diagrams nuttig.
Het design model van een service refereert uitsluitend naar het service model en het design model van een applicatie refereert zowel naar het functioneel model van die applicatie, als naar het service model voor alle services die door de applicatie gebruikt worden.

In het deployment model wordt vastgelegd welke hardware en welke netwerkvoorzieningen er gebruikt worden. Je specificeert ook welke applicaties en services op welke machines worden geïnstalleerd.
Het UML deployment diagram is speciaal bedoeld om dit soort zaken grafisch weer te geven.