There are different definitions of a pattern, these include:
- An abstraction from a concrete form which keeps recurring in specific, non-arbitrary contexts.
- A recurring solution to a common problem in a given context and system of forces.
- A named "nugget" of instructive insight, conveying the essence of a proven solution to a recurring problem in a given context amidst competing concerns.
- A successfully recurring "best practice" that has proven itself in the "trenches".
- A literary format for capturing the wisdom and experience of expert designers, and communicating it to novices
Despite the differences, they all come down to ‘let’s not reinvent the wheel’. My own pattern for helping development of an application architecture is shown below:
- Simple Core – these are the services for the main functions of the business, probably COTS packages to create a stable basis for the business.
- Special Functions – the COTS packages in the Simple Core do not cover 100% of the main processes and therefore specialist software is required to fill the gaps.
- Market Facing – different channels to market will require specific solutions and high agility is nearly always required. These services need to be separated from the Simple Core.
- Bulk Data – all major external feeds in and out of the other parts of the systems lie in this area.
- Management Information – this creates the separation of MIS from operational systems. A mix of MIS solutions can exist, some long lived others quick responses to business needs.
Clearly, different principles apply to each of these domains and the application architecture, with its underlying pattern, greatly facilitates the understanding of these issues.
A large organisation with different lines of business will require more than one application architecture. The links between or overlaps of services across the architectures depends on the level of integration in the organisation.
Comments