Incorporating changes in our individual lifestyle isdifficult, whether it be learning new skills or changingour habits. Incorporating meaningful change in largeenterprises with several individuals is exponentiallymore difficult. It isn’t a single solution applied by a sin-gle individual that changes a large and complex enter-prise, but several solutions applied simultaneously andcoherently by several individuals.

Given that products unify an enterprise — in that indi-viduals collectively design, produce, sell, support, oper-ate, and decommission them — we offer in this article aset of solutions to transform enterprises on the basis ofproducts. Pattern languages, which were originally con-ceived by Christopher Alexander as a means of describ-ing effective design practices within architecture, can beused to represent the knowledge required for productlifecycle management across a large enterprise. We dothis by understanding the prevalent forces in the enter-prise and finding positive solutions or patterns that areable to balance these forces. In this article, we providea pattern language for product lifecycle managementprimarily based on emergent, good, and best practiceswithin large telecom operators.

MANAGING LIFECYCLE PROCESSES IN A RAPIDLY CHANGING, INCREASINGLYCOMPLEX TELECOM LANDSCAPE

Telecom operators are confronting business challengesthat require deep changes within their people, systems,and organizations. With device manufacturers such asApple, Google, and Samsung increasingly providingtheir own communications services, telecom operatorsare facing declining revenues from their staple offeringsof voice, data, and messaging. The emergence of high-speed mobile Internet coupled with devices that offerusers greater possibilities in service selection and con-sumption requires telecom operators to build on theirexisting strengths while capitalizing on new opportuni-ties. Products focused around voice, data, and messag-ing need to be transformed and merged with new

services that revolve around the connected work andlife of users.

The omnipresence of Internet Protocol (IP)–based net-works makes it easier to create high volumes of diversemultidevice products, which will increase the complex-ity in the conception, implementation, operation, andretirement of products. Current inefficiencies will befurther amplified given the product volume and diver-sity, and new practices will need to emerge in order tomanage this unprecedented scale of complexity. Each ofthese new practices will have to be applied with otherpractices, creating an interconnected network of prac-tices. These practices can help telecom operators effec-tively transform from value chains to value networks.1

Telecom operators have traditionally tried to manageproduct lifecycle processes through individual andindependent projects, using waterfall or agile manage-ment methods. Products realized in environments thatuse a waterfall methodology have distinct phases forproduct innovation, product feasibility assessment,product implementation, product operation, and prod-uct retirement. Matrix organizations are often con-structed to complement these distinct phases, andparticular responsibilities are assigned to each phase.Distinct organizational units within the matrix organi-zation have clearly defined roles and responsibilities,each producing a specific aspect of the final product. Asingle department that translates all business needs intodesigns (or a single group that manages all the data inthe enterprise) is an example of these distinct organiza-tional units. Such structures are useful for producingproducts that have similar characteristics.

Historically, most commercial product offerings havehad similar structures, making it possible to create rela-tively repeatable processes for their lifecycles. The focusof such organizational structures tends to be aroundproduct delivery rather than product retirement. Theseprocesses are analogous to the classic Ford Model Tassembly line, in which each person in the assemblyline had a defined role, received fixed inputs, and

©2012 Indranil Bhattacharya and Michael Hartges. All rights reserved.CUTTER IT JOURNAL December 201212

A Product Lifecycle Management Pattern Language forTelecom Operatorsby Indranil Bhattacharya and Michael Hartges

CALMING TELECOM COMPLEXITY

13Get The Cutter Edge free: www.cutter.com Vol. 25, No. 12 CUTTER IT JOURNAL

produced fixed outputs to achieve consistency. Figure 1illustrates the treatment of product lifecycle processes ina waterfall method.

Products realized in agile environments follow morefluid and flexible phases, where each phase has a ten-dency to overlap with other phases. There is recognitionthat features that seem very important for a productat an early stage might seem less important at a subse-quent stage. Through understanding the complexity oftasks to realize a product, development can be priori-tized by tackling the most complex aspects of a productfirst. Documentation and service-level agreements arekept down to a minimum and replaced by incorporat-ing suppliers and partners as extended members ofthe production system. Processes themselves are con-stantly being adapted in the face of changing situationsby practitioners who continuously apply improvementsin their methods of working, following principles like“5 whys is 1 how.”2 However, agile work environmentsare difficult to achieve in highly distributed teamswithin complex organizations. The inspiration for agilemethodologies can be traced to the Toyota ProductionSystem as realized in the late 1970s, which introducedthe Kaizen philosophy of production. Figure 2 illus-trates the treatment of product lifecycle processes usingagile methods.

Both waterfall and agile methods provide practices forstructuring organizations for efficient product lifecyclemanagement. There are other practices that can beapplied to managing people, technological choices,organizational structures, organizational culture, andphysical workspaces. These practices can be selectivelyapplied in different combinations based on differentsituations and organizational cultures. The practicesthemselves can be classified based on their maturity.Best practices are typically established in situationswhere the correlation between cause and effect isobvious to all. Good practices require some analysisto establish a stable relationship between cause andeffect. Finally, emergent practices typically come aboutwhen retrospective analysis is done on the correlationbetween cause and effect.3

In this article, we use a pattern language4 to describesuch practices, indicating best practices with three starsand good practices with two stars. (If we had featuredany emerging practices, we would have assigned theseone star.) We first give a synopsis of the scale of com-plexity telecom operators confront today in each phaseof a product’s lifecycle. Next, we provide two examplesfrom our pattern language, outlining the problem thepattern solves, the pattern’s solution, and the linkage ofthis individual pattern with all other patterns. By usinga pattern language, these practices can be woven inmyriad ways for different products within the sameorganization, and the unique challenges a particulartelecom operator faces can be resolved using a uniqueimplementation of these patterns.

DERIVING OUR PATTERN LANGUAGE

The primary goal of developing a product lifecyclemanagement pattern language for telecom operatorsis to provide a flexible method for better dealing withthe scale of complexity they confront in using new prac-tices. The adoption of these new practices can requirenew organizational structures, changes in employeeroles, the creation of new employee roles, and thegradual removal of existing practices. All these

Product Operation

ProductInception

ProductFeasibility

ProductDevelopment

ProductImplementation

ProductRetirement

Figure 1 — Phases in the lifecycle of a product within a waterfall methodology.

Product Operation

ProduductctduduFeasFeasFFF asibilityasas

ProductPPPtDevelopmentDDD

uctProductuctuctPPPtttirementtttititiRetR tR tR tttttttttProduct

Impmplementationnnnnn

ProduductIncepeptionoonon

Figure 2 — Phases in the lifecycle of a product within an agile methodology.

©2012 Indranil Bhattacharya and Michael Hartges. All rights reserved.CUTTER IT JOURNAL December 201214

requirements for the adoption of new practices can bevery difficult to achieve if the benefits of the change arenot clear at every level of an organization. Patterns ofchange must be able to incorporate existing practicesby absorbing their strengths and minimizing theirweaknesses. Each pattern must be able to articulate theexisting problems based on real situations individualsencounter, the solution for these problems, and the link-ages of the pattern with other patterns.

In order to derive this pattern language, we applied the“embodied making” method.5 Embodied making is anaction research6 approach that requires participation,engagement, and reflection. In action research, thedesigner works with rather than for people, is engagedas an equal in terms of understanding the design envi-ronment, and takes a reflective stance with regard tothe work being done.

The process of design with embodied making is intiti-ated by having conversations with people in the spacewhere we want our designs to live. It starts by captur-ing stories, which are anecdotes as people relate them tous, and then faithfully recording them. We conductedaround 120 interview sessions with people performingdifferent roles in these organizations, ranging from cus-tomer service agents to product developers. All theseindividuals were involved in some capacity in the real-ization, operation, or retirement of products. From theseinterviews, we were then able to derive the prevalentforces from the processes of product lifecycle manage-ment. For instance, the following are some of the forcesevident during the inception of a product:

� Reluctance to discuss immature ideas

� Fear that ideas will be underappreciated

� Concern that competitors may copy ideas

� Desire to obtain idea feedback from experts

� Inability to identify experts

� Tendency of experts to prefer giving direct andpersonal feedback

� Tendency to forget about ideas after a while

� Skepticism of unconventional or disruptive ideas

� Tendency of commercially successful products toget more attention (with the result that disruptiveor innovative products stand a very low chance ofadoption)

We were able to identify around 500 individual forcesin the course of a product’s lifecycle. These forces didnot manifest themselves in isolation but rather in com-bination with many of the other forces. For instance,

one reason for the reluctance to discuss immature ideasis the fear that the ideas will be underappreciated.A solution for resolving these forces would be to createan environment where anyone can submit an ideaanonymously. However, this solution conflicts withother forces, such as the desire to get credit for goodideas and the fear that others will get credit for ideasthat are not their own.

Another solution that resolves these forces is to createa forum where individuals can choose to submit theirideas either openly or anonymously, with the optionto reveal their identity at a later stage. However,anonymity doesn’t allow individuals to receive directand personal feedback from experts, and it doesn’tresolve another force — the tendency for a single indi-vidual to have limited insight about all aspects of aproduct. A solution that does resolve these additionalforces is to require that for any idea to be adopted, itmust be championed by three individuals who collec-tively consider its commercial, operational, and techno-logical aspects. This continuous process of assessingsolutions eventually provides a set of stable solutionsthat work well together, and each of these solutionsis then restructured into a pattern. Wherever possible,the patterns are named after a common theme, suchas a garden or town. As new patterns emerge, existingpatterns are reassessed and redesigned to reflect theirindividual and collective interaction with other pat-terns. Together the patterns provide an interwovenpattern language.

SOME PATTERN EXAMPLES

Our pattern language as it has been developed thus farconsists of 33 individual patterns.7 These patterns havebeen formed by the merger of previous patterns, theemergence of new patterns, and the removal of redun-dant patterns. This continuous process means we expectother patterns to emerge as the scale of complexityincreases. We have developed these patterns in thestyle advocated by Alexander and his colleagues,8

which starts with a statement on the nature of the prob-lem as a summary of the forces that need to be resolved,how we propose to resolve them, and the manner inwhich this individual pattern is linked to all other pat-terns. The following pattern, Deep Roots, provides anexample of a pattern that is a best practice.

Deep Roots ���

Stable products that have grown over time tend to have alot of implementation complexity, which can span severalapplications. Each application can have complex business

15Get The Cutter Edge free: www.cutter.com Vol. 25, No. 12 CUTTER IT JOURNAL

rules, which in turn have complex integration with otherapplications. Due to the lack of automated testing, consider-able manual testing effort has been expended to make theseproducts stable. Manual processes and workarounds oftenexist to counter the products’ computational limitations, andthis knowledge tends to be well-documented to ensure stableproduct operation.

Therefore, when new systems are designed to replacelegacy systems, it is important to understand theseDeep Roots before trying to migrate stable products.If it is not possible to understand them, let these DeepRoots lie, and use each additional insight about themto remove them cautiously. Use initiatives for realizingnew systems to realize new products. If stable productsmust be migrated, use the opportunity to evolve theminto contemporary circumstances. Reduce historicalcomplexity by reevaluating the rationale that requireda particular style of implementation.

By Continuous Harvesting to reap regular yields andby continuously eliminating unnecessary features byPruning Products, evolve stable products into ClassicLines. Products made on the basis of outdated moldsrequire Recast Molds to make them more relevant tocontemporary circumstances. Revisit the product’sRinged Growth to understand its historical complexity,and replace it with simpler logic such as Decide byMatching.

Another example is the pattern Few Skilled Gardeners,which is a good practice and one of the most influentialpatterns in this pattern language, as evidenced by itsmany linkages with other patterns.

Few Skilled Gardeners ��

Given that products are usually launched through projects,and that projects to realize products are primarily focusedon their launch, existing products tend to fall by the waysideas the spotlight moves to the next product launch. The mosttalented individuals in the organization are assigned to thenext big product launch rather than making the products ofthe last big product launch more efficient or being involvedin the removal of inefficient products. Establishing productownership in large organizations where each departmenthas a different focus for the product tends to be difficult.This leads to products not realizing their true potentialonce launched and a proliferation of products with marginalcontributions to the organization’s profitability. If productmanagers are solely responsible for administering launchedproducts across departments, their perceived value is from thenumber of products they administer, rather than how activelythey contribute to the company’s profitability.

Therefore selectively assign a few talented individualsas product managers, and establish this role as one ofthe most prestigious and well-compensated knowledgeroles in the company. Individuals who have strongcommunication skills, good market knowledge, strongtechnical knowledge, and operational experience aregood candidates for this role. They must also possess astrong network within the organization, with an under-standing of how to get things done efficiently. Engagethese individuals in actively realizing one or two prod-ucts, operating two to five products, and retiring oneto two products simultaneously (in large organizations).In smaller organizations, there is greater capacity torealize, operate, and retire products given that there isless communication required for each of these activities.For the products being operated, give each productmanager a few products that have low profitabilitybut great potential, a few stable and profitable products,and a few products with seemingly no hope of improv-ing profitability. Periodically the product managersshould exchange their most stable products with otherproduct managers, which could happen as often asevery six months in smaller organizations and annuallyin larger organizations. The most successful productmanagers should be established as knowledge mentorsfor other product managers and earmarked for leader-ship roles in the organization.

The Three Product Champions, who understand thecommercial, operational, and technological aspectsof the product, and the Participating CustomerDemographic, who are representative of the customerswho would use the product, work with a select fewproduct managers to Continuously Harvest, ConstantlyCirculate, and Clear Withering Products. Product man-agers engage in the realization of products by ade-quately planning their Ringed Growth, ensure thatnewly launched products receive Shade from Othersand Growth Supports within Themed Areas, constantlyPrune Products in their operational portfolio, establishkey criteria for the products’ adoption with ProductMarkers, and see to it that products don’t grow DeepRoots. When Exotic Plants must be Planted in theSingle Garden, it is entrusted to one of these selectfew individuals. Their products can be Changed withConfidence by themselves and any of the Three ProductChampions, giving them Signature Aromas that high-light the product’s salient traits, to spread adoption andknowledge across the Low-Walled Town Communitiesand beyond the Fortified Walls in controlled circum-stances with selected partners. They frequently visit theTown Well to speak to others in the organization andcreate a culture of Specifying to Operationalize, whichrequires that the documentation around the product

©2012 Indranil Bhattacharya and Michael Hartges. All rights reserved.CUTTER IT JOURNAL December 201216

is just enough to make it operational. When productsdon’t work well, they place them in Temporary Splintsuntil they do. They conceptualize new ideas withinTrusted Circles using Living Prototypes and LivingData Everywhere and create initiatives where theWhole Town Participates.

CONCLUSION

A pattern language, like the one proposed in this article,can help an organization transition from using one setof practices to manage products to using a networkedset of practices. A metaphorical language acts as amnemonic device to help people remember the namesand meanings of patterns, such as Deep Roots. Relyingon the mind’s ability to process complexity throughmetaphors9 makes it possible to unify the solutions intoa practicable whole. This pattern language can also beused to influence daily practice in every level of anorganization. Practitioners employing the pattern lan-guage can judge how best to develop, alter, or removeproducts; when to engage others in participatoryprocesses; and how best to shape the architecturesthat support products.

The development of our pattern language is a continu-ous process. The emergence of new situations, causedby factors such as new business opportunities and newtechnologies, gives rise to new and unforeseen forcesthat must be resolved either with the existing patterns,with reconfigurations of the existing patterns, or withcompletely new patterns. This continuous process isreflective of a dynamic business and helps telecomoperators transform themselves from operating in valuechains to value networks.

In creating this pattern language, we see the need formore research into integral architecture practices, inwhich business and technological practices are not seg-regated. Enterprise architecture artifacts that require theknowledge and skill sets of an enterprise architect forcomprehension can be difficult for everyone in a largeenterprise to understand. Pattern languages provide abasis for architectures of engagement and participationat every level in an enterprise. We also see the need forpractices that help large organizations adopt patternlanguages. One such method is the application of archi-tecture styles,10 which can be used to explain a collec-tion of applied patterns with a strong metaphoricaltheme. Enterprise architects and system designers can

then utilize an architecture style to decide upon a set ofcriteria for selecting an appropriate network of patternsto resolve complex business situations.

ENDNOTES1Peppard, Joe, and Anna Rylander. “From Value Chain to ValueNetwork: Insights for Mobile Operators.” European ManagementJournal, Vol. 24, No. 2, 2006.

2Ohno, Taiichi. Toyota Production System: Beyond Large-ScaleProduction. Productivity Press, 1988.

3Snowden, David J., and Mary E. Boone. “A Leader’sFramework for Decision Making.” Harvard Business Review,November 2007.

4Alexander, Christopher. The Timeless Way of Building. OxfordUniversity Press, 1979.

5Bhattacharya, Indranil, Sergej van Middendorp, and AndreKampert. “What Is Embodied Making?” Embodied Making(http://www.embodiedmaking.com/method/What_is_Embodied_Making).

6Greenwood, Davyyd J., and Morten Levin. Introduction toAction Research: Social Research for Social Change. 2nd edition.SAGE Publications, 2006.

7Bhattacharya, Indranil, and Michael Hartges. “Patterns:A Product Lifecycle Management Pattern Language forTelecommunications Operators.” Embodied Making, 2012(http://www.embodiedmaking.com/patterns).

8Alexander, Christopher, Sara Ishikawa, and Murray Silverstein.A Pattern Language. Oxford University Press, 1977.

9Lakoff, George, and Mark Johnson. Philosophy in the Flesh: TheEmbodied Mind and Its Challenge to Western Thought. Basic Books,1999.

10Bhattacharya, Indranil. “Architecture Styles.” Journal ofEnterprise Architecture, Vol. 8, No. 1, February 2012.

Indranil Bhattacharya is an Enterprise Architect with around 15 yearsof experience in developing and designing systems in large enterprises.He works in the enterprise architecture practice within DeutscheTelekom, specializing in the product lifecycle management domain. Inhis spare time, he works on social ventures that assist small businessesin becoming more competitive by working together in collaborativesupply chain networks. He can be reached at indranil@perfectarch.com.

Michael Hartges is an Enterprise Architect who has worked forDeutsche Telekom in various international IT positions since 1999.After starting as team leader for the billing and accounting mobilesatellite communications unit, his main focus became enterpriseintegration and, later, enterprise architecture. He holds a degree inbusiness administration from the University of Cologne and recentlyjoined an international professional program in business and enter-prise architecture. He can be reached at michael@hartges.de.