The inspiration for this article came up from the animated discussion that’s going on at the Product Nation discussion Forum on ‘Customized Product’ – A true Oxymoron. We all know that customization is bad, and well architected extensions are the way to go. However, I decided to pursue on what ‘well architected’ really means, and what it means for the product business. The answer that came up is that – ‘being built to last’ should logically lead to better valuations. The question is – Does it really?
In the enterprise software world, where one is building large applications, it makes sense to build applications that last. In the consumer app world, it may be better to rewrite when changes occur, but not so in the enterprise world. Some of the best enterprise products out there in the market were built with an underlying framework, with an aim for extensibility and for lasting for long, through decades of change. The underlying product engineering is often proprietary, but aims for certain business goals. All of these goals point to one thing – built to last. Ravages of market focus changes, technology change, functional changes, version changes, and interface changes can still note disrupt the product capability. When products are engineered for this, it allows the business leadership to change their strategies through time, making the product enduring, lasting and hence multiply. Business goals are not derailed by ‘technical surprises’ but actually allow quick leveraging of new paradigms as they keep coming.
From a valuation perspective can you convince your investor to look at a 10 year horizon of returns because you have a ‘built to last’ product, instead of a 4-5 year horizon that is considered based on current market knowledge? Ideal world? Not really. When they say a product is mature, being ‘built to last’ is what it truly means, and there are great products that do these. It takes some more time, effort, cost and vision to architect such products, but the investment is well worth it, if it’s a long term play in a market.
Is it built for functional extendibility?
Functional extendibility is when the product designers know in advance that certain parts of the product always vary by customer, while the core stays the same, and they architect for the changing areas. Here rule builders, formula builders and tax tables enable customer, industry and country specific variations to be handled through ‘meta data’. Changing leave policies, income tax rules, price rules are some good examples where variation is built into good products
Is it built for technical extendibility?
Often, it is difficult to predict the changes that customers need. With an intent to protect the core, and to easily allow consultants to extend the product, extendibility tools are built into many products. View builders, alert builders, email trigger builders, add on extension screens, add on logic builders, and text label changes are some popular extendibility tools available in good products
Built for version upgrades?
Customers and your market expects upgrades. Upgrades are minor and major. Minor upgrades enable installation without the customer knowing. Major upgrades involve data migration. In the Cloud era, one is continuously migrating customers. How can changes be applied and yet allow versions to keep moving seamlessly?
Built for geographical variation?
The initial product may be built for a country and a language, but as time zones, languages, currencies, decimal place handling and other cultural aspects change, can the product easily adapt?
Built for UI diversity?
This was has become exceptionally critical now. How does one use the same product to handle form factors that keep changing. Responsive design is the current flavor of response to changing form factors, but we can expect many more shocks as interface changes innovations in voice recognition, internet of things and 3D interaction start coming in.
Built for maintainability?
One can build great products with a spaghetti of code, or one can beautifully architect products using techniques like model based development, or well defined objects designed for reuse. The true test comes when a change is required across the board. Well designed code is easy to change and upgrade.
Is it built for technology and deployment changes?
Flavor of the year programming languages, temporarily successful platforms, and nifty user interfaces keep improving, but when it is not possible to rewrite the core system, what do architects do? They usually ‘layer’. They allow a whole layer to be replaced to do new things with new platforms. A very popular product has kept its core intact as it moved from the mainframe, mini, PC LAN, Web and now the Cloud eras. Amazing engineering!
Built for scalability?
Can it work on a laptop for a demo, on the server for a group and also scalable on the Cloud to a very large number of users on a multi-tenant environment? The scalability capability is usually related to the platform the product is built on, where the engineering allows the scalability features of the underlying platform to be leveraged easily.
Yet not over engineered
Somewhere, the engineering has to stop and the economics has to step in. Every layer of abstraction added to handle change also creates a layer of pre-configuration before a product is customer usage ready. Finally it is a question of balancing the engineering to the business goals and budget.
Having been involved in product management and functional architecture decisions in Ramco’s products in the 90’s, and the KServe range of Enterprise products (www.KServeHRMS.com, www.KServeERP.com ) as an entrepreneur during the past 10 years, I’ve seen that the long range value of being built to last is often not understood or appreciated fully by stakeholders. With valuations and investment return expectations being short, there is merit in not over engineering, but there definitely a merit in the ‘right’ level of being built to last. Finally, you are accountable to satisfy and delight your customer and your market, and yet deliver returns to your stakeholders, and being built to last can be your long term ally through ups and downs of the business environment.
Guest Post by George Vettath, Kallos Solutions