patterns veryard projects > patterns

we offer	about patterns	pattern languages and catalogs	links
consultancy management briefings independent advice on tools and methods	A pattern is a judgement, partially abstracted from its context. It may be positive or negative, and may apply across multiple domains. Purpose. A popular misunderstanding about patterns is that they are merely abstract components – prefabricated chunks of analysis or design that can be instantly assembled into a solution – the engineering equivalent of convenience foods.  read more >> Form. Patterns are often described as solutions in context.  But within the software engineering world there has been a strong emphasis on reuse.  In order to reuse something, it has to be taken away from its original context – at least to some extent – and generalized so that it can be plugged into a range of contexts. read more >> Process. A pattern language represents a shared repository of knowledge.  This implies a process of disseminating and using this knowledge.  It also implies a process of maintaining and refreshing the knowledge. read more >> Material. Patterns come out of lived experience.	Pattern languages have been created in various domains, starting with Towns, Buildings and Construction, and spreading to software engineering (especially OO). If you're looking for patterns relating to components in business, start with the CBDi Forum Pattern Catalog. There are now some emerging patterns and pattern languages for business and organization.  Many of these are published in the form of best practice databases. For some reason, distributed systems design has lagged behind other parts of software engineering in the identification and use of patterns. On this page, we indicate the pattern sources we've found, and suggest some additional patterns for distribution. We also hope to create a pattern language for managed change, with particular attention to technology transfer, adoption and/or implementation. This work is in its early stages.  Please tell us about your favourite patterns or pattern sources	book list contact us

Purpose

A popular misunderstanding about patterns is that they are merely abstract components – prefabricated chunks of analysis or design that can be instantly assembled into a solution – the engineering equivalent of convenience foods. Anyone who reads Christopher Alexander’s original work on patterns cannot fail to sense an entirely different passion and purpose for patterns – the need for quality in the finished product – a quality that Alexander calls The Quality Without a Name.

On this view, patterns are not intended to make the engineering process faster or more efficient – or even more reliable. The purpose of patterns is to impart character to an artefact.  Pattern languages are intended to help engineers communicate an awareness of the character and quality of design – with one another and with their clients.
 

Form

Patterns are often described as solutions in context.  This description can be traced back to Christopher Alexander, sometimes seen as the father of patterns, who is very keen to emphasize the grounded, context-dependent nature of true patterns.

Within the software engineering world, in contrast, there has been a strong emphasis on reuse.  In order to reuse something, it has to be taken away from its original context – at least to some extent – and generalized so that it can be plugged into a range of contexts.  This means that a pattern has to be partially abstracted from its context.

Good pattern work has always maintained tension between two opposite positions – the immanent and the transcendental – between solutions that are grounded in the specifics of a given situation, and solutions that are timeless and universal.  Alexander expresses this tension by insisting that you can use a pattern a million times over, without ever doing it the same way twice.  In a manner of speaking, this is repetition without repetition.

A pattern has the structure of a judgement  – it involves an appreciation of a situation, leading to an intelligent response or action.  This leads me to define a pattern as a judgement partially abstracted from its context.

The business problems addressed in many patterns are sketched rather than fully defined.  This makes it quicker to read the pattern and recognize whether it might be relevant to the problem facing you.  But it means that the onus remains on you to investigate the problem in detail and work out how to use the pattern in this specific context.
 

Process

A pattern language represents a shared repository of knowledge.  This implies a process of disseminating and using this
knowledge – deploying the pattern language.  It also implies a process of maintaining and refreshing the knowledge –
testing the implicit hypotheses and assumptions, polishing the structures, formulating alternatives and improvements, and
perhaps abandoning certain patterns that have outlived their usefulness.

Publishing patterns, either individually or packaged into languages and catalogs, only makes sense if it fits into a cycle of knowledge generation and critical evaluation and evolution.  There is an obligation on the author and publisher to release updates and revisions. There is also an obligation on the reader and user of the pattern language, to participate in the improvement cycle, by contributing critical comment and experience – and we hope that the Internet will facilitate such participation.
 

Material

Patterns should come out of lived experience.  They communicate something that has worked – and worked repeatedly.

A useful source of business patterns seems to be the management journals. Sloan Management Review and Harvard Business Review publish lots of ideas of business strategy and organizational design that could be expressed as patterns. The best articles show how the same basic idea is applied in different ways to a variety of practical situations, with an evaluation of the various outcomes.

There are some interesting relationships between patterns in different domains - for example between business patterns, and technical distribution patterns. Some of the patterns (such as Federation) are the same in both, albeit with different interpretations and implementations. However, the patterns of managed change often conflict with the principles of distribution. For example, Concentration of Power.

This encourages some pattern authors to create patterns based on metaphor - where something that works in one domain is assumed to work in another domain, without detailed justification.
 

	business patterns (pdf) implementing a pattern programme design pitfalls as negative patterns reuse
	CBDi Forum Pattern Catalog patterns home page

Most of these patterns concentrate on the computational, engineering and technology viewpoints of RM-ODP.

Some of the patterns for distribution are embedded in particular middleware or TP products. Many of these patterns are specific to particular products. It seems to be difficult to identify technical patterns that are equally valid for DCOM and CORBA, not to mention other middleware as well.
 

on this page	internet sources	books
Federation Front Office Late Binding Optimistic Locking Stateless Client Stateless Server Zero Latency	The Nine Laws of God (Kevin Kelly) - inspiring, but hard to apply Implementation solutions for common distributed computing requirements (RM-ODP) - implied pattern instances, including Binder, Channel, Interceptor & Stub Communication patterns for networked systems (Doug Schmidt) - includes classic patterns for implementing load balancing, event management, and resource management Telecommunications Distributed Processing Patterns (Bell Labs 1995) - mostly data modelling patterns - but includes System Wide Pressure Gauge DASCo Project	Pattern-Oriented Software Architecture (Frank Buschmann &friends) - contains several patterns that cover infrastructure implementation, such as a distributed version of proxy, and a broker pattern (corresponding to Object Request Brokers) CORBA Design Patterns (Tom Mowbray &friends) - includes patterns for distributed computational architectures (computational in the ODP sense) - distribution covered from the application implementer's perspective, for general purpose apps

Note that this is an important stage in the lifecycle of a true pattern.  This catalogue is a critical element of our work in progress. All help welcome.
 

Access to Technical (and Social) Competence

Identified by Nord & Tucker as a key factor of successful innovation. They identify two sides to competence.

Technical Side - to do with the substance of the innovation

• what technology to use
• how to use it
• how to judge effectiveness in using it
Social Side - ability to activate and coordinate the resources of the organization
• divide labour in appropriate ways
• motivate performance
• integrate activities to achieve desired outcomes

Structure

A formal definition of this pattern needs to identify a set of structural relationships between the technology or other innovation, the organization, and the required competences.

Discussion

This currently lacks enough structure to be regarded as a proper pattern.

Concentration of Power

Identified by Nord & Tucker as a key factor of successful innovation.

It is difficult to extract a proper pattern from their discussion. Their main concern seems to be to provide evidence against the use of the contrasting pattern: Delegation.

Delegation

Push power down to lower levels.

Contrasting pattern: Concentration of Power.

Federation (business)

Federation is a method of scaling up organizations (organizational solutions). It can be used for interconnecting previously disjoint organizations (reducing interaction distance) and for partitioning previously fully connected organizations (increasing interaction distance).

The distinguishing feature is the use of negotiation to bring potentially competing and noncooperating parties together. Firms that adopt or evolve into this model [i.e. federalism] typically have strong central leadership and a culture that encourages cooperation and learning. Accomplishing it, of course, requires negotiating skills, and the willingness of managers to take the time to negotiate.

Federation (distributed systems)

Federation is a method of scaling up distributed systems (technical solutions). It can be used for interconnecting previously disjoint systems (reducing interaction distance) and for partitioning previously fully connected systems (increasing interaction distance).

Flexibility

Identified by Nord & Tucker as a key factor of successful innovation. Flexibility itself isn't a pattern, but Nord & Tucker identify two patterns that they believe increase flexibility, and thereby promote successful innovation.
• Supple role boundaries
• Unconstrained communication

Front Office (distributed systems)

Transaction is uploaded onto client PC. Significant processing footprint on client.

Related pattern: Optimistic Locking

Contrasting pattern: Stateless Client

Late Binding (Distributed Systems)

'It is desirable to build a building in such a way that it starts out loose and flimsy while final adaptations in plan are made, and then gets stiffened gradually during the process of construction, so that each additional act of construction makes the structure sounder.' [Alexander: Gradual Stiffening]

For 'building' read 'organization' or 'system'. For 'construction' read 'implementation'.

Systems are stiffened when the imaginative and innovative use of new approaches and techniques is consolidated by the appearance of the novel as commodity accompanied by widespread acceptance. This means that the technical arguments have to be placed within a context of understanding the ramifications, both technical and economic, of the process of innovation.

Uses of the pattern

Improve the overall robustness of a system by improving the robustness of individual components. A good example of such stiffening is provided by the Astrophysics Data System developed by NASA, perhaps the best-known early example of ODP design. This system was first constructed using ANSAWARE but has now switched to DCE; this switch was because DCE was a supported commercial product, and ANSAWARE was not.

The overall risk of an investment can be greatly reduced if the commitment to procure the most expensive (or technologically dynamic) components can be postponed. There is an important distinction here between budget and spend. You might budget for so many copies of a particular middleware product on a particular platform, but when you come to spend the money later, you might have the opportunity to buy a cheaper and better product, on a different platform. Your having this flexibility increases the probability of this investment's turning out good.

Prototypes and pilots can be completed much more quickly if it is clearly understood that technical choices are not permanent commitments.

Related pattern

Dynamic binding.

Limitations of the pattern

Late binding of everything counts as dithering. You have to make your mind up about something; you cannot leave everything to the end. Look for particular areas of uncertainty where early commitment may be unwise.

Late Binding (Change)

Acquisition of generic capability, rather than specific knowledge/skill. Late binding promotes flexibility; late learning promotes intelligence (open-mindedness). For example, it has been said that it is better to go up to university a little older.

Uses of the pattern

Invest training resources in the most generic knowledge and skills possible. This extends the benefits from a given quantity of training, both in scope and in timescale.

Schedule the bulk of training after some initial experience has been gained. This helps the trainees link the training to the real world, in a rich way.

Limitations of the pattern

As with other manifestations of the Late Binding pattern, you have to start somewhere.

If the capability becomes too generic, it may be abstract/remote, difficult to acquire, and difficult to apply to real situations.

Listening to Staff

Attention to the views of those directly responsible for implementation.

Identified by Nord & Tucker as a key factor of successful innovation.

This can almost certainly be generalized into a general business / organization pattern.

Optimistic Locking

The client takes a copy of some data from the server. The data get out of synch, and are resynchronized at update time.

Stateless Client

All persistence is implemented through data.  There is no processing footprint on the client.

This is contrasted with the Front Office pattern.

Stateless Server

All persistence is implemented through data. The transaction leaves no processing footprint on the server.

This is a particularly useful pattern for Internet transactions.

Supple Role Boundaries

An aspect of Flexibility in Nord & Tucker's analysis.

Implies an ability to transcend precise job descriptions in order to get the job done.

Unconstrained Communication

An aspect of Flexibility in Nord & Tucker's analysis.

Lateral and/or upward communication ... allows information about a wide spectrum of unanticipated problems to flow to the people who have the skill and authority to make changes.

Seek information from a wide spectrum of organizational members.

[source: Nord & Tucker, p 311]

Unilateral Commitments

Alliances between firms can often be made stronger by unilateral commitments. These work by making a visible change to the firm's payoff structure, or by making an irreversible commitment to a particular course of action, so that the other firm is also encouraged to cooperate. This requires the partners of an alliance to go beyond simplistic analyses of cooperation in terms of the prisoners dilemma.
R. Gulati, T. Khanna & N. Nohria, 'Unilateral Commitments and the Importance of Process in Alliances' Sloan Management Review 35/3, Spring 1994, 61-69

Zero Latency

Don't replicate data around a distributed network

For example, when passing an instruction to a shipping company for a future delivery to a customer, don't pass the delivery address itself. Pass a URL so that the shipping company can lookup the current delivery address at the last minute.

The advantage of this pattern is that it prevents the continued dissemination and use of old or incorrect data.

The disadvantage of this pattern is that it lacks robustness. If the URL containing the current delivery address is unavailable on the scheduled delivery date, what does the shipping company do?

Pattern Books veryard projects > patterns > books

title	comment	ordering
Christopher Alexander and friends. A Pattern Language: Towns Buildings, Construction Oxford University Press, 1977	The classic text on patterns. Offers a catalogue of design patterns suitable for towns, buildings and construction. Standard reference for software patterns.
Martin Fowler. Analysis Patterns: Reusable Object Models Addison-Wesley Longman 1995	A set of common model fragments. See also Refactoring
Erich Gamma, Richard Helm, Ralph Johnson & John Vlissides. Design Patterns: Elements of Reusable Software. Addison-Wesley Longman 1995	The essential book on software patterns, by the so-called Gang of Four.
James Noble & Charles Weir. Small Memory Software Addison-Wesley 2001	Patterns for systems with limited memory. http://www.smallmemory.com
Walter R. Nord & Sharon Tucker. Implementing Routine and Radical Innovations D.C. Heath, Lexington, 1987.	An important book on change management. Nord & Tucker had the opportunity to observe and analyse twelve banks introducing the same innovation at the same time. Some of them are more successful than others. The authors identify four factors common to the successful implementations:  flexibility concentration of power access to technical competence listening to staff.
Adrian Slywotzky et al Profit Patterns US edition: Random House, 1999 UK edition: John Wiley, 1999
Terry Winograd et al. Bringing Design to Software. ACM Press and Addison-Wesley 1996	Not just a collection of essays about software design, but an interwoven and integrated text by several leading software thinkers and practitioners.

Contributions gratefully received from Ian Graham, Tom Mowbray, Howard Ricketts, Chris Russell, Chris Sluman, John Vlissides, Charles Weir & Lawrence Wilkes.

top home page contact us
in asssociation with	This page last updated on August 22nd, 2001 Copyright © 1997-2001 Veryard Projects Ltd http://www.veryard.com/sebpc/pattcat.htm