Emerging technologies you must know for digital tranformation in 2019

At Accion Labs, every year we look back and look forward in terms of what are our focus areas in technology. So, we started in 2016, that’s when we started our real journey in the microservices architecture. I remember the initial first customers we first started talking to about microservices and they were quite afraid. Their first reaction was, it’s very unfamiliar, we’d rather stick to more familiar architectures. From there, in just a span of a few years today almost every application we develop uses microservices architecture, without exception. Of course, the degree of adoption is different in different applications and will discuss in this article, about what is the different level of implementation but certainly, that has formed. In 2017, we started building microservices libraries, in 2018 we created the Breeze blueprint for a microservices architecture and this year we’ve taken it to another level altogether.

The other area is automation and DevOps. We created the DevOps Centr of Excellence in 2016. Today, we’re not treating DevOps merely as an adjunct to development, it’s an integral part of our development, right from every sprint to every release. The backend of every application is today exposed to applications using API’s and initially API lifecycle management of conventional applications was a big problem. As we have matured through these few years, what has changed drastically is that people have started realising or accepting that legacy applications and legacy technologies cannot merely be repackaged in the form of API’s. You can get only to a certain extent in your digital transformation journey by merely packaging your existing applications using API’s. You really have to reinvent your architecture. So rather than treat it as an API lifecycle management we actually moved away from merely API’s into systems like GraphQl, for example, which sort of buy us more time to build a more robust backend and allow us to create better frontends and systems till we have enough budgets and time to build a robust backend. The other area is Blockchain. In 2016 it was still just R&D for us. We started building some of the Blockchain-based applications in 2017. 2018 has been even more exciting, we have worked on a couple of applications that we are very excited about.

Last year conversational UI was one of our big focus areas. We realised that user experience is not merely a matter of pretty pictures and how you can build easier navigations in your applications. It’s also about how does the application react to your user. There are two aspects, one is in terms of conversational interfaces- can your application talk and really understand what the user is really saying? Or is it just a silly chatbot? There’s a big difference between the two. The other thing is the performance of frontend applications, every reengineering project, every new digital product struggles with building high-performance frontend applications. Last year, the trend was GraphQl, progressive web applications as an extension of responsive applications. The constant struggle has been how do you make sure that mobile application development and web application development can merge together, even now we’re spending double and triple the amount of effort just because there is no uniformity in technology in all these platforms. Which is ironical, on one hand, we’re talking of really advanced technologies and on the other hand we’re still struggling with trying to have a unified development platform for mobile and web. Frontend is another that we last year talked about. I think the only area where I was in some ways coerced into our list was Robotic Process Automation. We all recognised that we truly did not believe in Robotic Process Automation. We put it there and much as we expected it’s not really made a big dent. The reason for that is very simple, we look at Robotic Process Automation as a band-aid technology which allows you to overcome some of the User experience drawbacks of legacy applications and try to build some automation on really badly designed applications. Once reengineer applications, reengineer your UX our PA is just invalid or redundant.

Data Lakes – you can see that has sort of taken us all the way from 2016 and this year there is a big difference how we treat Data Lakes. It has become an integral part of the application architecture. It’s no more just- build your application, then you want to do analytics as an afterthought. You have to build your architecture in such a way that you are able to use the Data Lake as an integral part of your application itself.

Shifting left in product development cycle

Fast forward to this year as you’ll see, that most of these areas are extensions of what we did last year. The first is about shifting left our development lifecycle. The first important thing we realised that in any digital journey, whether we’re building products, reengineering existing products or helping organisations reinvent their businesses, the most important thing is- what is the core value proposition? Most of the innovations that we work on are based on technology levers. What technology does is that it allows you to question the assumptions of your current business model. The minute you’re able to open up the box and say is my underlying foundation based on which I’ve built my business model? Is that foundation still valid today? With new technology or no? If you question those assumptions you’ll actually come up with really innovative ideas. That’s why we’re really pushing hard on everyone in Accion to shift their focus away from mere development into questioning – what are the products we’re developing? What is product architecture? What is the concept? Which are the drivers of innovation that are going to be making this product work? So, all of us in Accion are trying to focus our attention more and more left of the development lifecycle.

Performance of UI is struggling with the next two items of integration between voice UI and graphical user interfaces. So, we’re not treating voice as an adjunct to Graphical User Interface. A typical implementation of voice today is in the form of chatbots. There’s an easy way to plug in voice on any application but that’s not the only way you can do it. Most important and the low hanging fruit for integrating voice is in allowing users to ask questions and today if you’re limited by a square box in your application which is answering questions, just because you want to make it sound like or seem like a human being on the other side. It’s a really silly way in which you’re trying to make your application talk. Your application will never become a human being, your application will be limited in terms of its cognitive abilities till AI becomes mature enough for us to make applications that are really intelligent. At this point in time, AI is as good the patterns of data that you feed into those algorithms. It’s still not autonomous intelligence yet. AI is still playing the role of trying to find patterns in data that we feed into it largely. Now there are some exceptions but bottom line is if we are able to integrate voice into the applications interface in a way that the application is able to respond with what the application is good at- which is Graphical interface. So, if you are able to treat voice as an input to allow users to ask questions and the application is able to respond with a rich data and media elements that it is able to respond with. There’s no reason to make the application respond to voice merely in a small window inside of your application, let the whole application talk back. Our focus is in how can we integrate voice into normal graphical interfaces as an integral part of the interface not merely as an add-on afterthought that we’re building into an application.

Mobile Applications

We’re struggling with the limitations of mobile applications having to be developed on different platforms. There’s a different platform to make native applications on Andriod, different technology for IOS and different technologies for the web. Responsive applications were a great attempt but the performance is just not enough. So, we still end up where there are a lot of device capabilities and applications have to use device capabilities, if you’re just using the web, you’re just not going to be cutting the mark. Therefore, the new set of technologies that we’re paying attention to are things like – Flutter which allow you to create native widgets without any bridge between the mobile platform and the UI. We’re very bullish about Flutter. It’s still going to take some time to get maturity on development on Flutter. The second is Server- Side Rendering of UI. We moved from server-side rendered HTML and then we moved all the way to the other side and now all our UI applications are like two lines of HTML and lots of Javascript, and all the Javascript is rendering your applications. Whether you’re using React or Angular or View or any of these frameworks. These frameworks are ruling or creating your entire application. That means what we did was we shifted the entire performance bottleneck down to the browser. Now browsers were smart enough and devices/ our smartphones are powerful enough for most applications to run ok. Performance is still not a given, there are many applications where performance becomes a major issue in front end applications. When we look at a more balanced out approach of making applications render some part of the content that it needs to render in a browser on the server without having to redevelop your frontend application. The true key bottleneck to server-side rendered HTML was that we had to develop code in the backend to generate HTML. So, what we did was we shifted the code into the frontend, so the responsibility of development is split. Frontend developers who focus on frontend development and the API developers focus of API development. Server-side rendering doesn’t change that responsibility. The divergence between frontend and backend technologies so that you are able to develop frontend independently of the backend, matured to a level where initially we developed API’s and then we used GraphQl which almost made frontend developers independent of backend developers. In terms of rendering, there’s no rule that you have to render everything in the browser, you can still write your code and have some part of it rendered on the server, which will give you much better performance and focused on what works well in a browser which is dynamic data-driven front end. If it is not driven by data which is coming from your database or if it is not changing often, we really need to look at can we use server-side rendering, blended into your application? That’s going to give you huge benefits in terms of performance. We’ll see some examples during our sessions today and tomorrow.

Personalization

The other thing is personalisation, we talked about the fact that applications are just not able to understand users, even if you put voice. If you don’t have data about what is the user doing, you’re never going to be able to personalise the application because your view of the user is limited to an entity view of your business. Users are just one table and your database architecture. All you’re doing is primary key relationships between all your business entities which is your focus. All your analytics are based on saying, how much you made and how many transactions and all of that. User is just incidental, we had to reinvent the application saying that the user is core part of our application, he’s a core entity and not just user, events are the core entity of our application. What the user does is what is sacrosanct. If a user has placed an order if a user has just come to your website, it is an event that you cannot afford to miss and each of those events has a string allowing you to define reality. Personalisation is not merely saying Ok can we make our UI allowing the user to define his colours, that’s the silliest part of personalisation. What personalisation means is that you are able to respond to a user based on what is happening in the user’s life, at that particular time. That can only be done if your application is event-driven. It cannot be based on data. I don’t care what you did but did you place an order? No, how did he place the order? Did he come through your website? What pages did he browse on your website? Did he contact your call centre? What is the journey of the user? What are the events that came up to the point where he placed the order?

This is a far more important fact than the fact that he actually placed an order. That’s what helps you grow your business and figure out which are the channels where the customer is coming in. Bottom line is, personalisation cannot merely be an afterthought of saying ok let me just try and see how I can take my data and restructure it from a 360o view of a customer. Which is great for you the 360o view of customers was for you to view a customer but not from the customers point of view. That’s like saying I want to understand everything about the customer, it was never about the customer being able to do what he or she wants to do in your application. It’s a bit of a reversal in terms of how you look at personalisation.

Breeze

Breeze is a culmination of our effort in a microservices architecture. We realised as we went through the years that this transformation of applications is way deeper than we earlier suspected. Earlier it was just frontend reengineering then we said no, hang on you’ve to change your API’s and you’ve to distribute your services into independently deployable small applications but hang on, that can only be possible till my database is integrated into each microservices. If that’s the case how do all these microservices talk to each other? How do I make sense out of so many different microservices? If you look at Netflix’s architecture, they have thousands and thousands of microservices, how do you keep track of all of this? When we used to build monolithic applications, it was so much easier because everything was in one box and you were able to track everything but with hundreds and thousands of microservices how are you going to keep track of all of that?

So, orchestration is another pain point. As part of the Breeze framework what we did was, we said that we cannot merely treat building a product as just a sliver of the layout. Do you want to reengineer the frontend? Ok, that’s fine we’ll do that. Do you want to build microservices? then we’ll do that. Do you want to build a data lake? We can do that. In the Breeze you’ll see that it’s end to end architecture that builds connections between each of these components. It is a very opinionated framework because it’s not merely saying that if you want to build anything you can use Breeze. You have to first buy into the principle of agreeing that this event-driven architecture is the way you want to build applications. If that is the case then Breeze will accelerate your development significantly. We are hoping to demonstrate to you today how you can build an event-driven application really fast using something like Breeze. Event-based integration like I said is one of the big pain points in any microservices architecture. We have a session especially on how to build orchestration between our microservices. Data Lakes is an extension of the architecture. AI Everywhere is a given. I want to emphasise that AI is not an afterthought. The common question that we ask about reengineering applications is – can I use AI? Can I put IoT in the picture? How can I put IoT and AI into the mix and make my application better?

I wish it was as simple as that. If you really want to make use of AI, if your application is not event-driven, you just do not have enough data in your application to train a modal. The data that you have in your databases today are materialised views of events. It’s a culmination of several events and you are abstracting them and you are aggregating them and putting them in a database, in a relational database which doesn’t have any clue about how did you get there. How are you going to be able to do AI if you have such coarse data in your databases? It’s just too coarse. You don’t have any views on how users got to a particular transaction, a particular entity in your database. Just saying that magically I’m going to put AI and it’s going to transform my application, is a bit naïve. We have to build applications to be event-driven and then those applications will keep their data and events in a Data Lake and from this Data Lake which is rich with events we’re going to be able to draw patterns. Absolutely possible. Its an architecture which can be implemented today. Not all of us have the luxury of implementing an end to end application like this, using an event-driven architecture bottom up. The journey is going to take some time and we have to judiciously spend our dollars in a way that we are able to get there. In the shortest possible time, without ignoring our current customers and current applications. That’s a big challenge but certainly AI everywhere is possible assuming the rest of it is already done. The last line here in some ways antithesis of everything I said before. While we are at the peak of our current paradigm of cloud-based application, without realising that there is, you’ve to move your applications to the cloud, you’ve to rebuild your applications using microservices but the new paradigm already on to us and decentralised applications which do not need the cloud anymore are already hitting the markets.

So, how do we invest our money when we know for sure that the applications, we’re building today are going to become redundant in a few years. Decentralised applications are already there in the market. The protocols are still raw and will take some time to get matured but it’s not going to take time, hundreds and hundreds of developers who are working, not getting paid a single dollar. Even the organisation that’s coming up with IPFS and some of these protocols, all of it is released in MIT licence open source. They’re funded companies but they’re still releasing everything in open source. That’s the only way it’s going to change. Decentralised applications are going to force us to relook at our architectures, relook at how we’re building applications but it’s still going to take a few more years. We can’t ignore that, it’s still there on our list but if I were to predict the future, I would say, the real areas that we are looking at are How do you automate, which is what we’ve been doing all this while. We try to automate our applications, we try to reduce our manual effort, we use technology. Technology has expanded its scope, we have IOT’s, so computing power has moved the edge. You’re able to capture more and finer granular data, so you’re able to build systems. AI is not new we already had predictive analytics in all of these models, developed long back. What’s changed is we now have the data to be able make use of it, we have the computing power to run these applications efficiently enough. Not only automation but self -learning applications are possible. That’s going to continue but the other two factors are something that we largely ignored in this journey up to now. We’ve not bothered too much about sustainability, we’ve not bothered about decentralisation. When the internet came into the picture arpanet was defined or created in the cold war era when universities were too worried about- If a foreign power attacks us and brings some of our systems down how do we communicate with each other, so they came up with TCP/IP and http to make it resilient for any node to go down and being able to communicate with each other. As the internet matured, we now start looking at all our applications are hosted on either Amazon or Google or Microsoft Assure. We are moving back into a centralised model rather than a completely decentralised model. Before you know it both these aspects of sustainability and decentralisation are closely linked and limited. As you build bigger and bigger systems they cost more and they are unsustainable. The minute you decentralise they become more and more sustainable so both are closely related and those two factors are really going to play a major role in our future. As we go ahead and we look at a really exciting future which changing the way in which we grow our food, it changes the way we work with technology with augmented reality and technologies like that. The way we use energy is going to change. Renewable energy is going to come into the picture. How do we move, from one place to another is going to change drastically. How do we actually work? The very concept of work is changing because you have automated drones which can do a large part of the manual effort that we were doing. Technology has come down to a minuscule level where even nanotechnology can be inserted inside your body and fix your body. There are really exciting times ahead, you have bionic devices which will make a human being a superhuman being like superman. It is possible today. You can actually build food using a 3D printer. Devices are permeating everywhere. The way we connect with each other is drastically changing. We are going to be looking at more recycling and robotics.

Impacting lives with technology

All of this is a really exciting future and it’s all possible within the next few years. It’s not a distant future. All of these applications we’re going to build. I’m going to ask a very important question- This future is great but the bottom line is, does it really drive the social impact that we are seeking as human beings.

I’m going to leave you with a thought here, this is where we are- The Zuri, Goa, India and the swimming pool that you see there and this is the beach, just about 100 km. north from here, is a small village which is called Aakle, its area is about 500 hectares, population about 300, just 92 houses, they have no road other than a mud road access, they do not have any power or almost no power, mobile signal is intermittent but 50% of the population have smartphones and many of them have multiple smartphones because one provider doesn’t have continues signal so they will actually buy two phones and connect them with two different providers and try to make use of them. The big question is- what can we do with technology for the marginalised and this forms a large part of our country and our world today. All the previous technology was focused on what we are familiar with in our comfort zone, this is not in our comfort zone. The only way we know how to react to pictures like this is, oh maybe we should just give them some money and help them out. That’s not going to change their lives. They are not sad, if you look at them, they’re really happy people, they grow their own food, they have water which is supplied by their land, they grow mangoes and cashew nuts which are cash crops, so they’re not poor.

Last year we did a field trip to this village and we had a bunch of people (some of whom are here) who went there to just experience how do they live? Is it just that they’re marginalised, poor people?

They don’t have money and they don’t have connectivity and they don’t have fancy houses and cars? Or is it something else? We really discovered that the life that they lead is just different from ours, it’s not bad. How can we really make a big difference to people like these who are marginalised from normal technology users that we are used to? So, the project we started is Offline First Technologies. Can we build applications for a village like this of just 92 houses? So that they are able to connect with each other without necessarily using a mobile network, using solar power as far as possible, communicating with each other so hyper-local. Using Decentralised applications so when they get connectivity, they are able to sync back to the rest of the world but they need not stop using their applications when they are offline. All of these are applications that we can build today and if we build applications for this user you can bet that the other users that we are normally used to dealing with will be more than happy because if you are able to make you application work offline first can you imagine the performance you are going to get with your applications when you actually do have connectivity?

This is not merely a pie in the sky or just a side project for us, it’s really going to be driving a large part of our value system in terms of how do we really innovate in technology, by looking at areas that are just not in our consciousness today.