La SOA, c'est l'agilité de l'entreprise. Un des moyens d'y parvenir est d'identifier les composants métier du coeur de métier. Un fois ces composants métier identifiés, les processus métier et les services associés à ces processus métier peuvent être identifiés et spécifiés. Une fois ces processus métier et ces services identifiés, la décomposition du processus métier révèle quels services logiciels réutilisables sont nécessaires pour approvisionner ces processus métier et ces services. D'un point de vue informatique, ces services peuvent être modélisés comme des cas d'utilisation et les exigences fonctionnelles et non-fonctionnelles peuvent être tracées (dans un outil comme Rational Rose Requisite Pro). Comment peut-on gérer la complexité d'un tel environnement ? En particulier, comment peut-on construire ces services pour s'assurer que les exigences non-fonctionnelles de ces services soient satisfaites ? Les design patterns sont un des moyens de gérer cette complexité. Les patterns sont une solution reproductible à un problème dans un contexte donné, et sont typiquement décrits par une spécification du pattern. Certains sites se sont spécialisés dans les patterns pour SOA. Dr. Eoin Lane, Senior Solution Engineer chez IBM, maintient le blog Building SOA applications with patternssur le site de developerWorks d'IBM. On y trouve de nombreux articles sur l'architecture SOA et les patterns, et des exemples complets de patterns. Arnon Rotem-Gal-Oz, responsable développement dans une société israélienne, est en train d'écrire un livre, « The SOA Patterns book ». Sur son blog, SOA patterns a Anti-Patterns, il dévoile l'avancée de son ouvrage et livre les drafts de quelques chapitres. Le blog Patterns for Service-Oriented Architectures suit l'actualité des patterns SOA. On y trouve un catalogue de patterns SOA, des liens vers des entrepôts de patterns, un glossaire en cours, des liens, etc.