Why your next software is a ‘guided template’

When it comes to software development, why reinvent the wheel?
10 June 2019 | 42 Shares

Free license code from GitHub. Source: Shutterstock

Nobody builds calculator apps anymore— and there’s a lesson to be learned from this core truth.

That core element of functionality has been compartmentalized, componentized and (in many cases now) containerized to form part of a pluggable set of components that a developer doesn’t necessarily need to build when constructing an app.

Without delving too deep into the world of programming, let’s just clarify what we mean by this suggestion.

When a software engineer, architect or programmer of some discipline or other wants to offer a calculator function to users as part of an app, they can often find this type of core function elsewhere.

The rise of open source and cloud networks has meant that many of these application components have been available on the industries open repositories such as GitHub and elsewhere.

Friendly exposure

The programmer ‘exposes’ the calculator to their application (using an Application Programming Interface – API, or some other form of software driver) so that the app can offer calculation functions.

It could be a calculator, it could be a currency converter or it could be something less mathematical like a maps service, a clock, a weather service or some form of gamification platform, etc.

At the lower level, this means that the world of software is getting smaller i.e. we don’t have to create as many building blocks anymore. At the higher level, this means that the world of software can get bigger i.e. we can start with more of the ‘chassis’ already in place when we start on day one in the workshop.

Enterprise software vendors have reflected this trend in the shape of best practice templates that they now provide as part of their total platform offerings.

Sometimes called templates, sometimes called best practice guides, sometimes called industry-specific starter kits or ‘guided outcome’ solutions, these software head start packages form a sort of reference architecture for organizations looking to build software systems faster.

Head start advantage

The advantages of these templates are perhaps fairly obvious. Customers can plug into whole chunks of application functionality that have been refined and validated for use previously and apply their own data flows to it.

For a specific example, let’s say that a retail business needs a.) a new customer service and CRM system as well as b.) a new more agile billing system. These major software components have already been created by other (often quite similar) firms who also operate inside the retail industry.

There are a certain shape and size to these applications i.e. they need a common level of robustness, they process similar amounts of data depending on customer size, they need roughly the same level of system availability and they perform a somewhat similar number of transactional throughputs.

The message is: why reinvent the wheel?

Vendors now looking to provide these template guides will anonymize and obfuscate all the data from previous use cases and simply provide a template base of application code upon which the new customer can build and, if necessary, further customize for their own use case.

Typical templates

Business application functionality areas typically found within the template array could include cost optimization, CRM, revenue growth, workforce management and related areas of Human Capital Management (HCM), customer experience, plus product and service excellence. But these are just examples, the use case types are much broader.

As the use of template functions increases across the technology industry, we will see an increasing amount of these shortcuts offered as service-based elements delivered in cloud computing platforms.

The choice many customers will now have to make it how far to customize vs. how far they should stick with all the component parts of software being provided by their core vendor of choice.

Customize too much and it’ll be harder to stay on your software vendor’s core roadmap for major version releases. Customize too little and you risk disenfranchising and marginalizing some users who will say that they’re not getting the specific functionalities they need from the firm’s core IT system. But that trade-off is another story unto itself.

It’s safe to say that we’ll see more of these automated options coming forward in all the major tech vendors’ software platform offerings. How industry now takes up this efficiency advantage and how well it engineers it into the coalface of business will dictate how and where this trend develops next.

Template-based technology is for real, but we’re not all about to become some cookie-cutter version of each other quite yet and there’s a lot of differentiation still to build around. Pass the coffee pot and cookie selection box over, please.