"Enterprise Software Delivery: Bringing Agility and Efficiency to the Global Software Supply Chain" is the latest book by Alan W. Brown, and is a must-read guide for anybody concerned with the development and delivery of software in a large organisation.
The entire book is a summary of Enterprise Software Delivery, but the following passage from the appendix perhaps sums up the term and its importance best:
Fundamentally, enterprise software is any software-intensive solution or product that provides core services to an organization in its daily business. Consequently, the enterprise software delivery organization is a support organization with responsibility for the creation, evolution, or ongoing operation of an enterprise’s computer systems. ...Enterprise software delivery is primary to the organization’s success. It provides the infrastructure that the organization relies on for smooth operation of its key business processes, provides key information- focused services that differentiate the organization’s business offerings, and supports a wide variety of stakeholders who communicate through a common set of information managed by the group.
The initial chapters set the scene as to why Enterprise Software Delivery is so difficult and the characteristics of software delivery teams and projects as they often stand today.
...Enterprise software delivery organizations are under increasing pressure to manage costs, be productive, reduce time to market, and enable maintenance and evolution of those systems over extended periods of time. In addition, they must achieve all this with greater transparency and accountability to the business.
The core of the book contains an intensive look at some of the key themes of building a successful Enterprise Software Delivery organisation.
The chapter on The Software Supply Chain and Software Factories is based around the thought that in order to be more efficient at software development, we need to borrow ideas from other domains such as manufacturing. There is a detailed discussion on software testing factories as well as examples including an overview of the IBM Application Assembly Optimization (AAO) approach.
A software factory approach to enterprise software delivery requires a well established, multiplatform process with tooling that aligns business strategy with engineering and system deployment. Such multiplatform processes prove critical in building applications that meet the needs of the customer. Helping to identify business needs and stakeholder requirements, they then drive those business goals into enterprise software delivery projects and solutions, ensuring that the final product meets the business objectives with the lowest possible cost and highest possible quality.
The Collaboration chapter contains a detailed discussion on how to best tackle distributed delivery (given it is now, according to the author, the de-facto approach) as well as teh importance of collaborative development environments and application lifecycle management (CALM).
A dominant theme is emerging in the delivery of enterprise software: collaboration is king.
It is not surprising that Agile also gets its own chapter, and rather than get bogged down in approaches and practices, the book details some pertinent arguments for Agile as well as some suggestions on how to deploy it to scale.
My experience with several large enterprise software delivery organizations suggests that agile approaches can be successful in almost every kind of development team and in almost all organizations.
The author shares some of his critical success factors to agile scaling from his own observations:
- The roles most challenged by Agile approaches are those of Executive Managers, Product Managers, and Project Managers
- Plan at multiple levels and adopt a “measure and steer” approach to Agile planning
- Don’t use Agile methods for everything; match those practices to project characteristics to optimize success
- Adapt and harden the Agile process as the project gets closer to delivery
The importance of software quality as well as governance are highlighted in their own chapters with examples of measurements and metrics as well as discussions into topics such as automation, visibility and security.
...when we choose a set of metrics, we are explicitly or implicitly stating which parts of the enterprise software delivery process and organization we wish to control and which we do not.
The book concludes with a chapter on the lessons, limitations and challenges of the techniques discussed in the book as well as a discussion on future directions that are affecting the enterprise like cloud computing, multisourcing, crowdsourcing and mobile technologies.
- Use the characteristics of the enterprise to guide where and how industrialized approaches to enterprise software delivery can be more readily applied.
- Assess the process maturity of the enterprise and pay attention to differences in how it relates to the maturity of other organizations in the software supply chain.
- Don’t overly focus on standardization and cost cutting to the extent that it stifles innovation and creativity.
- Know your supply chain weaknesses and have explicit approaches in place to address them.
- Seek to gain insights from experiences in other domains with a history of supply chain management and industrialized delivery of solutions.
- Learn from other people’s failures and document your failures so that you (and others) can learn from them.
One of the highlights of the book is the large number of real-word examples (which includes examples in each core chapter as well as three chapters of in-depth case studies) as well as diagrams and figures that illustrate the key concepts being discussed by the author. This in turn leads to my only criticism of the book, which is due to the authors role and background at IBM Rational, many of the examples have an IBM context to them.
Overall, this is a book that all current and aspiring technology architects and leaders should read to gain ideas and approaches to improving their delivery approach. For some readers I suspect it will be an affirmation of approaches currently being undertaken with some different ideas for consideration. For others, it will be an eye-opener and a call to action.
Recently the author spoke to InfoQ about the book.
InfoQ: What prompted you to write this book? What problem do you hope to solve in the community?
My main motivation was a sense of frustration that in many of the situations in which I was offering consulting advice to software development and delivery organizations, I was seeing the same challenges and tensions being addressed, and little progress being made. I started to develop some ways to think about how to analyse and explore this, and when I tried to find good existing materials and frameworks in the literature, I couldn’t! I started to discuss this with colleagues in IBM and elsewhere, and was advised that very little was available and I was “on my own”. So after working on several customer activities I decided to write down some of what I was experiencing and the successful patterns I saw, to try to make sense of why this basic tension between agility and governance existed, and why it was exacerbated in a world of global software supply chains, outsourcing, and multi-company partnerships.
InfoQ: You mention that “managers that have transitioned to a more agile steering leadership style” are more likely to be successful. What are the signs of an enterprise that has leadership that has adopted this style?
When I look at some of the more successful Agile projects I see much greater flexibility in project management, measurement, and governance in several dimensions. Gone are the massive Gantt charts covering half the wall and showing activities for many months into the future. Instead you see greater autonomy in decision making at lower levels in the organisation, you see shorter cycles in a “think-do-learn” cycle, and you see a managed approach to prioritising and re-prioritising based on what is being learned. There are several organisations where this thinking and approach is quite well advanced, and the differences they experience in project delivery are remarkable.
InfoQ: In the book you talk about “best-in-class product and services companies are those that have built a strong competency in enterprise software delivery”. How do you define an organisation that is best-in-class?
There is currently a wide variation in execution capabilities in enterprise organisations. You can start to put some measurement in place around build cycles, frequency of build, the percentage of times that new builds break, percentage of automation in regression testing, and so on. These are helpful indicators. But those I consider “best-in-class” have a clear focus on connecting development and delivery activities into a more continuous cycle, talk about the combination of “dev-ops” as a core competency, and they will tell you about how they look to optimise "flow" across their lifecycle from idea to action. When you discuss these aspects with management and senior engineers, you very soon get a handle on what is going on.
InfoQ: In the book you introduce the term CDE (Collaborative Delivery Environment). Do you envision a CDE being software that an organisation can purchase off the shelf or more likely a combination of virtualised environments, (C)ALM and other collaboration software?
It would be nice to delegate this issue to an off-the-shelf toolset. But unfortunately it is not that easy! Certainly there are automations that can help smooth the processes and give you control, measurement, and insight into what is going on. But the real issue is to introduce the skills and change in mindset that focuses everyone on working toward getting value into clients’ hands as quickly as possible. The tooling of a CDE encourages and supports that.
InfoQ: You make the point that software delivery is evolutionary and that the critical phase comes after first release. Do you have any suggestions on how we can better educate organisations and their leaders about this critical change in thinking?
Yes, the best way I have found to do this is through some simple visualisations. For example, in IBM we have used some visualisation software to analyse the change logs for some of our large scale systems. We can see in a very immediate way how a large complex codebase changes and evolves over a 6-12 month period due to upgrades, bug fixes, fix packs, etc.. You see all the people who touched the code, documents, test scripts, etc. It is always quite an eye-opener to our management to see this, and to realize just how much effort is needed to control, govern, and manage this effort.
InfoQ: In the book you mention that “single, centralised enterprise delivery organizations are a thing of the past” and that ”every project is a distributed project”. Are there any situations in your experience where distribution may be less effective or harmful to an organisation?
Distribution has become inevitable as a means to make use of resources around the world, reduce costs, and open up your delivery model to outside groups. But this clearly comes with drawbacks. These are more obvious projects that must move very fast, that use new, unprecedented technologies or processes, and where external factors (such as privacy and security) demand tight control. This is typical in some government and military/aerospace situations, where they can struggle with distribution of projects. In these situations the management of the distributed team can overwhelm the benefits.
InfoQ: In your chapter on Agile Software Delivery you declare the following: “My experience with several large enterprise software delivery organizations suggests that agile approaches can be successful in almost every kind of development team and in almost all organizations”. Many traditionalists may see your loophole in this statement, so can you outline when Agile approaches would not be effective?
Well, the word “agility” covers a broad area… and is context dependent. So I think we need to take some care in thinking through where and when agility makes sense. In recent work with a satellite technology company, for example, where there are multi-year missions with some rather severe constraints, it is clear that the word “agile” has a limited interpretation. They cannot be redesigning the mission parameters every few days. However, they do need to be clear about how they focus on closer stakeholder feedback, how they learn from prototypes and simulations, and ensuring that the project governance is appropriate to the delivery approach. We have still, in a broad sense, been able to introduce some agility and flexibility in their approach. Certainly much more than was in use previously.
InfoQ: In the book you mention the importance of software quality as well as the benefits of an agile approach, yet you also talk about the role of software testing factories which goes against much of the thinking of testing in Agile teams? Do you have any advice on how a software testing factory can help the development team find bugs early thus eliminating expensive rework?
This is a good example of the balance that I believe is essential between the agility of integrated cross-functional teams and the efficiency of offshore role-based services. All organisations are looking at how they blend these ideas to get the ability to change quickly, but still have the efficiency of repeatability and scale. So in the case of testing factories, they can provide quick turnaround when a project needs some of the core work around performance testing, load testing and open source scanning. This becomes a real accelerator in software delivery if handled correctly.
InfoQ: In your role at IBM, and based on the examples in the book, I am sure you see lots of different approaches to enterprise software delivery. Are there any trends that you are seeing past the publication of the book?
In the last few months the debate on outsourcing and offshoring has widened much further than I had expected. There are major changes in the economy, in the political situation, and in the speed of new technology delivery that are pushing organisations to create a balance of local, onshore, Agile teams with core offshore services for scalability and value. In several cases I am working with large organisations to completely rethink their delivery model. The big push right now is to change the communication, coordination, and collaboration models to be more transparent, and to be supported by business models and contracts that work to encourage these relationships… not prohibit them. This includes looking much more closely at open sourcing, crowdsourcing, and other forms of innovative business partnering relationships. The situation is becoming much more complex than I had expected.
InfoQ: For technology leaders and architects reading this book, is there one core piece advice that you would like them to takeaway?
The main point I’d like to emphasise is that software delivery managers need to arm themselves with a new set of principles, practices, and experiences to be effective in their jobs in the future. Simple outsourcing schemes have limited value. Agile software coding practices have been hugely influential in small teams, but struggled to scale. Cost efficiencies are continuing to drive budgets and decision making. So there is a real need for new thinking about how the balance of agility and efficiency can be addressed. Some great new thinking is emerging, as described and illustrated in the book. Get yourself up-to-speed on these techniques and you will be much better armed to be successful in the challenging times we face… and will continue to face for the foreseeable future.
About The Author
Dr Alan Brown is Professor in Entrepreneurship and Innovation at The University of Surrey’s Business School in the UK. Alan is a Distinguished Engineer at IBM Rational software. His most recent post at the company was as IBM Rational Chief Technology Officer (CTO) for Europe. In that role he worked with customers across Europe consulting on software engineering strategy relating to enterprise solutions, process improvement, and the transition to agile practices.
"Enterprise Software Delivery: Bringing Agility and Efficiency to the Global Software Supply Chain" by Alan Brown is published by Pearson/Addison-Wesley Professional, June 2012, ISBN 9780321803016 For more info please visit the publisher site.