Business Patterns for Software Developers E-Book

Allan Kelly

• Herausgeber: John Wiley & Sons
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Englisch

Seitenzahl: 591

Veröffentlichungsjahr: 2012

Beschreibung

A must-have recipe book for building software Perhaps you can relate to this all-too common scenario: you know all about your software product?but could do with some help in understanding the strategic side of things. If so, this book is the one-stop resource you'll need in order to become a successful software entrepreneur. Patterns expert Allan Kelly provides you with the step-by-step route that needs to be followed in order to understand business strategy and operations. Each chapter starts out with a solid introduction and theoretical overview, which is then further illustrated with patterns and case studies, all aimed at helping you move into the management of software. * Teaches you the ropes of business strategy and operations for software * Places special emphasis on the patterns for those who make software for sale * Addresses patterns philosophy, patterns strategies, business strategy patterns, and software company lifecycle * Shares practical tools, tips, and examples of best practices so you can see how each specific pattern fits in and needs to be implemented. Business Patterns for Software Development divulges strategies, operations, and structures for building successful software.

Leseprobe

This edition first published 2012

© 2012 John Wiley & Sons, Ltd.

Registered office

John Wiley & Sons Ltd, The Atrium, Southern Gate, Chichester, West Sussex, PO19 8SQ, United Kingdom

For details of our global editorial offices, for customer services and for information about how to apply for permission to reuse the copyright material in this book please see our website at www.wiley.com.

The right of the author to be identified as the author of this work has been asserted in accordance with the Copyright, Designs and Patents Act 1988.

All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, except as permitted by the UK Copyright, Designs and Patents Act 1988, without the prior permission of the publisher.

Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic books.

Designations used by companies to distinguish their products are often claimed as trademarks. All brand names and product names used in this book are trade names, service marks, trademarks or registered trademarks of their respective owners. The publisher is not associated with any product or vendor mentioned in this book. This publication is designed to provide accurate and authoritative information in regard to the subject matter covered. It is sold on the understanding that the publisher is not engaged in rendering professional services. If professional advice or other expert assistance is required, the services of a competent professional should be sought.

Wiley and the Wiley Publishing logo are trademarks or registered trademarks of John Wiley and Sons, Inc. and/ or its affiliates in the United States and/or other countries, and may not be used without written permission. iPhone, iPad and iPod are trademarks of Apple Computer, Inc. All other trademarks are the property of their respective owners. Wiley Publishing, Inc. is not associated with any product or vendor mentioned in the book. This book is not endorsed by Apple Computer, Inc.

Every effort has been made to contact the copyright owners of third party material contained in this book. If there are any inadvertent errors or omissions we apologise to those concerned, and ask that you contact the publisher so that any corrections can be made in any reprints or future editions.

A catalogue record for this book is available from the British Library.

ISBN 978-1-119-99924-9

Set in 10/12 point Utopia by WordMongers Ltd, Treen, Penzance, Cornwall

Table of Contents

Title

Copyright

Dedication

Foreword

Acknowledgements

Chapter 1: Introduction

The Whole

The Journey to Business Patterns

Audience

A Story Book

Limits of the Book

Book Structure and How to Read

Sequence Diagrams

Comments Please

Chapter 2: Structure of the Software Industry

Types of Companies

Outsource and Offshore

Vendors and the Software Stack

ISV / ESP Divide

Closing Words

Chapter 3: Software Company Lifecycle

Early Days

Growing

Post Start-up Middle Age

Investor Exit

Death of a Software Company

Death Throes

Walking Dead

Closing Words

Chapter 4: Strategy?

What is Strategy?

Strategy, not Plans

Strategy as a Pattern

Generative Patterns

Identifying Strategy

Strategy Parallels Software Design

Strategy for Software Creators

Closing Words

Chapter 5: Funding the Start

Bootstrapping

Friends and Family

Banks

Angels

Venture Capital

Private Equity

Investor Exit

Funding Timing

Love-hate with Venture Capital

Closing Words

Chapter 6: What to Build – Patterns about Products

Customisation, Platforms, Frameworks and Product Lines

Poacher Turned Gamekeeper

Customer Co-Created Product

Simpler Product

Same Customers, Different Product

Core Product Only

Customisable Product

Simple Product Variations

Chapter 7: Marketing

The Missing Link

Whole Product

Homogenous Customers

Segmented Customers

Customer Understanding

Expeditionary Marketing

Chapter 8: Distribution Model

Direct Sales

Distributors

Choosing a Distribution Model

Different Product, Different Channel

9 Patterns of Direct Distribution

Branded Shops

Internet Store

Named Sales People

Account Management

Sales/Technical Double Act

Chapter 10: Patterns of Indirect Distribution

Local Guide

Value Added Reseller

White Label

Independent Retailer

Wholesaler

Chapter 11: Service

Crossover

The Missing Pattern: Product from Services

Tailored Products – ‘Specials’

Customise or Co-create?

When Services Distract from Product

Closing Words

Chapter 12: Patterns about Services

Products with Services

Initial Help

Lifetime Services for Products

Professional Services Team

Services Feedback

Personal Service

Self-Service

Corporate Certified Experts

Packaged Services

Chapter 13: Patterns about Organising Product Companies

Capabilities

Structure

Services Before Product

Single Product Company

Product Portfolio

Product Roadmap

Complementor, Not Competitor

Innovative Products

Separate Imaginative Teams

Appendix A: About Patterns

What Is a Pattern?

Pattern Languages

Pattern Sequences

Improvising with Patterns

Anti-patterns

How to Read a Pattern

How to Write a Pattern

Closing Words

Appendix B: Patterns Philosophy

Patterns and their Implicit Context

The Quality Without a Name: Wholeness

Events or Things

Sustainability: Living and Dead Patterns

Classifying Patterns: Good, Bad, Dead and Alive

Worse is Better: Path Dependency?

Knowledge Management and Patterns

Storytelling and Patterns

Closing Words

Appendix C: Future Work – Patterns Arising

Reference

Index

Thank you for everything to Taissia, Grisha and Antonska

Publisher's acknowledgements

Some of the people who helped to bring this book to market include the following:

Editorial and Production

VP Consumer and Technology Publishing Director: Michelle Leete

Associate Director-Book Content Management: Martin Tribe

Associate Publisher: Chris Webb

Executive Commissioning Editor: Birgit Gruber

Assistant Editor: Ellie Scott

Copy Editor: Steve Rickaby, WordMongers Ltd

Editorial Manager: Jodi Jensen

Senior Project Editor: Sara Shlaer

Editorial Assistant: Leslie Saxman

Marketing

Associate Marketing Director: Louise Breinholt

Senior Marketing Executive: Kate Parrett

Composition Services

Steve Rickaby, WordMongers Ltd

Foreword

I love books. I believe that all patterns fans love books. I remember in the early evangelical days of patterns introduction, arriving at a corporate site to talk about design patterns, hauling in my usual stack of patterns books: the Gang of Four (of course), the first of the PoSA series, several by Christopher Alexander and a PLoPD book or two. It was a lot of work, especially in the summer in Phoenix when the temperatures could be above 110 F. But it was worth it. Participants would immediately gather round, pick up, leaf through and start to read those books. It's often been said about Alexander's A Pattern Language that you start thumbing through, and then it happens – the book draws you in and soon you’re reading and reading and reading.

Good pattern books are all like that. Actually all good books are like that. It's one reason why I miss bookstores. You can't, even when selections are available online, browse books in the same way. I think you'll find Allan Kelly's book is the same. You'll pick it up. You'll see a particular pattern that catches your eye because it calls up a problem you've had or are having, and pretty soon you, too, will be reading and learning. One participant at a long-ago patterns talk, when asked about the attraction of books, said, “Some of my happiest memories are about books”.

I think that books have this power for us because they are proxies for the longest-lived form of learning – listening to others tell a story. Allan mentions Steve's Denning's work on corporate storytelling – how a good story is the most effective way to persuade others to hear your compelling idea. Readers will like the format for Allan's patterns, because each one opens with a short story.

Mary Lynn Manns and I decided to adopt that format for the patterns in Fearless Change after feedback from our reviewers. We had not taken the time to find good images for the patterns, believing that we could do that at a later date. We did, however, include a lot of known uses – stories from contributors all over the world who had used the patterns. Our reviewers noted that these stories, especially the more powerful ones, seemed to embody the message of the pattern – they were almost a stand-alone explanation. The suggestion was that we move an archetypal story to the opening of the pattern as a replacement for the image. Readers could then create their own images, in the same way that radio listeners used to. I remember many happy hours after school listening with my brothers to The Lone Ranger on the radio, and was almost disappointed the first time I saw an episode on television – it seemed to be missing all the detail from my eight-year-old imagination.

Good stories reflect the author's expertise. It's why we want to hear good storytellers. We're all looking for answers. We want some suggestions for new directions, experiments we might try in our organisations and in our lives. You will definitely find that in Allan's book. The expertise shines through – in the stories, in the understanding of the challenges we face and in the powerful solutions. This is one reason why patterns books take a long time to produce. It's not a simple matter of documenting the idea we had in the shower this morning. Patterns capture expertise, that of the author and of those who contribute known uses, examples or stories of their experiences using the pattern. It takes considerable effort to gather all that valuable material.

I can recall the first time someone asked me a very important question about books: can you think of at least one book that changed your life? I struggled with this question when I heard it, but then the obvious answer appeared. The book with the most impact on my life was one I had written: Fearless Change. Over the ten years it took to produce that book, I changed from a techie, a software designer, to someone intensely interested in the people side of development, especially the psychology of human interaction. The amount of research from the cognitive scientists that appears almost daily is overwhelming. It all has to do with us as humans, and has enormous impact on our software development and business process. It wasn't an overnight change, since the book took ten years to create, but it turned my life and career upside down. My personal mission statement is to translate as much of the research in this area to those in software development who are willing to listen.

Now that I teach others these patterns, I'm constantly reminded of how I saw the world. I encounter participants who want to introduce new ideas by ‘forcing people to use patterns’ or any new technology. There is a strong sense in many people that, if you just had enough power, you could get others to change. Even when I spent time discussing the difference between ‘compliance’ – where others toe the line and give the appearance of adopting the new idea – and ‘commitment’ – when others sign up for the innovation because they also believe it is the right thing to do, I often feel that many innovators would prefer a club to using influence strategies.

I experienced this again when my boss stopped by my cubicle one day and asked me to look into some possible patterns for customer interaction. Our small teams were moving to Scrum, something that I had found on the web and thought it might help. No books on agile development were available in the mid-90s, but controlchaos.com and some e-mails with Ken Schwaber and Mike Beedle helped us jump-start agile in our organisation. There was just one small problem: we expected developers to interact with customers. Developers are, for the most part, good-hearted technical people. Their people skills may be limited. It was unfair of us to expect them to understand immediately how to work with customers effectively.

That was not a simple assignment. I was not an expert in customer interaction, but I spent considerable time interviewing our business and marketing folks and others throughout the company who interacted with our customers successfully. The result, Patterns for Customer Interaction, again taught me that while we techies believe that a good technical solution is what the customer really wants, determining the true nature of that solution and how best to implement it requires more understanding of human interaction than computer performance. It was another wake-up call.

I hope you're wiser than I am. I hope that you already understand the importance of the business and human side of development. You don't need a wake-up call to see how critical Allan's patterns and others like them are to successful software development. You won't make the mistakes I have made. You know you need this book!

I first saw Allan's patterns at VikingPLoP in 2004. They resonated with me because I was working on some patterns for building beautiful companies with Daniel May, Steve Sanchez and Caroline King. I thought at that time that Allan had the beginnings of a book, and I am so happy to be able to introduce it to all of you. The Beautiful Company patterns were never finished – a casualty of lack of time, so common these days (the initial cut is on my website, lindarising.org) but I'm delighted that Allan has been diligent and has produced his own patterns to help you build your own beautiful company. Enjoy.

Linda Rising, Independent consultant

Mt. Juliet, Tennessee, USA

Acknowledgements

In some ways this book is accidental. Initially I wanted to see if the pattern form could add anything to the thinking and writing about business strategy. The experiment took the form of two papers, one at EuroPLoP and one at VikingPLoP (Kelly, 2004a; Kelly, 2004b). The experiment eventually worked: I learned a lot about what would work and what wouldn't. I also found insights into the original source material.

The more I looked at patterns of business strategy, the more I saw. Patterns to the left of me, patterns to the right of me. There are still many more business strategy patterns I have identified but have not had the time to write up.

It took me a while to come around to accepting there was a book in these patterns. Which is strange, because two people saw the potential almost immediately and have encouraged me along the way: Lise Hvatum and Cecilia Haskins. These two Norwegian-American crossovers have encouraged my writing, supported me when I've had doubts and been generous with their comments, criticism and advice.

Strangely enough neither Lise or Cecila actually shepherded any of the patterns in this book. As every pattern author knows, the shepherd plays an invaluable role in the creation of every pattern. I have been truly fortunate to have had some wonderful shepherds during this project: Manfred Lange, Daniel May, Alan O'Callaghan, Klaus Marquardt, Michael Weiss and Uwe Zdun.

Klaus, Daniel and Michael deserve special mention for shepherding several pattern papers. Daniel's advice, both in the early patterns and the later ones, was critical in shaping the work, challenging me and pushing me to go further.

Manfred also deserves special mention for being the first. Although the 2004 Porter Patterns are not included here, they were the start of the project, and Manfred's advice was particularly useful in shaping the business patterns that came later.

But shepherds are not the only PLoP reviewers: many more people commented on these patterns in workshops during VikingPLoP and EuroPLoP. Thanks too to: Ademar Aguiar, Albena Antonova, Valerie Brown, Jim Coplien, Lotte De Rore, Andreas Fießer, Alexander Fülleborn, Ian Graham, Birgit Gruber, Cecila Haskins, Kevlin Henney, Florian Humplik, Lise Hvatum, Halina Kaminski, Maria Kavanagh, Gwendolyn Kolfschoten, Herman Koppleman, Dinesha Koravangala, Wim Laurier, Andy Longshaw, Stephan Lukosch, Nora Ludewig, Jorge L. Ortega Arjona, Klaus Marquardt, Linda Rising, Pavel Hruby, Rebecca Riker, Jan Reher, Jürgen Salecker, Martin Schmettow, Lubor Sessera, Kristian Elof Sørensen, Hans Wegener, Claudius Link, Anne Hoffman, Neil Harrison, Aliaksandr Birukou, Christoph Hannebauer, Elissaveta Gourova, Yanka Todorova and Tim Wellhausen.

Thanks too to the reviewers who worked with me and Wiley at various stages to help improve the book: Charles Weir, Phil Nash, Mark Dalgarno, Linda Rising, Daniel May, Klaus Marquardt, Cecilia Haskins, Carl Åsman and Filipe Correia.

At VikingPLoP 2004, still early in the experiment, I experienced a degree of doubt and uncertainty concerning the pattern form for business patterns. I found the answers I needed in the writing of Dick Gabriel and Stephen Denning, and later in conversations with Klaus Marquardt and Jorge L. Ortega Arjona.

Dick Gabriel is a long-standing member of the patterns community and one of its more noteworthy philosophers. He is also a poet, and compares writing software and patterns to poetry. His Patterns of Software (Gabriel, 1996) had significant influence on my thinking about patterns, poetry and stories.

For me patterns, like poetry, are stories told in a specific way. I arrived at this conclusion after reading Stephen Denning's The Springboard (Denning, 2001) and Storytelling in Organizations (Brown et al, 2005). Denning, like Gabriel, has left his mark on this text without knowing it – and possibly without actually knowing about patterns!

Klaus Marquardt suggested that it may be the pattern writer, not the pattern reader, who gets the most out of a pattern. In effect, by writing the pattern we are forcing ourselves to understand it in depth. Writing the pattern is itself a ‘sense-making’ process for the writer. While I believe readers will certainly learn from this book, the author has learned far more during its writing.

Jorge L. Ortega Arjona pointed out that in most forms of art and literature, such as novels, films and music, it is normal to have many stories about the same subject. So why should pattern writing be any better? Duplication may run counter to minimalist instinct, but it certainly helps to tell a story.

In late 2009 I started to assemble the patterns so I could see the whole. Once whole it was clear that there was a book, and from that point on another group of people become involved: from 2009 Birgit Gruber at Wiley played midwife to the book. Thanks Birgit! Birgit was just one of many at John Wiley & Sons who helped this book come into being: thanks are also due to Chris Webb, Leslie Saxman, and Ellie Scott, and especially to Steve Rickaby of WordMongers for editing, typesetting and everything else.

Thanks too to Peter Sommerlad for the Itopia story, and to Nat Pryce, who in an off-hand, beer-enhanced, rant against pattern books at XTC unwittingly contributed to this book by listing things he didn't like about them. When agonising about how to present the patterns and book, I often heard Nat and Daniel's voices in my head.

As should be clear by now, lots of people had a hand in helping to create this book. Inevitably I will have missed some people, so thank you too, and my apologies.

Finally, thank you Taissia, my loving wife, for supporting me in the years of pattern writing and book construction, and thank you Grigory and Anton for being there to distract me, interrupt me and for generally being good sons.

Chapter 1

Introduction

‘ Software entities are more complex for their size than perhaps any other human construct because no two parts are alike ’

No Silver Bullet, Brooks, 1986

Building software is hard: successfully bringing a new software product from conception to market is harder. Building a successful software company that develops and markets multiple software products is harder still.

The days of ‘build it and they will come’ are over. Simply creating a great piece of software and waiting for the customers to knock on your door no longer works – if it ever did.

Nobody should ever think that building software is easy: some small application may indeed be easy to build, but meaningful software applications and platforms are extremely complicated things to create. However, building software is at least a reasonably well-defined task which isn't true of many of the other things that need to be done. Indeed it isn't even clear what needs doing.

Creating a successful software product, and building a successful software company, involve a myriad of other activities that are far less easy to define and put boundaries around. The first of these is just deciding what it is that should be built. But perhaps the most difficult task of all is bringing all these activities – well-defined, poorly defined and never defined alike – into alignment so that they move towards a common goal. This is akin to an exercise in formation flying in which the individual pilots have their own opinion on where they should be going. The bigger the company, the more complex the environment, the more difficult the task.

Focusing on the customer helps: after all, we all agree the customer comes first (don't we?) But while it might be clear what an individual customer says they want, what they are willing and able to pay for might be something different. When individual customers are aggregated into a market – be it millions, thousands or just dozens – it can be extremely difficult truly to know what the customer wants.

Customers are not homogenous: they want different things, but if you intend to build a product to sell to many of them, you need to determine common needs. Great leaders help, but great leaders are not a panacea. Leadership can give direction and common goals, but if a company can only survive with a truly remarkable leader, then the leader has failed. Leaders lead, but they also need to put in place mechanisms to prevent single points of failure.

Given all these difficulties, and more, is it a any surprise that many choose to focus on something right in front of them? Something here and now? We might call it ‘goal displacement’. Building a company is an engineering task to parallel the construction of the software itself.

The patterns in this book describe many of the recurring problems software companies face and details the solutions found by existing companies. The patterns follow the well-known pattern format: a problem statement, a set of forces that make the problem difficult, a solution, with details of how to build it, the consequences of the solution, and examples and related work.

The Whole

‘No plan survives contact with the enemy.’

General Helmuth von Moltke

Each pattern in this book contains one part of a solution. It may be used in isolation – a component if you like, dropped in to fix an issue. But each pattern also links to other patterns, and together they build towards a complete thing, a whole.

The whole is more than the sum of its parts. The whole is the thing you see when everyone is flying in formation. The whole happens when all the different parts of the organisation – engineering, sales, marketing – are coordinated, aligned, heading in the same direction. In business, making this happen is strategy.

Strategy sets organisational goals, objectives and direction. It is embodied in structures and organisation. It is planned, but it is also dynamic. It is changing in response to events and learning. Strategy looks forward and looks backwards to make sense of events. Strategy may be equated with a plan, something that is determined by a few – top management, consultants, planners – and executed by the many. But the devil is in the detail: things are just too complicated for a comprehensive plan.

While there are elements of forward-looking planning, strategy is equally the result of what happens; it emerges from events and decisions: what happens in the market, what engineers learn as they build the product, what competitors do. Strategy is backwards-looking; it makes sense of what has happened in order to direct the future.

Patterns are ideal for describing strategy, because they share these characteristics. Patterns are descriptions of what happens – like strategy, they emerge from looking backwards, adding to understanding and making sense. They are also forward-looking: they describe what to do.

Used alone, an individual pattern might be strategic, or it might just be something done to fix a problem – that is, tactical. When brought together, when used in a sequence to form a whole, they work strategically. Patterns direct and inform, but they are not a straight-jacket; you can, and should, vary a pattern as you see fit. This is how new patterns come into being.

Patterns describe the problems and the solution, and importantly, they name these things. Perhaps the most important thing a pattern adds to a discussion is a name. Patterns bring a shared vocabulary, which raises the level of the discussion.

Rather than talking about ‘that thing you do when you involve the customer in creating the product but don't create the product only for that customer’ you can say Customer Co-Created Product. This raises the level of the discussion and the abstraction level, it moves the conversation along more quickly and gives everyone, from CEO to lowly software engineer, a common language.

Patterns

‘According to leading management thinkers, the manufacturing, service, and information sectors will be based on knowledge in the coming age, and business organisations will evolve into knowledge creators in many ways.

According to [Peter Drucker] we are entering ‘the knowledge society,’ in which ‘the basic resource’ is no longer capital, or natural resources, or labour, but ‘is and will be knowledge…’

(Nonaka & Takeuchi, 1995)

Patterns are all around us; it is simply a question of whether we see them and whether anyone has documented them. Patterns are recurring events, situations, constructions and ideas. They occur over and over again. Things that happen once are not patterns, but when they recur several times we label them patterns.

A pattern exists for a reason. A pretty design on a tie, on a sheet of wallpaper or on a dress is just that, a pretty design. These patterns exist to decorate people and places; attractiveness is no small matter. When these designs are used again and again, they take on meaning: they are used again and again for a reason.

The pattern on a tie may simply be there to make a businessman look good, but it may also serve to identify him as a member of an association, a clan or an alumni of a college. Similarly, a pattern on a dress may make the woman wearing it look good, but it may also help to identify her or convey authority and legitimacy (think of a nurse). Wallpaper may look nice, but we would choose different wallpaper for a gentleman's club to that for decorating a baby's nursery.

Things recur for reasons; things repeat for a reason.

In the 1970s the architect Christopher Alexander devised the ‘pattern form’ to codify his thinking about architecture. Using patterns, he documented the way in which buildings are located, laid out and constructed in recurring ways for reasons – reasons he came to call forces. Traditionally the logic behind these designs was handed down by word-of-mouth and through participation. Today those who study these things would call this ‘tacit’ knowledge and would say it was communicated through stories and legitimate peripheral participation.

Alexander also believed that this knowledge was being lost. Modern architecture and modern society separates architects and builders from those who use the buildings. So he set about codifying the patterns that made buildings the way they are.

By the early 1990s the software engineering community faced a knowledge transfer problem. Knowledge of how to build computer systems effectively existed, but was confined to a few experts. Even when the knowledge was widely known it was difficult to talk about. The rapid growth of the discipline needed a new way of communicating this knowledge.

In the late 1980s a few engineers in the software development community began to look at Alexander's pattern ideas. Bruce Anderson, Kent Beck, Grady Booch, Jim Coplien, Ward Cunningham, Erich Gamma, Ralph Johnson and others set about applying Alexander's ideas to software. One result of this was the formation of the Hillside Group (www.hillside.net) topromote these patterns. Like Alexander, they used this approach to codify tacit knowledge so that it could be communicated and shared in a wider community.

The patterns identified by Alexander and the software community were not created by them. Patterns can, and do, exist independently of documentation. The world is full of undocumented patterns. Only a few of all possible patterns are documented. To those which are documented, the title pattern is awarded. These patterns codify the events and constructions that happen again and again.

Building on Alexander's ideas, each formally documented pattern contains:

The problem the pattern is addressing

The context in which the pattern is found

The forces that make it hard to solve

The solution

How the solution is constructed

The consequences of implementing the solution

Patterns that adopt this approach may be called Alexandrian patterns. There are different formats and styles in which such patterns might be written (see Appendix A) but, in general, as long as they consider these elements, we may call them Alexandrian patterns, or just patterns for short.

Ever since software professionals started writing patterns there have been some patterns which concern themselves more with the business side of the profession than the technical side. For example, the patterns in Organizational Patterns of Agile Software Development (Coplien & Harrison, 2004) are more about organisational form than software development. Fearless Change (Manns & Rising, 2005) originated in the software community, but is really about introducing organisational change.

This book sets out to show how the pattern approach can tackle the major issues of business – strategy – and specifically, business strategy as deployed by companies that create software.

All that jazz

The formation flying metaphor works – especially for engineers – but business people have long preferred the analogy of the symphony orchestra. The famous business writer Peter Drucker compared the executive's role to that of a conductor coordinating an orchestra (Drucker, 1985). Yet even the most famous symphony orchestra conductors only spend a small proportion of their time actually conducting in performance. After observing an actual conductor at work for a day, one writer suggested that ‘rehearsing is the work of the organisation’ (Mintzberg, 2009).

Rather than symphony orchestra, jazz offers an alternative metaphor – that of coordinated improvisation (Weick, 1997; Weick, 1999). Jazz musicians actively engage in improvisation and variation; free jazz in particular deliberately sets out to extend the score, to alter it and to break the rules with the aim of improving the experience.

There is no dedicated, isolated, conductor/leader here: maybe the drummer sets the beat, or maybe the sax takes the lead, but the leader is part of the band, the team. And while the team have a goal – a particular melody or sound to perform – each performance is different and contains improvisation. Experimentation is encouraged.

Formation flying is highly risky: improvisation is discouraged, for obvious reasons. But in business we have no choice; there are too many unknowns, many unknowables – we need variation and improvisation.

The difficult part is improvising while remaining coordinated. Individuals and teams need to be innovative, they need to experiment, they need to try new things, but simultaneously they need to be consistent and to work with others in the organisation.

For musicians the score gives an approximate map: however, things will definitely not unfold exactly according to the score. Patterns can help here: like a music score, they provide a shared understanding and language, a framework within which the players can perform while understanding the kind of moves others might make.

The Journey to Business Patterns

Many patterns have been written about the design and architecture of software systems. Other patterns have been written that describe the structural development of software organisations.

The more established patterns of software design exist within the context of organised software development. As long ago as 1968 Mel Conway pointed out that the organisation structure will influence system structure (Conway, 1968). Consequently, some architecture designs and patterns are more applicable in some organisational contexts than others. For example, an organisation with a large centralised team and several smaller distributed teams may find Patterns for Plug-ins (Marquardt, 2006) perfectly applicable. Conversely, developers working separately and under time pressure may find their design degenerating into a Big Ball of Mud (Foote & Yoder, 1999a).

Similarly, organisational structure will constrain the strategies available to an organisation, while the strategies a company pursues often dictate organisational structure. For example, staffing levels will be effected by the use of Domain Expertise in Roles (Coplien & Harrison, 2004). Similarly, a strategy of utilising offshore development may make use of Join for Completion (Bricout et al, 2004). Organisations, their structures, culture and constraints provide context and forces within which patterns form.

Through such mechanisms, the patterns used at one level in the organisation constrain the options available at another level. As Conway suggested, the organisational structure will influence the system structure. However, it is also true that the system structure can effect the organisational structure: ‘Reverse Conway's Law’ (Hvatum & Kelly, 2005).

Figure 1 shows that we can think of these different levels as partially constraining each other. The end state of one applying one pattern – the consequences – sets up the conditions – the context and forces – for the next. Applying one pattern generates the conditions for the next: thus, patterns are often found in recurring sequences.

Figure 1. Patterns at one level are partially constrained by patterns at other levels

Tactics, in contrast with strategy, are often regarded as less important. So it is that some patterns may appear to be relatively unimportant. However, when viewed from a different perspective – perhaps a later date – these details can take on significant and even strategic importance. There are no firm boundaries between what is tactical and what is strategic; details considered tactical today may be strategic in future. One should not apply the labels ‘strategic’, ‘tactical’ or ‘implementation’ too quickly.

Why capture patterns?

Much tacit knowledge already exists in the minds of experts. In the case of business these experts are the managers, entrepreneurs and consultants who make business work. They have little need of explicit pattern documentation because the patterns are in their heads.

While this knowledge remains locked inside expert's heads it remains inaccessible to the people who live in the society they create. Modern society is increasingly governed by the business paradigm and the implicit patterns of that paradigm. For society and businesses to be successful this gap needs to be closed, a situation similar to architecture:

‘So long as the people of society are separated from the language which is being used to shape their buildings, the buildings cannot be alive.’

(Alexander, 1979, p. 241)

There is a parallel between the construction of physical buildings and the construction of enterprises – an activity tellingly referred to as ‘building a business’. Turning tacit knowledge into explicit pattern documents is an important step in sharing this knowledge. By sharing we close the gap between people and business, thereby improving the quality of life and opportunities for all.

Architectural ‘patterns do not come only from the work of architects and planners’ (Alexander,1979, p. 199), and similarly business patterns do not need to come only from business experts. It is not just business experts who innovate; your local shop or café can be as innovative as a business consultant.

Explicitly documenting patterns has additional benefits beyond communication. Documented, patterns can be communicated, shared, analysed for improvements, alternatives or anomalies. The documentation process itself focuses attention on the act of design, it highlights the forces leading to the choice of a design and its consequences (both positive and negative.)

Patterns do not stop at design, they delve into the ‘How do we build this?’ question. And patterns beget patterns: patterns are generative in nature.

Audience

The patterns in this book are intended to codify some common business practices in a pattern language, so that they may be better understood, communicated and used. The patterns given here are intended for those interested in how corporate strategies are created and may be applied. This includes existing managers, future managers and entrepreneurs.

In particular, it is hoped that those on the receiving end – software engineers, testers, etc. – of such strategies and tactics will find the patterns informative and useful. Understanding what a company is attempting, why it is acting and the implications can be benefit everyone in the organisation. When company strategy is more widely understood, coordination should be easier.

The patterns presented here may be read and applied outside the domain of software companies. They may be applied to technology companies in general, and to non-technology companies in some instances. The domain and context of the patterns has been confined to software companies for two reasons. Firstly, this is the domain the author knows and in which he has experience. Secondly, limiting the domain helps to maintain the brevity of the patterns. Despite these deliberate limitations, the author believes many of the patterns may be applied in contexts outside the software domain.

A Story Book

Together these patterns form a story about how software companies do business. This story attempts to make sense of a diverse and changing field, a field which is not only confusing to newcomers, but is often confusing to those who have worked in it for years. What is not said in a story can be as important as what is said. Readers are left to fill in the blanks and incorporate their own experience and views, to make these stories their own.

While this author has striven for objectivity and universality, the patterns presented in this book are inevitably a reflection of his views, observations and understanding. Examples and references are included to support these views, but every example can be interpreted in many ways. More detailed analysis would certainly have enhanced objectivity, and may well have offered new insights and knowledge. But in doing so the stories would have lost their narrative.

Despite the wealth of good information to be found in academic journals on business and management, few practising managers or businessmen read these journals. For better or worse the academic form, the presentation style, the reference to past work and writing style make these journals unreadable for most people. While this author has observed some conventions, and wherever possible provided references, he has placed readability and story-telling above academic rigour.

In research terms the patterns in this book are based on the author's first-hand experience, supplemented with qualitative research. Much of the qualitative research is summarised in the boxed items between the patterns, the vignettes that open the patterns and the examples that complete the patterns. In most cases this research has not be conducted with academic rigour, but the author's views and intuition will hopefully compensate for this.

The patterns in this book aim to convey knowledge and understanding, but they are first and foremost stories. I intend these stories to be read, and hopes they will inform and inspire action in the reader.

Limits of the Book

Like any book, this book has its limits. Several have become increasingly apparent as final editing and preparation have approached, and deserve to be acknowledged.

The first limitation has already been mentioned: academic rigour has taken a back seat to readability and story-telling. From its first words to the final printed copies this book, over eight years will have elapsed in its making. During this time things have changed. Were work to begin on it tomorrow, it would be very different.

In particular, two major forces have emerged and continue to emerge in the world of software companies. Open Source development is providing new options for new businesses and changing the competitive landscape for those that already exist. While this book does not, perhaps, pay specific attention to Open Source as a business model, most of the patterns are applicable to companies working with Open Source models. It is my fervent hope that we shall see a book of Business Patterns for Open Source Companies before long.

At a far earlier stage than the Open Source movement lies the Lean start-up movement (Ries, 2011, www.startuplessonslearned.com). While still yet in its early days, this movement represents one of the most interesting changes in business strategy for some years. New patterns will arise in this field; only as these ideas become more widely applied will new patterns start to become visible.

Finally, while the examples in this book are intended to illustrate and explain the strategies and tactics under discussion, they are also hostages to the future. For example, Nokia provides the known uses for several patterns. Initial drafts of this book had Nokia providing even more known uses and examples, but Nokia in 2011 is not the successful company it was in 2007 or 2003. Things change, leaders becomes losers, strategies don't work or prove difficult to implement, and those pesky competitors change the context. Some of the original Nokia examples have been removed and others have become counter-examples. Time alone will tell how many of these examples and patterns stand up and are truly timeless.

Book Structure and How to Read

This book contains two types of pattern. Firstly, Patterns with a capital ‘P’ – Customer Co-Created Product, Local Guide, Personal Service and more. These form the bulk of the book and can be found from onwards. These patterns are written up in a defined format with a name, problem statement, a solution and supporting sections.

Then there are patterns with a small ‘p’: these are informal patterns described in unstructured English narrative. These are unnamed, dispersed and embedded throughout the book. To write a book containing only formal patterns would make for a dull book, and would also take significantly longer to complete, because of the review process, and far longer to read.

The obvious way to read this book is to start at page 1 and read to the end. There is nothing wrong with this approach, but it is not the way I would imagine reading this book.

Certainly, start at page 1 and read chronologically until the end of Chapter 5. Treat the book like a hyperlinked website: the pattern names are the links; follow them as curiosity strikes. As you go, you will encounter the names of patterns – Pattern Names are in Small Capitals Font. If the pattern interests you, break off, read the pattern, then continue from the point at which you departed. If, while reading a pattern, you encounter the name of another pattern that interests you, then break off and read that pattern.

Taken this way, by the time you reach the start of the formal patterns, you will have read a good few of them already. Continue reading chronologically, but confine yourself to the opening sections and sequence diagrams of each chapter. Only read the patterns as and when you are motivated to.

You will also find boxed items interspaced with the text. As with the patterns, read these as curiosity strikes and as you encounter the references. Boxed items and individual patterns should make this a good book for flicking through and reading sections as you choose.

The book ends with appendices. These are intended for those who want really to understand patterns and the philosophy and thinking behind the patterns in this book. They also provide suggestions for where business patterns might go next.

Finally, as you encounter a pattern you think is useful, perhaps one you recognise – maybe you have an ‘aha! moment’ as you recognise something you are doing – please share it with a friend, a colleague or a co-worker. That is how the language of patterns will spread and become even more useful.

Sequence Diagrams

Each pattern chapter opens with a sequence diagram showing how the patterns defined in the chapter fit together with others in the chapter and patterns from elsewhere.

Figure 2 provides a key to these diagrams.

Figure 2. Sequence diagram key

These sequences have a casual resemblance to Strategy Maps (Kaplan & Norton, 2004). This was never the intention: sequence diagrams are well established in the pattern community, and pattern sequences are discussed in AppendixA. That two communities can find similar techniques for describing strategy implies that there is some merit to drawing strategy visually.

Comments Please

All the patterns in this book, with one exception, have been through an extensive review cycle at EuroPLoP and VikingPLoP conferences. The author continues to welcome comments on the patterns, although obviously there is only limited opportunity to update them now.

In particular, the author would like to hear about further examples of these patterns and instances where they have been used as a guide to business. Please send comments to [email protected].

Chapter 2

Structure of the Software Industry

If we are to talk about software creators and the companies that create software, we need to define what we mean by a software company. Or rather, we need to differentiate between the many different types of organisations that create software.

For the purposes of this book, I define a software company as ‘a company that derives the bulk of its revenues from the sale of software or services to produce software’. In most of this book we will be discussing one particular type of software company, the independent software vendor, or ISV.

While this book and the patterns within it contain lessons for all types of software producer, the lessons are clearest for ISVs. This is simply because ISVs have the simplest software business model. That is, the company lives or dies by its ability to sell the software it produces. Other software business models are equally valid, but the relationship between creating software products and making money is more complicated.