After discussing issues with building software in part 1 and issues with buying software in parts 2 and 3, this concluding post of the series considers two approaches for organisations to deal with the buy versus build shift.
In the previous parts I have discussed issues with both, building and buying software. As I explained, I believe that the improvements in software development tools, techniques, and practices have reduced the issues with building software significantly while existing issues with buying remain unchanged and the trend towards deeper integration and service-oriented architectures has caused new issues with buying software. If an organisation agrees with this assessment and plans to make the shift towards building more software, what are their options?
[Photo Credit: Original Newberry Library building blueprint, as designed by architect Henry Ives Cobb. Courtesy of the Newberry Library.]
One Ring Out
An obvious approach for an organisation to build its own software is to embrace software development as an important competency. The core competencies remain at the centre of the organisation’s activities. In the newspaper example used earlier the core competency is the work of the journalists who report and comment on stories. Many other competencies that are important but not a differentiator, invoicing the newspaper subscribers for example or purchasing paper for the printing press, remain further out from the centre. In this picture, with the core competencies at the centre surrounded by the other competencies, software development should be viewed as a ring around the core competencies. It is not at the core, but it is close to it and because of its enabling nature it is deeply intertwined with the core competencies.
The mantra to “focus on your core competencies” is one of the main obstacles for many companies to create that ring of software development competency. However, like the “buy when you can” mantra it is outdated. Many companies that were successful over the last decade were successful because they left this mantra behind and explored the ring, or even further rings, around their core competencies. Google did not just focus on their core competency, arguably search and advertising, and outsource the operation of their server infrastructure, making it a procurement problem for servers and rack space. Instead, Google constructed their own servers and made data centre design one of their competencies, even becoming leaders in the field with high ambient temperature centres[7]. They did not buy, they built. Similarly, Amazon, at the heart a merchant selling books and consumer goods, did not buy an e-commerce package, they did not even outsource server operation. Instead, they built their own software and infrastructure, in the process becoming a provider of cloud computing services. Finally, Apple, now basically a consumer electronics company, is increasingly developing competency in processor and system on a chip (SoC) design. Even though these are components that traditional wisdom suggests one should buy from specialists, Apple decides to grow its competencies and build.
In my experience, the hard problem is to overcome this self-imposed restriction on the existing core competencies. Once it is accepted that software development, the practices, the people, and to a certain extent the culture around it, should become part of an organisation the hardest part of the shift is done.
As with any organisational change, though, it is key to have a sense of urgency to get started and to have some quick wins to make the change stick. If nobody senior truly believes that software development is an essential competency the introduction of a software development group will fail. If everything is pinned on a three-year plan, which will only deliver benefits in the third year, the introduction will fail. The organisational setup should reflect the importance, too. A software development group should not be put under the oversight of a powerless task force. It should neither be put in an existing department that itself is not at the core of the business. There are, for example, many stories of retail companies who created a website team in the marketing department, and then wondered why they struggled to make the shift towards e-commerce. The approach to create a sense of urgency will vary from organisation to organisation, but the establishment of a software development capability should always be well aligned with a core business unit, ideally the teams should be co-located, and the new group should deliver value in small increments as soon as possible.
Avoiding the Alignment Trap
As an aside it is worth mentioning the findings presented in a report titled “Avoiding the Alignment Trap in Information Technology”[8]. Based on data from about 500 companies the authors look at the paths a company can take to create a well-oiled IT function that is aligned with the business. There are clearly two dimensions to the problem, the ability to execute and deliver software on the one hand and the alignment of projects with the business on the other. An organisation that starts with a non-existent or below-average capability has to make a choice on which to focus first.
In the study, companies that did nothing, or not much, made up about three-quarters of the sample. They saw slightly below-average growth and about average levels of IT spent. Companies who focussed on execution, likely improving their competency in software development, were able to achieve revenue growth of 11% above average over three years while at the same time spending 15% less on IT than the other companies in the study. The fact that these companies were able to improve their results, and that even without alignment to business objectives, demonstrates the importance of having competency in IT.
The interesting and maybe surprising finding, though, is that companies that pursued business alignment first, without addressing execution, spent 13% above average and had to contend with 15% below average revenue growth. Based on these results, alignment with the business is not enough. In fact, the study suggests that an effort to align business and IT is harmful unless the organisation has first managed to create an effective IT function. Once the competency is there, though, alignment brings companies into the magic quadrant, with costs slightly below the average and revenue growth of 35% above their peers. These are the companies that have managed to create a ring of IT competency around their core competencies.
Buying building services
With the will to create competency in software development, with the understanding that this might shift corporate culture, and with a focus on execution, many organisations will be able to attract people with the necessary skills and organise them into successful teams. Of course, people will bring experience, but another development helps here, too. Many successful companies have realised that being relatively open about their IT competencies and achievements is a huge benefit to their employer brand, their attractiveness as an employer, and by becoming active participants in the wider software development community their teams can learn from other innovators. Even for companies that do not participate directly, this has resulted in an abundance of case-studies and other material to learn from, available through software conferences, books, and online discussions.
That being said, there is a third way: neither buying software nor building it, an organisation can buy services from another company to build the software for them. I should state that the company I have been with for over a decade is such a software consultancy and I am therefore both knowledgeable about the topic and at the same time somewhat biased.
So, instead of creating its own software development competency the organisation finds a partner, a software consultancy that has the necessary competency to build the software. The partner operates on a professional services business model, billing for the effort, for the actual development competency provided. Deals in which a fixed price is agreed for a piece of software are common, too, but that is conceptually closer to actually buying software, and not services. The consultancy can maintain and grow strong development competency when it has multiple clients and it can rotate their consultants through projects at different clients. In each project the consultants will provide some of their past experience while learning something new, which might be useful for the next client. Because the consultants are not fully integrated into the client’s organisation their natural tendency is towards execution, focussing on delivery excellence, which can be helpful in avoiding the alignment trap described above. Another benefit of having a complete team from an external partner, over hiring and building a team out of individuals, is the shortening of the forming and storming process that occurs with new teams. The price to pay is a dependency on an external partner.
In my experience, the most productive shifts towards software development occur when the organisation that requires the competency works with a partner, but instead of out-sourcing the entire delivery it takes an active part in the development process. Initially, most of the development team is from the external partner, they set up the project using practices based on their experience, bringing a bit of new culture and confidence that the process will work. Over time, the organisation hires or transfers existing employees into the team replacing the external consultants one by one until after a year or two the project is fully under the control of the organisation. This approach may, or may not, be more costly than building a team from scratch, but, again in my experience, it does speed up the creation of a software development group while at the same time reducing risk that the affected projects fail.
Conclusion
Hopefully, over the course of the four parts, I have conveyed why I believe that software development has become more attractive, why buying packages is becoming less attractive, and that acquiring competency in software development is within reach of most organisations and can be a huge benefit for them. With all this it is not too much of a stretch to expect that we will see more and more bespoke software development in the future.
A copy of this essay was published in Right Sourcing, Enabling Collaboration. Read a preview of the book here.
References
[7] Steven Levy, “Google Throws Open Doors to Its Top-Secret Data Center”. Wired, 17 Oct 2012
[8] David Schpilberg, Steve Berez, Rudy Puryear and Sachin Shah, “Avoiding the Alignment Trap in Information Technology”. MIT Sloan Management Review, Oct 2007
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.