Architecting for a Digital Economy
Ajay Pherwani, Vice President & Chief Technology Officer, Tata Capital Financial Services Limited
Ajay Pherwani, Vice President & Chief Technology Officer, Tata Capital Financial Services Limited
A simple, technology geek, completely focused on maintaining a data center and implementing core applications. This is what a CIO used to be many years ago. And just like the businesses the CIO was supporting evolved, the role of the CIO also evolved and became more complex, more customer focused, and completely business linked. There have been multiple inflection points that spur these role evolutions, but none so misunderstood and so complex as the Digital wave. Gartner recommends to deal with this using a Bimodal approach, whereas Mckinsey recommends a 2-speed IT model.
The CIO now needs to understand how to balance the traditional core applications (legacy systems, ERPs, core banking platforms, etc.) with the myriad of customer-facing solutions. It is obvious that the architecture approach towards these would be completely different.The drivers for alternative approaches to EA include providing a differentiation in terms of customer experience, the time-to-market, and the creation of innovative Digital products.
“Technology plays a role in defining the new architecture for the Digital Economy.”
With the proliferation of the API-economy, every niche player and their uncle is providing some sort of value addition via a set of web services directed towards addressing a small business need. This has resulted in niche players flooding the market and spoiling the CIO with choice. The focus on a seamless, multi-channel customer experience means that individual customer journeys (use cases) can actually become the basis of engaging with multiple players. Such niche players and startups that fuel innovation need to be evaluated from a different lens as well. Are they long-term players or playing the valuation game? Players seeking valuation normally run at a loss and it is imperative to examine their A/B funding, etc. before signing up with them.
At this
The core systems continue to be the legacy workhorses and most likely would be slower to change with time. These would primarily be driven using SDLC, ASAP, and other such methodologies. The processes would be more mature, more well-defined, and subject to an extremely strong test and QA cycle. The chances of errors would be few and far in between. The agility part, as it is being driven mainly by the Customer Experience, applies primarily to the outside-in approach. This includes the portal, the responsive mobile web, real-time analytics for cross-sell, and the likes. The agility is fueled by innovation – innovation in product design, innovation in cross-sell techniques, and innovation in analyzing customer behavior on the various channels. These innovative ideas need to be implemented in quick-time and cannot afford to be handled using traditional methodologies and long release cycles. A more agile approach is needed, and one needs to be prepared to experiment, test quickly, fail and learn to recover from failure quickly.
The API economy introduces challenges of its own. Assume that you have alliances with multiple aggregators for business leads. For example, when offering finance for Consumer Durable items, there is an almost infinite set of item codes (SKUs). Each alliance partner would use almost the entire set as its master, but internally code them with its own specific internal code. So, when the item code reaches your web service, what you have is the alliance code and not the original SKU code. Mechanisms can be designed using web services to handle such cases – and such mechanisms need to be flexible to adhere to the specific needs of the alliance partners. A layered approach to introduce abstraction via such translation (or mapping) services helps. A second challenge with web services is that they are cross domain, and we don’t have control of when a web service is up, or down. Hence, the web service calls need to be designed with retries, and error handling mechanisms. A good Enterprise Service Bus (ESB) would be absolutely essential for enterprise-class resilience.
I mentioned earlier that agility and complexity results in more chances of failure. Being Digital in nature, the impact of failure is exponentially higher. The architecture and systems need to be designed to gracefully revert back to older / tested versions, or provide some message of downtime, when such an occurrence happens. Version management becomes critical as does providing higher levels of security.
The role of the CIO has definitely changed, being more agile, more customer focused, and more architecture oriented. No longer does a CIO remain a simple, technology geek, completely focused on maintaining a data center and implementing core applications.
