There was a time when having an application at all; the mere presence of an automated solution was a competitive differentiator for a company. I remember when our on-line banking product was considered novel, not so much for unique features, as for its very existence.
As time moves on, market dynamic cause the competitors to adjust, adapt, and catch up. The solutions that separate leading companies from followers become smaller, and so either the previous leaders have to step up, or fall behind a new set of leaders.
The graphic below demonstrates an important element in the architecture, design, construction, and support of market leading applications. As time moves forward, the number of features embedded / provided by a digital product tends to increase, but the percentage of total features that offer a differentiated experience tends to decrease.
New features can mean greater speed, more reliability, smaller size, or better security, but more often than not result in additional capability – which means more lines of program code to support. I’m not aware of too many upgrades where total lines of source code were reduced (although it happens).
We are left with a conundrum of how to support an ever-increasing accumulation of source code and feature set, with a fairly static and sometimes shrinking talent pool, in an environment where (by definition) the amount of competitive differentiation is shrinking.
One of the fundamental concepts that we can take from the physical world of manufacturing and apply to software development is specialization. We might call it reuse, leveraged assets, shared services, or even (broadly) SOA. Nonetheless, we can improve the manageability of our software products by extracting responsibility for the development and support of non-differentiating elements, and centralizing these components in specialized teams.
In addition to freeing up front line resources to allow their focus on true market-leading capabilities; this approach enables the very specialization that can drive costs down and quality and scale up. This is not a new idea; certainly not in manufacturing, and not even in software development.
What’s new, may be just how much of an software application can be considered non-differentiating, or put another way; how much of an application can you build from reusable components.
For most of our applications, the front end (the user interface) is likely the obvious choice to leave in the hands of your business-aligned technology team. The data tier is the no-brainer to encapsulate into reusable calls and services. How about business logic? None of that should be in UI/UX layer. How much of the business logic can be adequately addressed through calls to a Business Process Management (think No Coding) solution?
The number of product features is not likely to go down, so this criss-cross conundrum is going to continue for some time. We need to be engaged in thinking to support business demands for more features, while delivering a code base that is easier to manage, cheaper to support, and just never fails.