Skip to Content

IT architecture patterns

Design patterns for software development have been best practice since “Elements of Reusable Object-Oriented Software” by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides. Although IT architecture patterns are still in their infancy according to TOGAF Version 9, they provide a very practical and meaningful way to operationalize IT architecture principles. The reason is that patterns can be matched against actual requirements. Therefore the desired solution is regularly chosen except for special circumstances for which an exception process is implemented.

There are two levels of IT architecture patterns. Generic patterns describe business or IT architecture requirements and are universally applicable. Concrete patterns apply the generic patterns to specific circumstances and contain the actual recommendations. TOGAF Version 9 does not discuss generic patterns and divides concrete patterns into

  • Architecture patterns
  • Design patterns
  • Idioms

In my point of view this distinction is too detailed for IT architecture patterns and therefore I do not apply it. The structure of a concrete IT architecture pattern suggested by TOGAF Version 9 however I find very useful.


Generic pattern




A process spanning multiple applications has to be implemented.



If users have to log into different applications to perform a single process they have to store the context of that process themselves, often in Excel sheets, Word documents or even on paper. This is error prone and can lead to breaking the process, i.e. requiring the user to log into a prior application again after unsuccessfully trying to continue the process in a following application.


If users have to store the context of a process themselves this requires additional processing time and is therefore inefficient.


If users have to store the context of a process themselves this is error prone and can lead to inconsistent data in the different applications.


Build a composite application that starts in one application and spans over the other applications of the bridge process while keeping the process context.

Resulting context

The user is freed from the duty to keep the process context.


  • Service requests captured in a CRM system that need material master information from an ERP system.
  • Production orders that need material delivery information from a partner company.
  • Customers updating the ATP information in their ERP based on updated lead times.


The process context is kept in the composite application eliminating the need for the user to keep it.

Related patterns

  • Business information warehouse
  • Master data management

Known uses


Concrete pattern


Bridge SAP to SAP internally


A process spanning multiple internal SAP applications has to be implemented.


SAP Composite Application Environment (CE).


CE provides an easy way to integrate a process with other SAP solutions via web service calls.

Concrete Pattern


Bridge to EDI partner


A process spanning from an internal application to a partner application using the electronic data exchange protocol (EDI) has to be implemented.


Outsource to Crossgate.


Maintaining an in-house EDI gateway has proven to be expensive and inflexible.

Concrete Pattern


Bridge to customer


A process spanning from a customer application to an internal application has to be implemented.


SAP Enterprise Portal


Customer to in-house processes are best implemented as customer self service solutions.

Generic patterns

Process patterns

Common process patterns are

  • Request / refine / approve
  • Analyze / decide
  • Handle exception
  • Fork / join
  • Bridge

Integration patterns

Common integration patterns are

  • Synchronous versus asynchronous
  • File based versus message based
  • Secure
  • Exactly once
  • In order
  • Transactional

Deployment patterns

Common deployment patterns are

  • Local versus regional versus global
  • Flat versus hierarchical
  • High available
  • Redundant

Information management patterns

Common information management patterns are

  • Transactional
  • Business information warehouse
  • Master data management

Access patterns

Common access patterns are

  • Power user versus occasional user
  • Fat client versus thin client
  • Stateful versus stateless
  • Transactional

Operations patterns

Common operations patterns are

  • Onshore versus nearshore versus offshore
  • Insourced versus outsource
  • Service level management

Concrete patterns

Concrete patterns have to be derived from the above generic patterns and fully depend on the circumstances. It is hardly possible to generalize those.

Be the first to leave a comment
You must be Logged on to comment or reply to a post.