The Rise and Fall of Software Recipes Darius Blasband
ISBN-10: 9490783420
By William Ulrich
When first saw this book by Darius Blasband, the first thought that came to mind was “do we really need another book on software development?” Once I began exploring this book, however, I realized that it fills a much-needed gap in our understanding of software, software development, and software’s far-reaching impacts on businesses as a whole.
What makes this book unique is that it looks at software development in light of the “recipe-based” mindset that has emerged over the past few years that has resulted in efforts to dumb down software development in general and software developers in particular. To my knowledge, no one else has articulated this valuable message in a way that is so insightful, fact based, and engaging. That is not to say that good books on software do not exist; there are certainly many and Darius cites a number along the way. But this book leaves the reader thinking about the nature of software and every decision we make regarding software systems.
Darius delivers two strong, unambiguous messages; “The quality of the people is the single most important factor contributing to the success in software development projects” and “good people are hard to find.” These statements struck a nerve with me personally. For many years I have been performing oversight on major IT transformation efforts and related portfolios. The hard-hitting truth, whether executives recognize it or not, is that successful IT projects ultimately rely on highly skilled people. You would never know it, however, based on the growing degree that IT organizations place on methodologies and processes (i.e., recipes) while deemphasizing the need for quality software development professionals.
Darius speaks to two universal truths when he says that you need good people to build good software and that good people are hard to find. These universal truths were reinforced for me on a recent program on which I performed oversight. This program had the benefit of a well-defined set of prioritized business objectives, framed by a robust business architecture, and supported by a strong portfolio management team. While this was a good starting point, the project also fell into a trap that development projects often experience. Management had recently adopted agile practices and had contracted support from what we termed “agile zealots” – individuals who view agile as the panacea to all software project challenges. Don’t get me wrong, I like the ideal of seeing incremental deliverables versus waiting 2-3 years to find out a project is failing. But a slavish commitment to any methodology or practice that leaves little room for related best practices while devaluing the need for quality developers is a sure path to failure.
With one exception, this program involved a rotating crew of ineffective analysts and developers that were simply not qualified to deliver high quality software. Yet management believed that a well-defined architecture, software development lifecycles, byzantine contract management practices, and, yes, agile, meant they could rotate in any number of incompetent developers and analysts and succeed in spite of the lack of quality people. The result was predictable; the initiative as a whole turned into a slow march towards mediocrity.
There was one bright light in this story that supported Darius’ point that you need good people to build good software. One of the projects under this program had the good fortune of establishing a quality team of strong development talent from day one. The lead was a star, had (at least for a while) strong management backing, and would not tolerate ineffective developers. This development team not only produced high quality, reusable software, but also served as the glue that kept related projects and deliverables aligned. Yet all good stories come to an end. Management in its infinite wisdom turned a blind eye towards these successes and the team of stars was ultimately replaced under the assumption that developers are interchangeable parts. The ending is not fully written on this story, but the slide towards mediocrity is increasingly becoming clear to the objective observer.
Darius shares many other lessons and universal truths. He challenges the idea of over specialization in the software field and the subsequent need for methodologies and checklists as a way of managing cascading handoffs of work. This has led to an ultimate breakdown in communications as specialization, roles, and checklists proliferate. I should note here that when I began my programming career back in the 1970’s we had titles like programmer / analyst. Yes, we did both jobs. Programmers were expected to be multifaceted and were not boxed into a corner, waiting for an “analyst” to hand them a poorly framed interpretation of what they think the business wants or needs, only to deliver a software system that misses the mark. Developers back in those long-gone days produced a wealth of robust, highly functioning software that continues to run in production to this day, even has it has been ported from hardware platform to hardware platform.
My own observations of numerous major IT projects are that the very incarnation of the business analyst today has been distorted and has had the unintended effect of creating a catchall role that more often than not falls short of its intent. Indeed, the analyst role itself is a direct result of what Darius terms predefined divisions of labor in sub-activities that has resulted in the endless cross-checking of lists and deliverables that are the result of this division of labor. I will let you read about Darius’ experiences with business analysts and just point out that I have shared his frustrations many times over.
The wide range of topics covered in this book include development, redevelopment, and software package deployment. I have been involved in systems redevelopment projects for many decades and Darius ponders why such projects fail so often. (They do.) His insights include what he calls optimistic blindness, unbridled constraints, and unrealistic timelines. Even someone with decades of experience in the field found these observations quite insightful. The book even covers the naïveté and challenges of implementing off-the-shelf packages
Reading this book can be a challenge, but a worthwhile one. Darius advises readers up front that there is no set way of reading it. Because of the range of topics, different individuals will want assess how best to consume this material based on their role. Those chartered with IT planning, technical standards, and best practices, such as a Chief Technology Officer (CTO), will find a wealth of information that can help inform their technology decisions. CTOs should in particular take a look at the chapter entitled “Money” when evaluating IT investments.
Darius also delivers useful insights for individuals who determine an organization’s “technology stack”, which represents what is and is not acceptable technology at a given organization. Offering a frank discussion on computing languages in his chapter titled “Language”, Darius delivers lessons that have been lost on management in this day and age where we either don’t care or don’t know what computing languages we have in place, or assume everything will be created in Java. For example, he provides readers with a perspective on the risks associated with deploying a continuously rotating set of non-interchangeable Java frameworks, only to find them “mutually incompatible” even as they reach a point of obsolescence. While this statement seems to be common sense, it is a real issue that management has repeatedly ignored at its peril.
It you are running a largescale project or program, you can take heed of the lessons in this book on roles and responsibilities of the technical team. One thing I found of particular interest was the discussion targeting the role of the software architect and the need for architecture. Darius balances the need for the role with the reality that many architects attempt to over prescribe solutions without getting their hands dirty, leaving the project once it gets going. One piece of advice I wholeheartedly share is that architects should stay with projects throughout their lifecycle.
If you are a developer, there are numerous insights across a range of technologies. I would encourage readers to take heart at Darius’ references to industry computing giants such as Knuth and others he references. I have found that many of today’s developers have lost touch with the history that has led to where the field of software development is today.
Another point of interest in this book is the broad diversity of topics covered. Darius does not leave many software stones unturned. The book includes discussions on XML, domain specific languages, ontology driven architecture, literate programming, UML, numerous computing languages, parsers, and compilers.
In closing let me get back to Darius’ two key points; software recipes do not replace the need for good people, often doing more harm than good, and quality software developers are hard to find. Much of the book addresses the first issue, but his comments regarding the talent drain in IT leaves us thinking more broadly about industry and society as a whole. Are a very small number of high-tech companies draining quality programming talent from IT organizations? I certainly would concur.
On this last point, the book offers no easy answers, but it does deliver unique insights that are lacking in the field today. Darius challenges “common wisdom” and “best practices” that may be doing more harm than good. He highlights issues that result in wasted investments, lost opportunities, and an endless cycle of broken projects and promises. The book’s biggest contribution, however, is that it makes you think twice before you sign off on a set of technology standards, software investments, deployment of yet one more methodology, or a quick fix solution from those that have their own best interests in mind.
Adaptive Enterprise: Creating and Leading Sense-and-Respond Organizations Stephan H. Haeckel
ISBN: 0-87584-874-5
The Adaptive Enterprise is an insightful book that discusses the importance of becoming a sense-and-respond organization. According to the author, organizations that can make the transition from make-and-sell to sense-and-respond will be able to deal with unpredictability more quickly and effectively, and this includes the ability to respond to customer demands of any nature. Stephan Haeckel provides important insights into designing an organization as a system, where a pool of modular capabilities can be dynamically combined and recombined to respond to events, particularly customer-initiated events. While the publication of this book predates the formalization of business architecture by a decade or more, the messaging aligns well to business architecture’s perspective where a fixed pool of capabilities may be combined in an endless number of ways to deliver customer value through formally defined, end-to-end value streams. The author guides readers through the transition cycle, including the hybrid phase, where organizations may exist for a time as they incrementally increase their ability to sense-and-respond. This is a useful read for managers and executives looking at how to be more responsive to customer and other demands in an increasingly unpredictable global environment.
Enterprise Architecture as Strategy
Jeanne W. Ross, Peter Weill & David C. Robertson
ISBN-13: 978-1-59139-839-4 & ISBN-10: 1-59139-839-8
“Enterprise Architecture as Strategy” is subtitled “Creating a Foundation for Business Execution.” Sadly, this is not what the authors deliver. This book, from the Harvard Business School Press, starts with much promise but quickly disappoints after the first two chapters. Opening statements in chapter two set the stage for concern. The authors state that “IT executives work to align IT and IT-enabled business processes with stated business strategy.” This wrong-headed approach to IT planning has become the foundation for failed projects and an increasingly dysfunctional relationship between business and IT.
IT cannot align to business strategy. Business strategies are too abstract to serve as IT alignment targets and this approach creates a knowledge gap that IT creatively fills with the vivid imaginations of an army of business analysts. The correct approach is for the business to align business architecture to the business strategy and then have IT align the IT architecture to the target business architecture. While this concept is becoming increasingly accepted as a means of achieving business / IT alignment, the authors make no mention of business architecture. As a result, they have left a knowledge gap for executives attempting to use this book as a guide to architecture based strategic planning and deployment.
The most insightful and useful portions of the book come when the authors lay out four business operating models: Coordination, Diversification, Unification and Replication. I have had the opportunity to apply these concepts at client sites and have found that it opens up the eyes of executives when they consider their own enterprise in light of these basic operating models. In short, it helps executives understand that their organization is structured in a certain way and they must structure their planning accordingly.
A second useful aspect of the book comes when the authors share one-page diagrams that encapsulate portions of the business and IT architecture in a way that can be quickly explained to an executive. Sadly, the authors provide little insight into the process involved in creating these pictures, discuss little of the underlying metadata required to support creation of these views and muddle the concepts of business and IT architecture as a result.
Consider for example, Figure 3-5 on page 59 showing the MetLife core diagram. While helpful for viewing the customer / screen / application / data relationships, it is essentially an IT-centric view of the enterprise and sidesteps a more business centric schematic that should include capability, value chain and process based views of the business. The risk in such a diagram is that it creates a perception that IT is the only aspect of the business that requires analysis and alignment.
In addition, the authors entirely omitted MetLife’s leading edge work in business architecture. MetLife shared its experiences and successes in business architecture and enterprise architecture on Nov. 2008 in New York. The MetLife presentation provided a clear view of the importance of business architecture within the context of enterprise architecture.
In stark contrast to MetLife’s views on business and enterprise architecture (and those of numerous other leading organizations), the authors define enterprise architecture (page 47) as “the organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the company’s operating model.”
In this definition, the authors omitted the concept of business architecture and filled the void with business processes. The danger here is that it communicates a view that the only business aspect to enterprise architecture is the business process, which the OMG Business Architecture Working Group, Business Architecture Institute and even Wikipedia refute. Business executives reading this book will be led to believe that IT-enabled business processes and IT architecture are all that are required to deploy a successful business strategy. Industry best practices, including work being done by MetLife – a company cited by the authors, show this position to be patently wrong.
As far as the rest of the book is concerned, it quickly moves beyond the business realm into a discussion of IT architecture. The emphasis on IT is highlighted most dramatically beginning on page 92 where the authors list the first benefit of enterprise architecture as “reduced IT costs”. First, IT spending is a small percentage of overall spending and therefore not the ideal source of funding cuts. In addition, if IT funds are being spent to retain or attract customers, streamline the ability of a business to bring a new products or services to market, or control operational business costs, then reducing IT spending could have a negative effect on the business.
The focus on reducing IT costs as the number one benefit of enterprise architecture casts suspicion on the validity of this book as a guide to “creating a foundation for business execution” as the authors have labeled this publication. Given that the authors cast the CIO as the key driver of enterprise architecture (which presumably includes business architecture) it should not come as a shock that they focus their benefits discussion on IT value and not on business value.
Executives reading this book should use it sparingly and judiciously. While the four operating models can be useful as input to enterprise planning, do not assume that you can jump from business strategy to IT deployment. The track record of failure of this approach is all too clear. In addition, consider crafting simple views of the integrated business / IT architecture for executive planning purposes, but be sure to create the supporting business architecture / IT architecture metadata and related mappings needed to validate these views and to drill down to subsequent levels of detail.
Finally, this book as with most books should not be considered a business or IT planning bible, but rather just another book where executives can pluck one or two good ideas out to be added to their arsenal of useful concepts. In this case, pluck out the operating model concepts presented early in the book and then move on.
One From Many: Visa and the Rise of the Chaordic Organization
Dee Hock
ISBN 1576753328
[Updated Review - August 2009]
Since my initial review of Dee Hock’s excellent book, I have had to opportunity to further test his ideas within the context of numerous business engagements. The organizing principles Dee Hock put forth in his book have served to create a foundation for establishing parallel organizational structures that can function within an enterprise. For example, TELUS Communications created a Quick Win team function that uses “Chaordic” principles to function within the context of the corporate hierarchy. Other organizations are applying Dee’s concepts as well to align with business partners to deliver a common set of products and services.
In addition, Dee’s work has taken on significant value in the practice of business architecture. The organizational representations that map to business capabilities, processes, customers, products, initiatives and other aspects of the business are best represented in the social networking diagrams. In addition, the focus on purpose and principles have provided a strong foundation for establishing collaborative teams within and across enterprises and this includes business architecture centers of excellence.
Dee’s work continues to resonate within the business community. While originally envisioned as a vehicle for aligning disparate organizations to organize around a common purpose to address major industry and social challenges, Dee’s work has been successfully adapted to provide real value within major enterprises. Any executive seeking collaborative solutions to major challenges would be well advised to read this book.
[Original Review]
Dee Hock, Founder and CEO Emeritus of Visa, not only recalls the intriguing events that led to the creation of Visa, but shares the roots of his personal journey that took him to that place and time. This book chronicles Hock's exploration of the nature of organizations that go well beyond anything that had been done to that point in time. As a byproduct, he helped save a credit card industry that was bleeding money across a sea of large and small financial institutions. The reviews inside the book and on the cover, along with a Forward by Peter Senge, ring praises upon Hock for sharing this riveting story.
James Gleick
ISBN 0 14 00.9250 1
Chaos is a basic theme in nature, science and in organizations. Chaos, where order can be found in what appears to be random behavior, has tremendous implications on how we create and leverage organizations. If you want some excellent background reading on where Dee Hock is coming from in the Birth of the Chaordic Age, check out this book. Or if you just want to get a better understanding of the world in which we live, understanding chaos is a great start.
Adaptive Software Development: A Collaborative Approach to Managing Complex Systems
James A. Highsmith III
ISBN 0-932633-40-4
Highsmith applies Chaordic organizational disciplines to large-scale projects. He breaks away from the notion that a project can be neatly broken into little pieces, organized like a puzzle and laid out in a neat and predictable manner. Rather than the traditional task-driven thinking that has permeated project management for too long, Highsmith focuses on results-driven concepts. The book discusses collaboration and adaptability as overriding factors in managing complex projects. If you are deploying an e-business strategy across your enterprise, or tackling any other type of large, complex project challenge, this book is strongly recommended reading.
Complexity: The Emerging Science at the Edge of Order and Chaos
M. Mitchell Waldrop
ISBN 0 671 87234 6
Self-organizing systems are all around us. Whether you are talking about a hurricane, a pot of soup, the economy or an organizational infrastructure. Lessons from Complexity can be applied broadly, particularly when brought back into the realm of organizational structures. One important aspect of this is that self-organizing systems are more adaptive. Ever wonder why corporate hierarchies segregate people rather than encourage collaboration, or why they hinder rather than enable communication, or why they break before they adapt? Self-organization and other fascinating insights into a variety of disciplines provides the reader with, as Waldrop puts it, a "vision of the whole".
Fractals: The Patterns of Chaos
John Briggs
ISBN 0-671-74217-5
A visual ride through the world of fractals . Briggs brings together nature, math, science and art to show us what chaos looks like from many perspectives. My interest here continues along the lines of how organizations really look like fractals if you expose their true nature and do not try to pretend that they are really hierarchies. You will enjoy this one and can even put it out on your coffee table.
Large Group Interventions: Engaging the Whole System for Rapid Change
Barbara Benedict Bunker, Billie T. Alban
ISBN 0-7879-0324-8
This book provides good insights into managing organizational change. Any executive team that thinks they can lock themselves up, build a new organizational hierarchy and then implement it from the top down should read this book. Of course those executives that do the most damage are likely to be the least likely to think they need advice on this topic. Bunker and Alban explore many ideas regarding topics such as participative design: a key element in building new organizations.
From Chaos to Coherence: Advancing Emotional and
Organizational Intelligence Through Inner Quality Management
Doc Childre & Bruce Cryer
ISBN 0-7506-7007-X
Most our reviews address the challenges of dealing with the complexities of moving enterprises further into the information age. From Chaos to Coherence addresses the human side of the equation. Childre and Cryer are from the Heartmath Institute and offer proven techniques for organizations undergoing radical changes in chaotic times. They offer tools to deal with real-time changes in companies and across industries. They also offer scientific underpinnings for their work something the Heartmath people have been doing for a long time.