More and more code, delivered faster and faster. According to many, that’s the imperative if you want to keep up with today’s fast-paced, mobile-enabled, digital-first business environment. We are told that markets are now driven by software and that developers are now calling all the shots. As part of this, DevOps is promoted as a way of pumping a continuous stream of code into your live environment.
The problem with all this is that priorities have become distorted, not least because suppliers are scrambling to win over mobile and web based businesses that need to keep churning out new apps and features to survive. Most in this developer community don’t stay in business for long, of course, but huge volumes of code are nevertheless written each day to feed the ever-hungry app stores and consumer clouds. This has created a frenzy among development tools vendors, who are urging their enterprise clients to become similarly obsessed.
But don’t get swept along by this ‘develop or die’ mindset. Development work to do with new solutions, incremental updates and systems integration will always be required in larger enterprises, and new needs are emerging around digital and mobile. It’s important to remember, however, that despite the evolution of tools and techniques, code will always need to be maintained, and changing that code will always need significant effort. The result is an ongoing burden and cost, and a degree of rigidity. The age old principle of buy where possible and only build where absolutely necessary therefore still applies as you look to optimise IT delivery.
The nature of modern packaged applications and enterprise-class SaaS solutions reinforces the relevance of this principle. A lot of things that historically required development and integration work come as standard nowadays. Mobile and web access to a range of core business functions is often enabled out of the box. Soft-coding of the environment means that this and other capability can be tailored without hard-core programming effort. Then where new functionality is required, data-driven development tools enable a drag and drop approach to meeting many needs.
The point is that whole swathes of development can be avoided by modernising your standard application portfolio. This has the added advantage that application vendors and SaaS providers will ensure smooth upgrade paths for the future, including your customisations and extensions. They will also take the strain when it comes to supporting emerging technologies and standards.
Going down this route means you can direct your software development efforts to where they really matter. For many organisations, this will be in the area of customer-facing systems. Consumers, and even business clients, increasingly expect to interact electronically via the web and mobile devices. This is also the area in which rapid and continuous delivery are important, not just to keep to up with changing behaviour, but also to make sure your digital presence stays fresh.
Having said this, in most customer-facing scenarios the requirement is generally for rapid deployment of new data and content rather than software. Indeed, while customers want to see new products, offers, information and multi-media, they are often put out when you change the way the website or mobile app works. It is no coincidence that the functionality of most successful, big retailer and media sites, for example, actually changes pretty slowly, even though the content changes day-by-day, hour-by-hour or even minute-by-minute. When customers get a habit that works for both you and them, you need to be careful not to disrupt it.
Of course that’s not to say that rapid software and development and rollout isn’t important, particularly in the early days of you building your digital capability, but you probably want to aim for a reasonable degree of stability over time. A fundamental design requirement, however, will generally be to allow those in the business, i.e. non-technical users, to drive content and data out through applications and services independently of IT. You may even enable users to change software behaviour through business rules and other application settings. The principle here is to again minimise development effort, this time through user empowerment.
So, by all means take advantage of the latest ideas and tooling to support agile development, DevOps, and so on, but don’t take advances in these areas as licence to go development crazy as some suppliers would have you do. How you approach software development is important, but a more fundamental question is how you minimise the need for it in the first place. Business agility stems from taking a balanced approach.