App development for enterprises, more than just good looks
It sometimes looks like everybody can develop an App or website these days as the entry barrier is relatively low. Everybody with some rudimentary knowledge on software development can produce a simple App. This combined with a huge demand in the market for Apps, has resulted in an explosion of vendors which try to get a piece of the cake. And subsequently pressure on price.
Besides labor cost is the number of functionalities one of the key drivers of the development price. And with App development being a relatively new area, are many client companies finding their way in defining the right scope. Building a App which is supposed to unlock business rules and data from internal (back office) systems is not something you do on a rainy Sunday afternoon.
App vendors and client companies should be aware of the impact (and risk) of building a proper B2C or B2B App. I have seen client companies picking the cheapest vendor and finding out after three months that a large part of the functionalities required to create a fully functionally App were missing. The App itself is often only a very small part of the puzzle, as the main challenge is to access the right internal or external system and combine the pieces to a logical and consistent user experience.
Take an airline for example. To book or change a ticket via an App it is necessary to have access to systems related to seat availability, food preferences, credit card information, luggage preferences, general flight information (e.g. IATA systems) and several others. Several systems (e.g. IATA’s) are read only as it provides a global service for every airline while others have specific interface requirements (e.g. credit card systems). In other words, App development is for many companies a serious profession as it unlocks core business rules and data to customers.
Developing an App which provides access to the right business rules and data securely for a mobile or tablet is only part of the challenge however. There are many more devices around which (soon) have to be taken into account to ensure a company has a consistent presence in the market. Surface tables and touch screen foils are two other digital channels which can be added to the mix, and within a decade expect even your dining table will provide access to you email while you are having breakfast.
To make matters worse, all these devices more capable and versatile, allowing for the integration of more complex business rules (and datasets) on the devices. This trend is depicted in the illustration below and shows that the back office systems have to be opened up to many more devices. The different size of the triangles depict both the increase in channels and the ‘upstream’ shift of business rules and data. A third element of added complexity is the shift from data only to data, voice and video integration. Soon, you will be able to use your banking application on your tablet not only to access your bank account, but use the same App to open a video session with the service desk of the same bank if you have a question about your statement or want to buy an insurance.
To do all this securely and at the same time very fast (consumers get irritated very quickly when having to wait; resulting in a bad customer experience; resulting in customers leaving) is not easy. It requires vendors to develop a capability which is traditionally not their strongest point: combining designing a good looking and intuitive App and unlocking business rules, data, voice and video.
In the illustration below, I provide two sourcing models (in case client companies do not consider App development part of their core IT capabilities). The solution at the left is for client companies which consider the App part of their primary sales/delivery channel towards their consumers. Think of the previously mentioned airliner, banks and other A-brand companies. For them it is crucial that the style of the corporate brand is reflected in the App and that it is very easy to use. This is the area of specialized niche vendors which employ very creative minds with an excellence sense for usability.
Opening up business rules, data and other technical stuff is not their cup of tea however and another vendor typically steps in (or the internal IT department if they have App developers). This second vendor creates everything that is needed to turn a nice looking presentation layer into a fully functional solution. On the right side of the illustration is a sourcing model where interface design is important, but not crucial. Here developers with some creativity, and after following the right courses, can develop the whole stack. The eye-candy part is not that important, it is first and foremost about the right functionalities. The target audience for these Apps are for example internal workers, business partners or for consumers if e-commerce is only of secondary importance of the company.
In short, the following topics are important when thinking about developing an App as a client company:
Besides labor cost is the number of functionalities one of the key drivers of the development price. And with App development being a relatively new area, are many client companies finding their way in defining the right scope. Building a App which is supposed to unlock business rules and data from internal (back office) systems is not something you do on a rainy Sunday afternoon.
App vendors and client companies should be aware of the impact (and risk) of building a proper B2C or B2B App. I have seen client companies picking the cheapest vendor and finding out after three months that a large part of the functionalities required to create a fully functionally App were missing. The App itself is often only a very small part of the puzzle, as the main challenge is to access the right internal or external system and combine the pieces to a logical and consistent user experience.
Take an airline for example. To book or change a ticket via an App it is necessary to have access to systems related to seat availability, food preferences, credit card information, luggage preferences, general flight information (e.g. IATA systems) and several others. Several systems (e.g. IATA’s) are read only as it provides a global service for every airline while others have specific interface requirements (e.g. credit card systems). In other words, App development is for many companies a serious profession as it unlocks core business rules and data to customers.
Developing an App which provides access to the right business rules and data securely for a mobile or tablet is only part of the challenge however. There are many more devices around which (soon) have to be taken into account to ensure a company has a consistent presence in the market. Surface tables and touch screen foils are two other digital channels which can be added to the mix, and within a decade expect even your dining table will provide access to you email while you are having breakfast.
To make matters worse, all these devices more capable and versatile, allowing for the integration of more complex business rules (and datasets) on the devices. This trend is depicted in the illustration below and shows that the back office systems have to be opened up to many more devices. The different size of the triangles depict both the increase in channels and the ‘upstream’ shift of business rules and data. A third element of added complexity is the shift from data only to data, voice and video integration. Soon, you will be able to use your banking application on your tablet not only to access your bank account, but use the same App to open a video session with the service desk of the same bank if you have a question about your statement or want to buy an insurance.
In the illustration below, I provide two sourcing models (in case client companies do not consider App development part of their core IT capabilities). The solution at the left is for client companies which consider the App part of their primary sales/delivery channel towards their consumers. Think of the previously mentioned airliner, banks and other A-brand companies. For them it is crucial that the style of the corporate brand is reflected in the App and that it is very easy to use. This is the area of specialized niche vendors which employ very creative minds with an excellence sense for usability.
Opening up business rules, data and other technical stuff is not their cup of tea however and another vendor typically steps in (or the internal IT department if they have App developers). This second vendor creates everything that is needed to turn a nice looking presentation layer into a fully functional solution. On the right side of the illustration is a sourcing model where interface design is important, but not crucial. Here developers with some creativity, and after following the right courses, can develop the whole stack. The eye-candy part is not that important, it is first and foremost about the right functionalities. The target audience for these Apps are for example internal workers, business partners or for consumers if e-commerce is only of secondary importance of the company.
In short, the following topics are important when thinking about developing an App as a client company:
- Is App/HTML5 development a key capability or is it something I want to buy. Develop capabilities internally if ‘online’ is or will be a core part of the companies’ business model. Always ask help from niche players for concept development of critical B2C Apps.
- Ensure to include all functionalities required to create a fully functional App. It is easy to assume that an Enterprise Service Bus or a data repository will provide all that is needed, but in real life have back office environments the tendency to develop into complex eco-systems with all kinds of interfaces which are often not visible on the standard architecture drawing.
- Think of a mobile or tablet as one of the channels you can reach a consumer with. It can be a standalone solution, but by integrating them into an (online) consumer strategy it is likely to yield much higher returns.
And the following when developing Apps as a vendor:
- Carefully pick your clients and types of Apps you want to develop. In my experience is it easier to more upstream than the other way around. What I mean is that developers which have created complex business applications are easier to train in mobile App development, than train an App developer in unraveling (legacy) back office systems. This would mean that traditional software developers are well positioned to take a considerable piece of the enterprise App cake.
- Decide whether you want to be brilliant in concept creation and interfacing or in the technology behind it. The skills, culture, leadership style etc required to do one of them are very different and cannot be part of the same team. You can focus on one and do a bit of the other, but it is always better to have a clear profile in the market. Client companies know the two things require a different type of person and do not expect to see both combined in one vendor.
- Push back towards the client if you find their requirements cover only half of the scope needed to build a working App. I recently spoke somebody from vendor A which had lost an App deal to vendor B on price, only to find the client going back to the vendor A after six months when they found out that vendor A had priced all functionalities needed for working an App. Here the client had made two mistakes a) not including the necessary scope in de RfP and b) not listening to arguments of vendor A why their price was higher. I am not saying that there will be a happy end every time, but it still happens.
Comments
Post a Comment