Gartner and other authorities are already predicting an increase in the number of enterprise apps (ie.
business apps for a specific purpose) that will be required in the next 12 months. They (Gartner et al) are also predicting a significant shortfall in the skill base required to address the increased demand for these apps. It’s classic case of demand (for apps) outstripping supply (the resources to develop them).
App Developer – [ap-p dih-vel–uh-per] – Noun
- A person with a highly desirable job, who works in a funky office with multi-coloured bean bags and is able to command a fortune for their ‘niche’ technology skills.
Gartner and other authorities are already predicting an increase in the number of enterprise apps (ie. business apps for a specific purpose) that will be required in the next 12 months. They (Gartner et al) are also predicting a significant shortfall in the skill base required to address the increased demand for these apps. It’s classic case of demand (for apps) outstripping supply (the resources to develop them).
To overcome this situation enterprises have a number of options which are available to them:
- Train more developers – spend time nurturing people to the necessary skill level to deliver apps until the shopping-list of required apps is complete.
- Stop requesting apps – keep the backlog of required apps manageable by not allowing people to request apps and digitise their world – do they really know what they want anyway?
- Make development times shorter – reduce the delivery time of apps in order to allow a greater throughput.
Individually, each of these could be a solution the enterprise app situation but what if an enterprise could do all of these things AND still keep momentum through their digital transformation journey? The answer is that they can! Let’s have a look at the above in a bit more detail, but in reverse order:
Make development times shorter
The truth with app development is that, in many cases, users don’t know exactly what they want from an app, and what they actually want may differ significantly from the original app brief. As a user there are expectations that the app will be stable, that it will update painlessly and it will have the ability to ‘change’ over time.
Taking this view, I don’t believe that any app is ever fully finished; it is just ‘ready’ at a particular point in time. We’re not talking about sequential releases here, we’re talking about a constant, fluid model of development.
This is a tough mindset to get into as, historically, software development has tended to be a very monolithic entity with everyone aspiring to get to a final nirvana and ultimate sign off. However, in the new digital space this model doesn’t fit quite so well.
What I believed was important yesterday may have changed today. My product (ie. app) roadmap has to update to allow for this innovation. The ‘fixed’ items on this list may cover the next 3-6 months, but the further 12-18 months will be much less rigid.
Development times can be shortened by allowing what is ‘ready’ to be available NOW and then improving it over time. The process for improvement can then be at a pace to suit the enterprise and will incorporate feedback from users and allow for changes. Surely this will result in a better product in the long run!
In my role at CommonTime I’m frequently presented with an app idea from a customer and asked “How long will this take to develop?” My answer varies depending on the end-user but I always want to speak to the client, discuss their requirements and see how we can best assist them: Do they really know what they want the app to do? Have they canvassed their teams to discuss what they want the app to do? Have they discussed which features are vital NOW and which features could be added later?
Get these questions answered before you start coding and you can reduce the development time (ie. getting the app to the ‘ready’ and usable stage) significantly quicker.
Stop Requesting Apps
Is this really an option? Should enterprises stifle innovation within their organisation, allow stagnation and potentially become less competitive?
No, of course not. What should be done is a review of what apps are actually needed, an evaluation of the various development options and a sensible decision on the what/when/how of app creation, based on the facts. This normally requires an owner of the digital ‘roadmap’.
The key phrase here is ‘actually needed’; not just in terms of the features of the app, but more importantly the processes and functions that the app will be designed to mobilise. When CommonTime is called in to provide advice and expertise to a customer, we have a duty to evaluate other suitable products which might be applicable to the project. We are critical of the customer requirements in relation to these other products and (if appropriate) see if value can actually be achieved elsewhere.
Let me give you an example. My personal business background came from ‘mail client’ software and right now if I was asked by a customer to build an app to deliver mail client features, I would say “no”! Why would someone pay me for a feature-set that exists already off the shelf? Can we integrate with a mail client? Of course we can. Can we work with other providers? Of course we can. But there’s no way that a bespoke app solution would be able to compare (and compete) to either what exists natively or by those specialist vendors if (and it’s a BIG if), that’s all the functionality the customer required.
However, flipping that thought around – if an enterprise has one of those monolithic systems which includes a mobile offering that doesn’t do what is required by the end user, then creating apps which enhance and extend that system can start to offer real value. It boils down to the question – “Do I actually need an app at all?”
Train more developers
In addition to Gartner’s predictions about the rise in enterprise apps, they also predict that Business Analysts (ie. non ‘technical’ personnel) will become the new app developers in the future.
This is great news! What if you really could shift the onus away from the Dev guys and put it onto the teams who really knew the business? What if you could take the evolving app development approach outlined above, incorporate some ‘coalface’ decisions on roadmap items and then get the guys who actually know what they want from the app to develop it?
Does that mean I can scrap my Dev team? Absolutely not. Simply use them more effectively. Get them to build micro services that allow re-use. Get them to build integration points and own the app deployment processes. Help them to do what they do best (unless you have a ‘business prevention’ department instead of a business systems team!) and split the skill set between themselves and the Business Analysts (ie. people who will actually use the app!)
A good software developer who understands the business requirements, who can engage with project stakeholders AND who can write quality code is hard to come by (and expensive!). The people who know the app process, who can live and breathe the customer/user experience and can really understand what ‘ready’ means instead of ‘finished’ are not the Dev team – they’re the Business Analysts within an organisation. Empower these people to take control of the app creation process and your potential is infinite!
In summary. There are some exciting changes happening in the enterprise app space. The app culture is with us now and will remain – so embrace it! Allow and encourage innovation. Promote collaboration between departments and functions. Empower your staff and get them involved! Do this and watch your digital strategy unfold.