Business Patterns for Software Developers Paperback – Feb 27 2012
|New from||Used from|
No Kindle device required. Download one of the Free Kindle apps to start reading Kindle books on your smartphone, tablet, and computer.
To get the free app, enter your e-mail address or mobile phone number.
About the Author
Allan Kelly has seen the software industry from many different angles - has held just about every job in the software world and has worked with just about every type of company there is. As a result he has seen the many different ways of doing business the industry has, and seen many of the same ways repeated.
Most Helpful Customer Reviews on Amazon.com (beta)
The chapters containing the patterns are diverse and detailed covering the following business areas:
Services (Professional, customer service, self service, etc)
Patterns provide a succinct and clear language for representing complex ideas in common ways. Understanding how to use a pattern and this book becomes a great reference as well as education resource. Each of the patterns is presented in the following format:
Each of these characteristics enable the authors to explain business activities, processes and goals in no more than three or four pages. It provides enough information to get you started without too much information that artificially limits your design or innovation.
This book is HIGHLY RECOMMENDED for Consultants, IT professionals, Business Process Designers or anyone who has to learn a new area or wants to understand how business activities work. This is not a book you will read cover to cover, but neither is Alexanders two pattern books. Rather this is an active reference book, one that you will dip into, explore and learn from. It provides a great check to see if you are considering the right solution, covering all your bases, etc.
This book is for developers, to be sure. But it ought have a wider audience. Everybody in a software company, and many in business units will benefit from this book. I tried to think of some role that would not. I could not.
The evolution of software development describes an arc that has moved from the singular creation of software for a single purpose to the notion of a real product, with all that entails. In my experience, we are so good at developing crack software that we ignore its larger context as a product. Foreshadowing further, products sit in the context of the entire business world and tradition. Hang on just a bit if I have not turned you away.
Developers, or at least their keepers, are forever talking about the SDLC. Good as it is, the software development life-cycle is not to be confused with the product life-cycle, and neither with the life-cycle of companies. So Mr. Kelly yanks us back to consider the larger context of a software company.
So, instead of being project centric, he expands the scope to product centric. Later he will spiral again to the context of running a company. He is looking for analogous patterns at each level of the spiral.
Finance jerks always want to express the larger problem of what to do with software products as maximizing immediate returns. They always have new and better jobs after you are already dead. Finance champs all know that the area under the curve is the whole life of the company. That curve is the only non-destructive maximization. The rest is grift.
Most start-ups that do not fail quickly do not go past the initial phase of the early success attributed to a good idea. It may sometimes be given something resembling money. But, rather than using this initial success to enable, and more importantly to adjust to the next juicy market, the natural, uninformed tendency is to do more of the same, thereby missing the boat. The perfect balance is the dynamic dance between innovative risk and mundane financial muddling.
By the time Mr. Kelly gets to his discussion of strategy, it seems that developers are nearly always better assets when they know what their firm is doing, and thereby they align, however tangentially, to the company goals:
"Without shared understanding between individuals of what the company strategy is and its intentions are, there is risk of no coordination between apartments, teams and individuals: each runs in a different direction and then there is little overall forward movement"
Strategy, it turns out, is not only intentional, it emerges from the forces of the past. Therefore, it is foolish to embark on a strategy that you think is a good idea but divorced from the past. As emergent strategy cannot successfully drive the future, it does offer the real context to ground a real strategy forged from the intentional and the emergent. He refers us to Mintzberg from his "Strategy as a pattern; a consistent pattern over time. "
Strategy is not the plan; it is the thinking behind the plan.
It follows that, if patterns exist, they have an inductive aspect to them. Inductive reasoning of pattern progression can be a powerful analytical tool, but it is not enough to effect a brake through. In another curious analogy to pure software development, he says, "...as strategy is implemented it must allow for emergent properties."
Formal change control is an important discipline if the product is to fruit. Agile development needs agility strategy, if you will excuse the methodological pun.
Mr. Kelly provides a basic survey of funding start-ups. Ye who dance with Venture Capitalists best learn the steps before the music begins. If you play Faust, you better know how high you will be made to jump at each round of VC funding.
Next comes an extended discussion about classes or categories of products, and of how they live in the marketplace. He moves away from strictly software companies, and for good reason. Lifecycle patterns are easier to see when software people are not just looking in their own yard. Better to get out and see that product types, their characteristics and attributes, without the unintentional distraction caused by the familiar. Mr. Kelly is a superior pattern analyst and a superior strategist.
Surely as night follows day, marketing follows product in the developmental context (as opposed to the mature company). Thusly are going concerns built from start-up software companies. To move from a generic, or core product to an optimized company that grows nicely, there are more aspects to the grand strategy, or, as he names it, "the whole product".
Sound like quite a lot for one book, and one that is but 300 pages. We have come a long way, yet something is missing. The customer has gone missing.
Just as in product strategy, where he is loudly against the temptation to divert vital company energy into engineering one-offs, so he is likewise bold with customer focus:
ASSUME ALL CUSTOMERS ARE SIMILAR
It is not that you are not customer oriented, but that your product management does not dilute itself over functionality not common to your target customers. Get to market with your product and learn how to improve while growing over time.
Once you are in the marketplace, it is time to consider distribution models, which inturn shape sales strategy. He favors account management by pairs of business with technical.
Only in the final third does he tackle the tricky world of services - hard to manage; hard to track - and the hardest to sustain. The bankruptcy courts are strewn with the charred corpses of successful product companies that let this tail wag the dog and ruin the purse.
Finally, he returns to his opening theme, pattern, for a summary yet philosophical discussion. Again, he turns to his architect mentor, Christopher Alexander. His "The Nature of Order" is a worthwhile study for the ambitious reader.
This book is for all sorts of technology people, from those in start-ups to those wanting a make-over, from skunk-works to seasoned developers. For a senior manager, save money on consulting fees. This book is a guard against their invasive capture of your vision and your money, and a good companion to your strategic planning.
This book is a good guide for managers at all levels, whether writing a business plan or developing staff. Use this book to plan your year as a small part of your staff meetings. Assign chapters or sections, perhaps on a monthly schedule, or at least a quarterly one. They make for good team working sessions. Align and conquer.
Anyway, this book has finally made me see what use patterns can be. Allan Kelly has done a superb job of laying out the forms of business strategy and methods of operation available to software companies. Developers who have been around a while will recognize the life cycles, marketing strategies, types of support, product development choices and more of the companies we've been involved with. If you've ever wondered why the company doesn't just make the software better instead of selling professional services, Kelly explains it. Yes, the bosses did it on purpose. They also skimped on the documentation on purpose.
Kelly not only describes the patterns, he explains them clearly and makes sense of the reasoning behind them. If you're a developer, this book can help you understand what the marketers and and distribution people and product managers and operations people are up to. If you are a developer who wants to move into the business end of things, this book is as good as an MBA (except for the details of finance and personnel management and all that generic stuff you also need).
As a bonus, Kelly includes a section defining and explaining what patterns themselves are.
I can't recommend this book highly enough for its target audience. It does what any book of its type should do: organizes knowledge and understanding and experience you already have, puts it together, gives concepts names, and makes the whole thing make sense.
One caution: Kelly is British, so some of his terminology reflects British rather than American usage. "Poacher turned gamekeeper" makes a lot more sense in an English context than in an American one, but you'll understand the pattern anyway.
As a software developer with 20 years of experience in the industry, I can tell you that there is a big difference between writing software from my client's specifications and how it is actually used. The later chapters in this book take you through 38 different strategy patterns with charts and examples of how actual companies used them. Chapter 8 covers the Distribution Model which involves how you will get your software into the customer's hands. In the following pages the basics how this can be accomplished is covered accurately and reflects what I have found myself after many years of work in the industry. Chapter 9, Patterns of Direct Distribution compliments the previous chapter with coverage of how to sell your software and excellent examples how you should manage these new customer accounts. The entire book has a logical progression of knowledge which makes your task of quickly seeking advice on a subject easy.
In conclusion, I recommend this book to anyone new to writing software for business or to a manager seeking better ways to implement electronic solutions for a company. You will be able to use this as a reference guide for planning the entire software design process.
You have basic elements like Users, Data and Business. So some examples of business patterns are User-to-User (Collaboration, like Wikis, Newsgroups, Facebook), User-to-Business (Self-Service, like Online Banking, Online Brokerages) and User-to-Data (Information Aggregation, like Statistical and Market Analysis).
This book applies this pattern development to the Software Development industry, and helps you set up and run your business based on the pattern you are implementing - from how to fund your business to understanding your customers to how to sell your product. With each pattern type, the author presents the context of your pattern, a theoretical problem you might face in that context, forces acting for and against you, a suggested solution to the problem presented, and the expected consequences of the solution with variations. Some examples of business types covered are online gaming services, independent retailer, product support and management.
You should be able to find help for common problems with your business pattern in this book. Many case studies bring the business pattern concept closer to home, as you can identify with real-world examples. So I would recommend this book to anyone who is dealing on a management or owner level with a software-related business.