Applying the concept of patterns to systems … the Concept of Patterns to Systems ... While much has been written about patterns in software ... APPLYING THE CONCEPT OF PATTERNS TO

Applying the Concept ofPatterns to SystemsArchitectureRobert J. Cloutier* and Dinesh Verma†

Stevens Institute of Technology, Castle Point on Hudson, Hoboken, NJ 07030

APPLYING THE CONCEPT OF PATTERNS TO SYSTEMS ARCHITECTURE

Received 31 March 2006; Revised 7 August 2006; Accepted 18 December 2006, after one or more revisionsPublished online in Wiley InterScience (www.interscience.wiley.com).DOI 10.1002/sys.20066

ABSTRACT

While much has been written about patterns in software engineering, little has been writtenabout their application to systems architecting. This paper provides a discussion of patternsand their potential applicability to complex system architecting. A historical introduction tothe concept of patterns is provided along with their evolution from the domain of civilarchitecture to other engineering disciplines and domains. The relevance and applicabilityof patterns to systems architecting is then examined. Research with regard to developing apattern form for documenting patterns for systems architecting is presented, and this isdemonstrated on a command and control pattern, using both IDEF0 and UML. The applicationof this pattern within a functional architecture is then explored. Finally, recommendations forthe development and management of a systems architecting and architecting pattern reposi-tory are offered. © 2007 Wiley Periodiocals, Inc. Syst Eng 10: 138–154, 2007

Key words: systems architecture; architecting; pattern; documenting patterns; pattern reposi-tory; knowledge

1. INTRODUCTION AND DEFINITIONS

Today’s complex systems make it difficult for systemsarchitects to mentally juggle the system details and

nuances. Models help in that arena, and patterns areexamples of models, or abstractions of reality. As sys-tems become more complex, the need for a method tocapture and manage implicit knowledge within corpo-rations and within the systems architecting disciplinegrows. This implicit knowledge should be socialized tosuch an extent that it can be made explicit. Furthermore,

Regular Paper

* Robert Cloutier is the primary author of this paper and is the authorto whom all correspondence should be addressed (e-mail:[email protected]). † E-mail: [email protected]

Systems Engineering, Vol. 10, No. 2, 2007© 2007 Wiley Periodicals, Inc.

138

this explicit knowledge needs to be properly docu-mented such that it can be applied when relevant tosolve similar problems. Patterns may be a partial solu-tion to both these needs. This paper will present patternsas one tool for capturing implicit knowledge for use bysystems engineers to develop system architectures.There are a number of concepts and practices alreadyin the systems engineer’s toolbox today. These includedocumented processes such as CMMI® (CapabilityMaturity Model Integration® as defined by the SoftwareEngineering Institute), heuristics, templates, and frame-works to name a few. While these tools may appear tobe patterns in the broadest sense, they do not containthe richness of information found in modern day pat-terns. The remainder of this section will review somekey pattern concepts as well as terms that are sometimesconfused with what patterns have become, based on thecontinually maturing patterns community of other en-gineering disciplines.

For the context of this paper, that the authors havepreviously defined a systems architecture pattern as “ahigh-level structure, appropriate for the major compo-nents of a system. It expresses the relationship betweenthe context, a problem, and a solution, documentingattributes and usage guidance. Patterns are time-provenin solving problems similar in nature to the problemunder consideration” [Cloutier, 2006, p. 107, 2005c,2005b].

1.1. Heuristics

A heuristic is sometimes referred to as a rule-of-thumb.Rechtin and Maier state that heuristics are very general,spanning domains and categories of guidance [Rechtin,1991; Rechtin and Maier, 1997]. They go on to statethat heuristics are imprecise and give the least guidanceto the novice. Koen [2003, p. 28] defines a heuristic as“anything that provides a plausible aid or direction inthe solution of a problem but is in the final analysisunjustified, incapable of justification, and potentiallyfallible.” A couple of examples presented by Koenmay be helpful in understanding the concept of heuris-tics. “If we are unable to find a single example of aconcept, we should suspect it may not exist.” (p. 146)Yet another example is “A properly designed boltshould have at least one and one-half turns in the thread.(p. 167)

Heuristics represent the capture of implicit knowl-edge. For instance, one heuristic cited by Koen [2003,p. 35] is “at some point in the project, freeze the design.”Though this is good advice, it is very general in nature,nor is it expressed using Alexander’s basic form. Thatis not to say that it could not be put in the Alexandrianform—but that would be of little further value. More-

over, if the design is simple enough, or being workedby a single individual, there may be no need to freezethe design. Finally, it does not satisfy the definition ina number of ways, to include documenting attributesand usage guidance.

Rechtin and Maier [1997] described heuristics, pat-terns, styles and design methods as a progression, eachbecoming more prescriptive. Patterns were still gainingmomentum when Rechtin and Maier addressed them inthe context of systems architecting, and, though theycite the Alexandrian form (template), and state thatsince the form and definition of a pattern is quitegeneral, they state that pattern concepts can be appliedto other forms of architecture. They also believed thatpatterns are prescriptive heuristics, describing particu-lar choices of form and their relationship to particularproblems. Later in this paper, it will be shown thatarchitecting patterns can be used well beyond the do-main in which they were originally identified.

1.2. Templates

The relevant definition from the American HeritageDictionary defines a template as “[a] document or filehaving a preset format, used as a starting point for aparticular application so that the format does not haveto be recreated each time it is used.” Said another way,a template is a document that contains topic headings,but no content. In the pattern community, the patternform is the pattern template.

1.3. Processes

ISO 15288 defines a process as a set of interrelated orinteracting activities, which transform inputs into out-puts (referencing ISO 9000:2000). Most companieshave documented processes covering everything fromemployee relations to how to engineer a system. TheCMMI® provides a product suite developed specificallyfor those users who are system and product developersand want to improve their processes and products.Processes tend to be prescriptive in nature. Onceadopted, one must follow a prescribed set of steps tochange or tailor the process for use on a specific projector program. The desired changes or tailoring may alsorequire approval by a governing body.

1.4. Frameworks

A framework is a logical, organizing structure used toclassify information, concepts, data, etc. They may alsoprovide mechanisms to transform information from oneform to another. Gamma et al. [1995] defined a frame-work as a set of cooperating classes that make up areusable design for a specific class of software. A frame-

APPLYING THE CONCEPT OF PATTERNS TO SYSTEMS ARCHITECTURE 139

Systems Engineering DOI 10.1002/sys

work provides architectural guidance by partitioningthe design into abstract classes and defining their re-sponsibilities and collaborations. A developer custom-izes the framework to a particular application bysubclassing and composing instances of frameworkclasses. Another popular framework was proposed byZachman [1987]. It addresses the concept of informa-tion systems architecture in the form of a collection ofarchitecture views and perspectives, and the products,depicted in a matrix. The Department of Defense Archi-tecture Framework (DODAF) is a framework used bythe U.S. Military. It captures complex systems architec-ture in a number of artifacts, and organizes those arti-facts in three separate views—an operational view, asystems view and a technical view.

1.5. Pattern Languages

A pattern language is a collection of patterns that arecomplimentary to one another. In another reference,Alexander [1979] discussed a pattern language in termsof mathematics a set of elements (or symbols), and a setof rules for combining these symbols. Alexander [1977]also portrayed a pattern language as a network of largerpatterns, comprised of smaller patterns. An explanationoffered by Alexander [1979] for a pattern language isthe collection of patterns that would be useful for de-signing a garden. The collection of patterns chosen todesign a garden may include: Terraced Slope, TreePlaces, Greenhouse, Garden Seat, Building Edge, andSunny Place. By assembling these individual patternsfrom Alexander’s garden pattern language, any numberof beautiful gardens could be assembled, containingelements of trees, sun, sitting, a building, etc. If onethinks of patterns as the elements, and the combinationof patterns (or transitions from one pattern to another,representing interfaces, a pattern language emerges.This notion of a pattern language, constructed ofsmaller patterns will be revisited again in section 5.3.

2. PATTERNS—A HISTORICALPERSPECTIVE

Most people in the pattern community attribute Chris-topher Alexander [Alexander, 1977] as the first to for-malize and articulate the concept and value of patterns.Throughout the ’60s and ’70s, Alexander, a civil archi-tect, strove to improve on the art of urban design bycreating patterns that other architects could use. “Eachpattern is a three-part rule, which expresses a relationbetween a certain context, a problem, and a solution…”[Alexander, 1979, p. 247]. That is to say, in Alexander’sview, one must capture all three elements to documenta pattern. Alexander began to identify patterns for civilarchitecture, urban design, and community planning by

looking at an architectural design and then abstractingthat design into its basic parts that were common acrossother designs. Communities were viewed as systemsthat could be decomposed into component parts. Hedescribed the component parts and their relationship toother component parts in terms of boundaries. Alexan-der first published these notions in Notes on the Synthe-sis of Form [Alexander, 1964]. In this seminal work, hebegan what has resulted in several thousands of pagesof published works in which Alexander investigates theprocess of architecture development. Examples of reus-able patterns identified and tested by Alexander includepatterns such as (1) 6-foot balcony and (2) light on twosides of every room. The first pattern captures thedesign elements, in the form of context, problem, andsolution, to provide the minimum requirements for auseful balcony. Though the pattern seems self-explana-tory from the title, Alexander [1977: 782–784] spent 3pages documenting the pattern. Likewise, “light on twosides” captures the design approach that when architect-ing a room, one should provide architecture elementsthat allow natural light from two directions—be itwindows, skylights, or doorways. Alexander did notinvent these patterns, they came from observation andtesting; and only then were they documented as pat-terns.

2.1. Alexandrian Pattern Examples

To demonstrate the application of the pattern concept,Alexander outlined a collection of patterns to governthe architecture of a farmhouse [Alexander, 1977]. Thenames of those patterns are:

• North South Axis • Two Floors

• West Facing Entrance

• Hay Loft at the Back

• Bedrooms in Front • Pitched Roof

• Garden to the South

• Balcony Toward theGarden

• Half-Hipped End • Carved Ornaments

As one reads through the listed patterns, a visualpicture begins to develop in the mind’s eye, creating animage of the farmhouse and the site on which it will restfrom nothing more than a written or spoken list.

Other simple, yet powerful patterns documented byAlexander include “house for a couple” and “house fora small family” [Alexander, 1977]. The context for the“house for a couple” (Fig. 1) pattern was characterizedas follows: “In a small household shared by two, themost important problem which arises is the possibilitythat each may have too little opportunity for solitude orprivacy” [Alexander, 1977, p. 386]. The “house for asmall family” pattern (Fig. 2) context was: “In a house

140 CLOUTIER AND VERMA


for a small family, it is the relationship between childrenand adults which is most critical” (while these examplesdo not contain the entire patterns, as documented byAlexander, they do convey the essence of the patterns)[Alexander, 1977, p. 382].

In developing the concept of patterns and re-searching their applicability, Alexander was attemptingto lower the cognitive load of design by exploring largedesign spaces on behalf of the architect [Coplien, 1997;Alexander, 1964]. From his perspective, “patternshelped him to express design in terms of the relation-ships between the parts of a house and the rules totransform those relationships” [Coplien, 1997]. This isan important concept, and if one were to replace theword “house” with “system,” the same concept couldapply to the notion of system architecture patterns.

2.2. Patterns Are Not Created

It should be noted that patterns “are not created from ablank page; they are mined” [Hanmer and Kocan,2004]. Hanmer explains, when discussing design pat-terns, over time, similar designs are arrived at inde-pendently by different designers on various projects. As

it becomes apparent that the same design elements existin multiple designs, the design can be studied anddocumented to encourage reuse. This reuse prevents thereinvention of the same concept, and provides a vocabu-lary for the design concepts that a project can share[Sanz and Zalewski, 2003]. Consistent with the notionthat patterns are not created, but instead mined, the ruleof three was introduced by Ralph Johnson. He statedthat a pattern is not a pattern unless there are at leastthree independent, observable applications utilizing theproposed pattern as part of the solution (though this wasfully documented as a pattern, it may also be ap-proached as a heuristic). Appleton [2000] expanded onthis “rule of three,” stating that there are some in thesoftware patterns community that believe it is inappro-priate to identify a solution as a pattern until that pro-posed pattern is vetted, or scrutinized, by others. Thisscrutiny should give the user of the pattern some confi-dence in the completeness and appropriateness of thepattern, which may also reduce risk in a system employ-ing the applied pattern. Once a pattern is identified andbelieved to be of use in the future, it should be docu-mented using a pattern form.

2.3. Patterns Usage and Pattern Form

Based on the literature and usage of patterns in otherengineering disciplines, patterns are not meant to pro-duce “cookie cutter” architectures or designs. Insteadof using patterns exactly as documented, they are meantto be a starting point from which the final product willbe crafted. Alexander believed that in some settings,patterns might be reused tens of thousands of times, andnot have any two designs look exactly the same. “Wemay then gradually improve these patterns which weshare by testing them against experience…” [Alexan-der, 1979]. The benefit of this approach to patterns isthat they should not remain stagnant, but instead beimproved through continuous application.

The Alexandrian form of documenting patterns con-tained four topics to be addressed. They are: (1) name,(2) context, (3) problem, and (4) solution [Alexander,1977]. When using this form, the name of the patternshould be descriptive and should represent the solutionbeing proposed. Naming a pattern succinctly is criticalfor pattern reuse. If the pattern name is cryptic andwithout mnemonic value, it becomes meaningless tothose looking for a pattern to solve their particularproblem, significantly reducing the value of document-ing a pattern. The context addresses the setting for theproblem. This might include environment, the problemdomain, or any other aspect that will help understandwhere the pattern is being applied. The problem de-scribes the challenge or issue that the pattern will be

Figure 1. House for a couple.

Figure 2. House for a small family.



used to address. Finally, the solution is a description onthe application of the pattern—how it is used to solvethe problem, and how it may be modified or adapted toaccomplish the task.

The intent of this section was to provide a historicalcontext of where the modern notion of pattern use byengineering disciplines originated. Some of Alexan-der’s concepts are more than 30 years old. The disci-pline of systems engineering was just beginning toemerge then. Systems were much less complex then.Today’s modern automobile has more computingpower than the Gemini spacecraft of that era, and thepersonal computer had not yet been invented. Like otherengineering concepts, the concept of patterns has ma-tured and evolved with time. In reading Alexander’svoluminous body of work, his notion of patternschanged too [Alexander, 2002]. So it is with the appli-cation of patterns in other engineering disciplines. Al-exander’s early civil architecture pattern conceptsprovide a good reference foundation.

3. KNOWLEDGE AND PATTERNS

Today, there is already some carryover from the soft-ware patterns community into the systems architectingdiscipline. As an example of this, many systems engi-neers today understand what is meant by a client-serverbased architecture. The same is true for any number ofpatterns that have been abstracted to the systems level.The net effect of this discipline carryover is a commonlexicon between systems and software engineers toexchange knowledge.

3.1. Implicit Knowledge

Though one can attain advanced degrees in systemsengineering, there are many systems engineers todaythat do not have a formal systems engineering degree.Instead, they have acquired experience and knowledgeto be called a systems engineer by working on a numberof development projects, and by being able to thinkabout how parts of the system interact, both positivelyand negatively, with one another. Corporate systemsengineering departments attempt to capture knowledgeexplicitly through artifacts such as handbooks, lessonslearned repositories, engineering project notebooks,templates and tools, methods and practices, and metricsand measures. A significant component of this corpo-rate knowledge, however, is implicit and undocu-mented, and largely held by the technical leaders. Thisimplicit knowledge is useful to others only if it is sharedin a manner that allows its application. According toHole [2005], the holder of that implicit knowledge may

become a bottleneck in applying that systems experi-ence on current or future projects.

If a pattern exists only in the form of implicit knowl-edge, it is not accessible by others and cannot be usedby others without some form of repeated storytelling toconvey the pattern to others by the holder of this knowl-edge. The real power and value of a pattern is derivedonly if it can be packaged for use by others. If the patternis not documented (written down), it may increase thepossibility that the complete pattern will not be imple-mented the next time it is used—something may beforgotten or inadvertently left out. Formalizing patternsthrough documentation helps to ensure their usage byothers, their management as assets, and their applica-tion in an appropriate manner, and that they are im-proved over time.

3.2. Explicit Knowledge

Though patterns and heuristics are cited as serving toimprove communications between teams [Rechtin,1991; Rechtin and Maier, 1997], Hashler [2004] maybe the only documented, quantitative source in docu-menting improved communications between membersof the architecture and design teams resulting from theuse of patterns. He also found that they facilitated theapplication of sound architectural concepts and imple-mentations. The sound architectural concepts identifiedby Hashler were the software patterns documented byGamma et al. [1995]. As the discipline of systemsarchitecting assumes the challenge of developing in-creasingly complex systems, there is a need for a com-mon lexicon between systems architects. Describingarchitectures in the context of known and understoodpatterns should foster better and more consistent under-standing across the many stakeholder communities.Systems architecture patterns may also enable imple-mentation of common design features across systems(reuse) leading to enhanced R&D efficiency, and lowerownership costs through reduced efforts with regard tosystem testing, integration, and maintenance.

4. USE OF PATTERNS IN ENGINEERING

We have discussed the notion that patterns representimplicit knowledge, which if documented, can bereused by others with the intent of managing the cogni-tive load while architecting complex systems. In thissection, we will explore some examples of pattern usagein a number of engineering disciplines beyond softwareengineering. This section will briefly discuss someapplications of patterns across a number of engineeringdisciplines.



4.1. Software Engineering

Patterns were adopted by the software engineeringcommunity in the late ’80s when software designersbegan to apply Alexander’s architectural concepts (pat-terns) to object oriented software development. In 1995,Gamma et al. published what is considered to be anauthoritative work on software design patterns—De-sign Patterns: Elements of Reusable Object-OrientedSoftware [Gamma et al., 1995]. A recent search onAmazon.com for books on “software patterns” returned1883 choices. Software modeling tools such as IBM’sRational Software Architect includes a number of soft-ware patterns that can be applied, and the ability to addnew patterns. The software community may representthe broadest application of patterns in the communityof engineers today.

Software patterns are effective in transferringknowledge by describing solutions to similar problemsthrough common ways and techniques, regardless ofthe project problem domains or implementation toolsand languages. Using software patterns early in thedesign reduces the number of changes that have to bemade later in the lifecycle [Devedzic, 1999]. Devedzicalso considers some software patterns to be “micro-ar-chitectures” that contribute to the overall software sys-tem architecture. He makes that assertion based onsoftware patterns being used to weave parts of theoverall software system architecture into a whole.

4.2. Telecommunications

Bell Laboratories began mining their embedded sys-tems for patterns, and then documented those patterns.What they found was that there were commonalities infault tolerant and high availability systems. By identi-fying and documenting patterns that existed in theminds of their long-standing experts [implicit knowl-edge], they could document their core competencies[Coplien, 1997]. This is a strong argument for furtherexploration into the identification and use of architec-ture patterns—to enable the capture of good architec-tural concepts and implementations and to preservethem for future projects. In other words, patterns mayrepresent a knowledge capture methodology that pro-vides value to a business. Another value-added traitcited in support of patterns is that they provide a com-mon lexicon between architects. A common under-standing of the architecture is fostered by describingparts of the design and its implementations in the con-text of known and understood patterns.

4.3. Requirements Engineering

Large-scale system requirements difficulties have beenidentified as one of the three major factors that contrib-ute to poor systems integration [Kim, 1999]. Kim goeson to explain that requirements are often “inconsistent,incomplete and emphasize performance without regardto cost” [Kim, 1999]. Existing requirements engineer-ing methods, as applied to today’s complex systems,still pose the problem of missing, ambiguous, or mis-leading requirements [Kaffenberger, 2004]. Accordingto Kaffenberger, patterns offer a better way to specifysystem requirements. He identified two types of re-quirements patterns: (1) patterns that describe the con-stituent elements of a single requirement statement andtheir relations and (2) patterns that describe a set ofrequirements statements and their relations betweenthem. In his paper, Kaffenberger actually identified thefirst type of pattern as a requirements template, consis-tent with the definition presented in the introduction ofthis paper. The goal of his template was to improve thequality of the individual requirements statement.

The second type of requirements patterns were bro-ken into two subcategories—requirements process pat-terns and requirements data patterns. According toKaffenberger, by separating the system process essen-tials from the system products, patterns emerged in thehandling of the products. Patterns were then identifiedfor the processes and for the data structure of theinformation contained in the products. These patternswere reused in subsequent systems development pro-jects.

In 2002, there was a special interest working groupon requirements engineering of the German InformaticsSociety, four presentations representing four differentprojects from four different domains. However, all fourprograms were facing similar challenges:

• Stakeholders had to be convinced of the necessityand benefits of requirements engineering.

• Cultural differences of stakeholders had to beaccommodated.

• Requirements engineering methods and tools hadto be established.

• Skepticism regarding processes and transparencyhad to be overcome.

As a result of this working group, The RequirementsEngineering Pattern Repository (REPARE)1 was cre-ated in 2004. This online repository is a good model fora pattern repository.

1 See http://repare.desy.de.



4.4. Control Systems Engineering

Software now represents a significant portion of controlsystems. This has required the marriage of controlsystems engineers and software engineers to producethe necessary control system software. To facilitate thissituation, Sanz and Zalewski [2003] have proposedusing software “design patterns to document, transfer,and exploit [control system] design knowledge.” Theyare using software design patterns to capture both clas-sic control system designs and promising new designsand see the use of patterns as a new way to manage andexploit existing design knowledge. Further, they havefound that patterns enhance functional properties andespecially nonfunctional properties of control systemsdesigned using patterns. They presented a computerbased feedback control system pattern, and accordingto Sanz and Zalewski [2003], the pattern mindset is nota search for the Holy Grail, but rather, a “continuouseffort of thinking generic when designing, creatingdesigns—patterns—that will last because they demon-strate wide applicability.”

5. SYSTEMS ARCHITECTURE PATTERNS

The purpose of this research is to provide a frameworkand methodology to document and manage some as-pects of implicit knowledge in the form of systemarchitecture patterns and to understand whether thepositive benefits of enhanced productivity and effec-tiveness observed in other disciplines apply to systemsarchitecting. Based on precedence from other disci-plines (as well as parts of systems engineering), use ofpatterns in systems architecting may provide the foun-dation for a more common lexicon leading to improvedcommunications between the various stakeholders,while also enhancing the R&D efficiency on complexdevelopment programs. Other disciplines that haveadopted the use of patterns simply chose one of thepattern forms already in use by the software commu-nity, which originated from the Alexandrian form.However, systems architects may need different or ad-ditional information than that required by a softwareengineer to implement a pattern. For instance, the infra-structure of a system may include a mechanical systemthat has a rotating part that resonates at 60 Hz. Thatresonance may manifest itself in interference in anelectrical system through inductance. Additionally, itseems reasonable that the more abstract the concept, themore thorough the documentation must be to enablereuse to solve similar problems.

Rechtin [1991] discussed the concept that a series ofunprecedented systems establishes a precedent, and thatthe precedent establishes recognized patterns, some-

times called architectures. Each unprecedented systemhas an architecture, which represents the organizingstructure of that specific unprecedented system. Thedifference between architectures and patterns is thatwhile certain architectures are reusable, most architec-tures include details specific to the set of concerns forwhich the specific architecture was synthesized. A pat-tern abstracts (hides) specific details and concernsfound in any number of unprecedented systems, keep-ing the common, reusable characteristics that occuracross the unprecedented systems. These commoncharacteristics which provide the organizing structureof the common aspect of the architecture is documentedto address the generalized set of requirements in orderto foster reuse or application to an entirely differentproblem with similar concerns.

5.1. Potential Benefits of Patterns toSystems Architecting

Numerous benefits may result from the growing interestin architecture patterns. For instance, Haskins [2005]has proposed creating a patterns language from patternsthat may be found in the INCOSE Systems EngineersHandbook [2005]. One significant derived benefit ofpatterns, based on precedence in other disciplines,should be improved communications between variousstakeholders. Improved communications between teammembers of the architecture and design teams was ameasured and quantified result of using patterns whiledeveloping open source software [Hashler, 2004]. An-other benefit identified from the same study was thatpatterns facilitated application of sound architecturalconcepts and implementations. As the discipline ofarchitecting assumes the challenge of developing in-creasingly complex systems, there is a need for a com-mon lexicon between systems architects. Describingarchitectures in the context of known and understoodpatterns should foster better and more consistent under-standing across the many stakeholder communities.Systems architecture patterns may also enable imple-mentation of common design features across systems(reuse) leading to enhanced R&D efficiency, and lowerownership costs by reducing the effort required forsystem testing, integration, and maintenance.

According to Coplien [1997], in communities thathave adopted the use of patterns, the patterns oftenbecome standardized through multiple implementa-tions, presentations at research and professional confer-ences, and publication in research journals. Thisstandardization fosters reuse of designs and even codethat might be generated from the architecture patterns.Such reuse can improve development efficiency andproductivity [Coplien, 1997]. Based on Coplien’s



study, one could argue that documenting current pat-terns may reduce the cost of creating and documentingarchitectures, for any organization that elects to pursuesystems engineering patterns. It may also follow thatarchitectural patterns may help control the complexityof architectures by standardizing on accepted and prac-ticed patterns.

Who would benefit from systems architecting pat-terns? Systems architecture is typically conducted byexperienced systems engineers. Over the course of theircareers, they have accumulated the knowledge that iscarried forward from design to design. Recognizingpatterns as they emerge over time requires the same typeof experience. The same holds true in documentingpatterns—it takes an experienced systems architect toknow what can be abstracted, and how to abstract thatinformation in a meaningful way so that it can bereused. Once documented, as the software communityfound, patterns provide a common communication me-dium between engineers and architects. However, thereis another consumer of systems architecting patterns,which could yield higher return. If a bright systemsengineer with some experience under the belt aspires tobecome a systems architect, patterns may be of use intheir further education. A systems architect, mentoringthe aspiring architect would be able to leverage theexperience captured in the pattern, or pattern language,

as a learning tool for the architect being mentored,providing a launching pad for the next architecture.

5.2. Application of the Pattern Concepts toSystems Architectures—A Survey

Since a literature search on the use of patterns in theengineering disciplines indicates that there may be po-tential benefits supporting the use of patterns at thesystem architecture and design level, one must then askthe next question: “Does the systems architect need a

Table I. Summary Data—Necessary PatternDocumentation Sections

Table II. Recommended Systems Pattern Form



different solution for documenting patterns than thatused by other engineers?” This topic was discussedduring a colloquium conducted at Stevens Institute ofTechnology [Cloutier, 2005a]. Two issues with regardto patterns for systems architectures were highlightedat this colloquium. The first issue is abstraction. Thearchitecture of a system (an enterprise system or acomplex system) requires a higher level of abstractionthan necessary for the software that may be a part of thesystem. Additionally, many systems include a combi-nation of hardware, software, and other resources thatmay result in pattern uniqueness. This abstraction maymake it more difficult to use a simple approach todocumenting patterns. The second issue that arose isrelated to the first—patterns need to address interfacesto software and nonsoftware parts (if they exist) in the

pattern description. This notion of interfaces has notbeen explicitly addressed in past software pattern dis-cussions.

Survey data demonstrate that systems engineers andarchitects are most interested in the rationale for thepattern followed by an example of how to apply thepattern, and known uses of the pattern [Cloutier andVerma, 2006; Cloutier, 2006]. Summary data derivedfrom the survey are presented in Table I. Based on theanalysis of those data, the sections considered impor-tant in the documentation of architecture patterns arelisted in Table II.

The Example heading is meant to provide a diagramor model of the pattern. The diagrammatic repre-sentation of patterns has matured over time. It is easyto imagine this is due to the increasing complexity and

Table III. Perform C2 Pattern (Page 1 of 3)



abstract nature of the information contained in a sys-tems architecture pattern. Alexander’s diagrams weresimply hand drawn sketches as seen in the patternsrepresented in Figures 1 and 2 (House for a Couple andHouse for a Small Family). They represent simple con-cepts, which did not require complicated diagrams.Gamma et al. [1995] expanded the sketch to classdiagrams and interaction diagrams. This conventionwas carried forward by Buschmann et al. [1996], whoused a combination of text, tables, class diagrams, andsequence diagrams to represent patterns such as theBlackboard pattern. As patterns are used to representhigher levels of complexity and abstraction, the“sketch” approach utilized by Alexander may becomeinadequate. For instance, the concept of command andcontrol is considerably more complex and abstract thanthe notion of a gated garden. A simple sketch may besufficient to convey the underlying architecture of a

gated garden, while architecture of the underlying con-cepts of command and control may indeed require amore complex notation—e.g., IDEF or UML. Finally,patterns are methodology agnostic, so if the pattern isbest represented using an SA diagram, or an OO dia-gram, use what best captures the pattern.

5.3. Example: The C2 Pattern

In this section, the Perform C2 pattern [Cloutier andVerma, 2006] will be discussed. The pattern documentsthe concept of operations for command and control(C2) using the Plan, Detect, Control, and Act paradigm.Though this pattern is normally associated with militarysystems, it has broader applications to other domainsthat involve emergency response. It could also be ap-plied to a command and control system for transporta-tion systems like the railroad or a trucking fleet with

Figure 3. Perform C2 pattern (page 2 of 3).



little change. The Perform C2 pattern is documented inthe following example (Table III and Figs. 3 and 4).

5.3.1. Alternate C2 Pattern DiagramsDifferent graphical notations are usually associatedwith the engineering methodology that has been cho-sen. The most common methodologies are functionaldecomposition, represented with diagrams such asIDEF0, Functional Flow Block Diagrams, N2, etc.[Buede, 2005; Sage and Palmer, 1990]. When using anobject-oriented approach like the Object Oriented Sys-tems Engineering Methodology (OOSEM) [Frieden-thal and Meilich, 2003], then the notation is more likelyto be the Unified Modeling Language (UML). Basedon the graphical notation, the diagrams presented in theC2 pattern may look like those shown in Figures 5 and6. (In Fig. 6, it should be noted that the I/O can be

represented more explicitly on the activity diagrams viaobject nodes/pins. Figure 6 shows the I/O simply as anannotation.)

5.4. The Perform C2 Pattern Language

As discussed in the Introduction, a pattern language isa network of patterns that are complementary, and maywork together to form a larger pattern. The C2 pattern,as a whole, relies on the collection of smaller patterns—Plan, Detect, Control, and Act. Therefore, one mightrefer to the C2 pattern as a pattern language. Each ofthese four patterns could be used independently toarchitect the Concept of Operations (CONOPS) of an-other system. For instance, the Plan pattern shown inFigure 7 could be used by a marketing organizationdeveloping a new software application to manage newproduct launches.

Figure 4. Perform C2 pattern (page 3 of 3).



Figure 5. Perform C2 pattern (alternate page 2 of 3).

Figure 6. Perform C2 pattern (alternate page 3 of 3).



5.5. Additional Thoughts on the C2 Pattern

There are a number of items that can be summarizedfrom the documentation of the C2 pattern. First, thePlan/Detect/Control/Engage workflow for commandand control (C2) can be documented as a pattern forreuse. Sufficient detail can be captured in the pattern toenable an architect less familiar with the process tobegin architecting a solution to a new instance of the C2problem. However, as one “drills down” in document-ing a complex pattern, a level of detail is reachedwhereupon the necessary detail begins to obfuscate thevalue of pattern abstraction. This is the point in whichno further data should be added to the pattern

Anecdotal evidence from SME interviews that haveapplied this pattern in the past indicate that this type ofpattern is extremely helpful in guiding stakeholder in-terviews, acting as a reminder to the systems engineerof questions that must be addressed. One of the creatorsof this pattern noted that last time the pattern wasapplied to a project; he arrived at the same design pointof the previous implementation months earlier.

6. APPLYING AND MANAGING SYSTEMSARCHITECTING PATTERNS

This section will address the actual application of pat-terns to systems architecting. A brief discussion onpossible strategies for managing patterns is also in-cluded.

6.1. Applying Patterns in SystemsArchitecting

To demonstrate how a systems architect would use thePerform C2 pattern while architecting a system, a sce-nario will be used. The discussion will be generalizedfor simplicity, but the concepts will apply to mostscenarios. The example should not be considered as afull treatment of what a systems architect would do toarchitect the system.

Consider the situation where a mid-sized town hasembarked on an effort to upgrade the emergency re-sponse capability. They have decided to design an emer-gency response center (ERC). All communicationsassociated with an emergency will flow in and out ofthe ERC. During an emergency, the town Mayor, Chiefof Police, Fire Chief, and Emergency Response Direc-tor will report to the ERC. From the ERC, the team willbe able to plan the response, monitor, and direct actionsof the emergency response personnel. The system alsohas the requirement to integrate the police, fire, andEMT efforts, as well as assistance coming from neigh-boring towns, or even other government agencies. Anengineering firm has been contracted to architect thissystem.

Upon interviewing the city officials and subject mat-ter experts (SMEs), the systems architect believes thePerform C2 pattern in the firm’s pattern repository is agood starting point to model the concept of operations(CONOPS). Looking at the context diagram on page 1of the pattern, many of the same terms are found in the

Figure 7. Part of a pattern language—a plan system pattern.



keywords section, and the problem description seemsto be similar. However, many terms were never men-tioned in the interviews—terms like track, sensor avail-ability, etc.—not an exact fit, but a possible start. Theconsultant decides to use the pattern to help develop theCONOPS.

Customizations when implementing any pattern arenormal, and in fact, expected. Patterns are not meant tobe an exact fit. In the C2 pattern the term “Tracks/Tar-gets of Interest” may represent assets—fire trucks,squad cars, and EMT units—all of which need to betracked during an emergency response. Knowing thewhereabouts of these assets allows the command centerto redeploy as necessary, or when the situation changes.Sensor availability may be a citizen calling in a reportbefore an official response team gets there. Sensor datacould also be a latitude and longitude from a GPSreceiver from a citizen to help exactly pinpoint a loca-tion if it is for a more rural location. Reports are criticalitems on this pattern. Looking at page 2 of the pattern,a number of items are still necessary without change:external data and environmental data are still necessary,as is a strategy, external guidance (county or state laws)and doctrine (standard responses already documented),and resources. The outputs need a bit of adjustment,however—BDA (battle damage assessment) may notbe applicable, so the output is changed to be situationassessment. Mission assessment sounds like a duplicateto situation assessment, so it might be a candidate fordeletion. Coordination data are still necessary. Orders,plans, reports, resource assignments, situational data,tasking, and request for information are all necessary.Other items may be renamed or deleted as applicable.

Once the context diagram (A-0) is correct, the dia-gram on page 3 of the pattern can be incorporated intothe design by updating the terminology to be consistentwith the context diagram, removing the items that weredeleted, and adding new items that may not exist on thepattern. At this point, the pattern has been applied. Theconsultant has the beginnings of a functional architec-ture (A0 diagram) for the city’s ERC.

6.2. Managing Systems ArchitecturePatterns

One question that is asked frequently regarding patternsduring the course of this research is the concern forbeing able to locate or select the correct pattern for theproblem being addressed. Engineering patterns shouldnot be thought of as a silver bullet. Although the patternprovides a basic structure of the solution to a particularproblem, it does not provide a solution that can be used“as-is” [Buschmann et al., 1996]. Sound engineering isstill required. The same is true when it comes to select-

ing a pattern—sound engineering judgment is requiredto make the correct pattern choice—or choose not touse a pattern in a particular case. However, like manag-ing reusable software, there are things that must be doneto foster reuse of patterns.

A review of the literature on software reuse librariessuggests the following lessons learned, equally applica-ble to managing and using system architecture patterns:

A. Build a “critical mass” of reusable componentsquickly. Then advertise the availability of therepository. If engineers go there to find some-thing before a decent number of patterns areavailable, they will quit using this source.

B. Identify reusable components that should bedocumented for early inclusion in the library.

C. Reusable components should be easy to use, notpromise too much, and be very reliable.

D. Provide a Reuse Tool from the start.E. Assign a Reuse Librarian from the start.

The methodology described here provides the meansto capture the content of the “critical mass” for a patternreuse repository. It details an approach for documentingpatterns, based on input from a body of experiencedsystems architects and systems engineers. The big chal-lenge is for systems architects and engineers to recog-nize the value of patterns, to begin identifying patterns,and then to document them using this methodology.There is an opportunity for systems engineering aca-demic institutions, and/or INCOSE—to collaborate ona systems engineering and architecting patterns reposi-tory similar to the REPARE repository discussed earlierin this paper.

7. DIRECTIONS FOR FUTURE RESEARCH

The use of patterns in systems architecting intersectswith a number of other key emerging technologies. Afew of these technologies include the Object Manage-ment Group (OMG) model driven architecture (MDA)approach, product line management (PLM).

The advent of SysML should encourage the adop-tion of modeling the system architecture using formalmodeling tools that support the SysML standard. Thesemodels may then be “executed” to begin early verifica-tion and validation. Part of the MDA approach includesdeveloping a computational independent model (CIM)and platform independent model (PIM). These notionsare described today in terms of software and softwarearchitecture. If they are described in terms of systemsarchitecture, what use might systems architecture pat-terns serve in describing the CIM or PIM? Another



emerging concept in systems architecting is the appli-cation of product line management. How can one man-age the product line of very complex systemarchitecture on the magnitude of a military fighter orwarship? In commercial terms, how might one applyproduct line management concepts to the global posi-tioning system? Moreover, do patterns help in thisarchitecture development and management? Intui-tively, it seems there is a point of intersection with thesetechnologies, and the author intends to continue re-search in these directions.

8. CONCLUSIONS

The research in this paper represents a methodology toaddress the specific needs of systems architects andsystems engineers with regard to documenting andapplying patterns. Looking at the pattern form docu-mented in this paper, one could conclude that simplyadopting a complete software pattern form may havebeen sufficient. However, that approach would havemissed the importance of capturing information specifi-cally related to interfaces. This may seem self-evidentto experienced systems engineers. However, this paperpresents research, based on a broad base of internationalexperience, to confirm that observation.

The Perform C2 pattern demonstrates sufficient de-tail can be captured and documented to enable the reuseof the pattern in future projects. It does not provide allthe answers, but it can provide a significant jump-startto architects and engineers that may not be as familiarwith the domain captured in the pattern. This method-ology enables the expert knowledge and advice of ex-perienced systems engineers to be transferred to lessexperienced architects and systems engineers.

The documentation and application of patternspromises the potential to improve the efficiency andproductivity of virtually all engineering disciplines us-ing patterns. There is little evidence beyond anecdotalevidence that bears out this potential; however, there issufficient evidence throughout engineering disciplinesto suggest that systems engineering may benefit byusing patterns. As an extension to this, the ability todocument patterns in such a way that they can beapplied at the system architecture/systems engineeringlevel may also reduce the documentation costs andcomplexity. The major difference in documenting apattern for use in systems architecture or design is theaddition of interfaces within the pattern. What was notaddressed is the parameterization of pattern parts—isthere a way to parameterize the parts of an architecturepattern to help at the interfaces? Each of these unan-

swered questions provides future research opportuni-ties.

Patterns offer the potential to manage and control thecomplexity of a system by standardizing designs onwell-known and practiced patterns, where appropriatethrough the creation of a common lexicon to be used bysystems engineers. Evidence that this lexicon is a realityis the understanding that today’s systems engineershave with a layers architecture, or a client server archi-tecture. Both were first documented in the mid 1990sas software patterns. While this paper represents earlyinto the application of patterns to systems architecture,there are many aspects that need further investigation.One such topic to be explored next year is the applica-bility of systems patterns to deeper, conceptual ele-ments of systems architecture. Alexander’s [2003] mostrecent work, representing decades of pattern applica-tion to civil architecture, indicates that he still continuesto struggle with what can and cannot be conveyed withpatterns, and believes there is much to discover.

Finally, if patterns are to be useful to the systemsengineering community, there will have to be an openrepository for pattern submission and reuse. This re-pository would become a vehicle to build a maturingsource of patterns that can be leveraged for similarrealized benefits already gained in other engineeringdisciplines. Patterns are not cookie cutters. In somesettings, patterns may be reused, and not have any twodesigns which are identical. Patterns should not remainstagnant. They should be improved upon. “We may thengradually improve these patterns which we share, bytesting them against experience…” [Alexander, 1979].Patterns and pattern languages are not created from ablank page; they are mined [Hanmer and Kocan, 2004].Sanz and Zalewski [2003] summarized the use of pat-terns by stating: “The pattern concept is not easy tounderstand, however, the best way for the reader to fullygrasp its potential is to practice it. Select a patternschema adequate for your field of work and try usingpatterns to document the simple design elements thatproved useful in the past and that you are typicallyemploying in your systems.”

ACKNOWLEDGMENTS

The authors acknowledge support from the LockheedMartin Corporation, and specifically Sandy Fried-nethal, Jeff Carter, and Kathy Tennar. Osmo Vikman,Sari Leppänen, Pasi Rinne-Rahkola, Markku Turunen,and Jukka Honkola from Nokia Technology Platformsand Nokia Research Center contributed significantly tothis research. Finally, the support provided by Vitech



Corporation and Telelogic for the use of their modelingtools is appreciated.

REFERENCES

C. Alexander, Notes on the synthesis of form, Harvard Uni-versity Press, Cambridge, MA, 1964.

C. Alexander, A pattern language, Oxford University Press,New York, 1977.

C. Alexander, A timeless way of building, Oxford UniversityPress, New York, 1979.

C. Alexander, The order of nature: An essay on the art ofbuilding and the nature of the universe, Book 1 Thephenomenon of life, The Center for Environmental Struc-ture, Berkley, CA, 2002.

B. Appleton, Patterns and software: Essential concepts andterminology, 2000, http://www.cmcrossroads.com/bradapp/docs/patterns-intro.html, accessed June 22, 2005.

D. Buede, The engineering design of systems, models andmethods, Wiley, New York, 2005.

F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, andM. Stal, Pattern-oriented software architecture: A systemof patterns, Wiley, West Sussex, UK, 1996.

R. Cloutier, Survey on the use of patterns in systems engineer-ing and architecting research, Colloquium Proc 2005 ConfSyst Eng Res, March 2005a.

R. Cloutier, Towards the Application of Patterns to SystemsEngineering, Proceedings of the 2005 Conference on Sys-tems Engineering Research, March 2005b.

R. Cloutier, Application of patterns to systems architecting,2005 Telelogic Americas User Group Conf, October2005c.

R. Cloutier, Applicability of patterns to architecting complexsystems, Doctoral Dissertation, Stevens Institute of Tech-nology, Hoboken, NJ, 2006.

R. Cloutier and D. Verma, Applying pattern concepts toenterprise architecture, J Enterprise Architecture 2(2)(May 2006), 34–50.

J. Coplien, Idioms and patterns as architectural literature,IEEE Software (Special Issue on Objects, Patterns, andArchitectures) (January 1997).

V. Devedzic, Ontologies: Borrowing from software patterns,Intelligence 10(3) (1999), 14–24, http://doi.acm.org/10.1145/318964.318968.

S. Friedenthal and A. Meilich, Object Oriented Systems En-gineering Method (OOSEM) Tutorial, 13th Annu IntSymp, INCOSE 2003, Washington, DC, July 1–3, 2003.

E. Gamma, R. Helm, J. Johnson, and J. Vlissides, Designpatterns: Elements of reusable object oriented software,Addison-Wesley, Reading, MA, 1995.

M. Hashler, Free/open source software development, K. Ste-fan (Editor), Idea Group Publishing, 2004, pp. 103–124.

R. Hanmer and K. Kocan, Documenting architectures withpatterns, Bell Labs Tech J 9(1) (2004), 143–163.

C. Haskins, Application of patterns and pattern languages tosystems engineering, Proc INCOSE 15th Annu Int Symp,Rochester, NY, July 10–13, 2005.

E. Hole, Architectures as a framework for effective and effi-cient product development in a dynamic business environ-ment, Proc 2005 Conf Eng Res, March 2005.

INCOSE Systems Engineering Handbook, Version 2a, Inter-national Council on Systems Engineering, 2005.

R. Kaffenberger, The difference—on the use of pattern-basedrequirements, 14th Annu Int Symp Proc, INCOSE 2004.

Y. Kim, Framework for systems integration complexity meas-ures: Achieving better architectures of large scale and verycomplex systems, Doctoral Dissertation, School of Engi-neering and Applied Science, The George WashingtonUniversity, Washington, DC, 1999.

B. Koen, Discussion of the method, Oxford University Press,New York, 2003.

E. Rechtin, Systems architecting: Creating and building com-plex systems, Prentice Hall PTR, Upper Saddle River, NJ,1991.

E. Rechtin and M. Maier, The art of systems architecting,CRC Press, New York, 1997.

A. Sage and J. Palmer, Software systems engineering, Wiley,New York, 1990.

R. Sanz and J. Zalewski, Pattern-based control systems engi-neering, IEEE Control Systems Mag (June 2003), p. 43–60.

J. Zachman, A framework for information systems architec-ture, IBM Syst J 26(3) (1987), 276–290.

Robert Cloutier (Rob) received his Ph.D. in Systems Engineering from Stevens Institute of Technology.He has over 20 years experience in systems engineering, software engineering, and project managementin both commercial and defense industries. He is a Research Associate Professor at Stevens, where hisresearch interests include Systems Engineering Patterns and modeling complex systems withUML/SysML, Reference Architectures, and agent based technology applied to systems engineering. Robalso has an M.B.A. from Eastern College, and a B.S. from the United States Naval Academy. He is anAdjunct Professor for Eastern University and chairs the Rowan University Electrical and ComputerEngineering Department Industry Advisory Board. Rob belongs to the International Council on SystemsEngineering (INCOSE), and is a member of the Technical Leadership Team. He is also an active memberof the Association of Enterprise Architects, and is a member of IEEE.



Dinesh Verma received his Ph.D. and the M.S. in Industrial and Systems Engineering from Virginia Tech.He is currently serving as the Associate Dean for Outreach and Executive Education and Professor inSystems Engineering at Stevens Institute of Technology. He concurrently serves as the Scientific Advisorto the Director of the Embedded Systems Institute in Eindhoven, The Netherlands. Prior to this role, heserved as Technical Director at Lockheed Martin Undersea Systems, in Manassas, VA, in the area ofadapted systems and supportability engineering processes, methods, and tools for complex systemdevelopment and integration. Before joining Lockheed Martin, Verma worked as a Research Scientist atVirginia Tech and managed the University’s Systems Engineering Design Laboratory. While at VirginiaTech and afterwards, Verma continues to serve numerous companies in a consulting capacity, includingEastman Kodak, Lockheed Martin Corporation, L3 Communications, United Defense, Raytheon, IBMCorporation, Sun Microsystems, SAIC, VOLVO Car Corporation (Sweden), NOKIA (Finland), RAMSE(Finland), TU Delft (Holland), Johnson Controls, Ericsson-SAAB Avionics (Sweden), and Motorola. Heserved as an Invited Lecturer from 1995 through 2000 at the University of Exeter, United Kingdom. Hisprofessional and research activities emphasize systems engineering and design with a focus on conceptualdesign evaluation, preliminary design and system architecture, design decision-making, life cycle costing,and supportability engineering. In addition to his publications, Verma has received one patent and has twopending in the areas of life-cycle costing and fuzzy logic techniques for evaluating design concepts. Dr.Verma has authored over 85 technical papers, book reviews, technical monographs, and co-authored twotextbooks: Maintainability: A Key to Effective Serviceability and Maintenance Management (Wiley,1995), and Economic Decision Analysis (Prentice Hall, 1998). He is a Fellow of the International Councilon Systems Engineering (INCOSE), a senior member of SOLE, and was elected to Sigma Xi, the honoraryresearch society of America.



Applying the concept of patterns to systems … the Concept of Patterns to Systems ... While much has been written about patterns in software ... APPLYING THE CONCEPT OF PATTERNS TO

Documents