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.
Example
Generic pattern
Name
Bridge
Context
A process spanning multiple applications has to be implemented.
Forces
Fault-tolerance
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.
Efficiency
If users have to store the context of a process themselves this requires additional processing time and is therefore inefficient.
Correctness
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.
Solution
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.
Examples
- 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.
Rational
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
n/a
Concrete pattern
Name
Bridge SAP to SAP internally
Context
A process spanning multiple internal SAP applications has to be implemented.
Solution
SAP Composite Application Environment (CE).
Rational
CE provides an easy way to integrate a process with other SAP solutions via web service calls.
Concrete Pattern
Name
Bridge to EDI partner
Context
A process spanning from an internal application to a partner application using the electronic data exchange protocol (EDI) has to be implemented.
Solution
Outsource to Crossgate.
Rational
Maintaining an in-house EDI gateway has proven to be expensive and inflexible.
Concrete Pattern
Name
Bridge to customer
Context
A process spanning from a customer application to an internal application has to be implemented.
Solution
SAP Enterprise Portal
Rational
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.
