patternsveryard projects > patterns
|we offer||about patterns||pattern languages and catalogs||links|
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
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.
|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.
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 Alexanders 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.
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.
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.
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)|
|CBDi Forum Pattern Catalog|
|on this website||internet sources||books||other sources|
|Best Practices||Profit Patterns: The Website
Organization Patterns (Jim Coplien)
|New Rules for the New Economy
(Kevin Kelly) - shorter and more business-oriented than his previous book
Profit Patterns: The Book (Adrian Slywotzky)
|Sloan Management Review|
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||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
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
|on this page||internet sources||books|
|Access to Technical Competence||My main interest is in business strategy, technology
transfer and organizational change.
A great place to start is the short article Places to Intervene in a System (Donella H. Meadows, Whole Earth Review, Winter 97)
Most intervention patterns found on the internet are intended for individual and family therapy, or for international politics.
Intervention Center - Family Intervention for Addiction
|Implementing Routine and Radical
Innovations (Nord & Tucker)
A New Theory of Urban Design (Christopher Alexander &friends) changing physical environment
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
Technical Side - to do with the substance of the 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.
Contrasting pattern: Concentration of Power.
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.
Related pattern: Optimistic Locking
Contrasting pattern: Stateless Client
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.
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.
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.
If the capability becomes too generic, it may be abstract/remote, difficult to acquire, and difficult to apply to real situations.
Identified by Nord & Tucker as a key factor of successful innovation.
This can almost certainly be generalized into a general business / organization pattern.
This is contrasted with the Front Office pattern.
This is a particularly useful pattern for Internet transactions.
Implies an ability to transcend precise job descriptions in order to get the job done.
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.
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 Booksveryard projects > patterns > books
|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
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
|Patterns for systems with limited memory.|
|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:
|Adrian Slywotzky et al
US edition: Random House, 1999
|Terry Winograd et al. Bringing Design to
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.
Copyright © 1997-2001 Veryard Projects Ltd